Transfert ou transport ?

by Christian on 28 novembre, 2009

L’emploi de ces deux synonymes que sont « transfert » et « transport » a attiré mon attention après avoir constaté que, même si parfois les deux termes sont utilisés de manière quasi interchangeable (« transfert ou transport »), il y avait aussi des cas d’usages dans lesquels prédominait l’utilisation d’un des termes plutôt que de l’autre.

Qu’en est-il donc ?

Les cas d’usages de « Transport » :

  • Il semble y avoir prédominance du déplacement physique et matériel ;
  • La logistique s’occupe de transport ;
  • Déplacement entre deux lieux (dimension topologique) ;

Les cas d’usages de « Transfert » :

  • Implique la notion de propriété, il y a l’idée de transfert de droit sur ce qui est potentiellement transporté.
  • Le Littré dit ainsi que transfert est un  » terme de finance et de commerce. Acte par lequel on déclare transporter à un autre la propriété d’une rente sur l’État, d’une action, d’une marchandise en entrepôt. »
  • Avec le transfert, on passe d’une sphère (d’influence, de pouvoir, de droit) à une autre, cela peut s’accompagner d’un transport (ie. physique), mais pas nécessairement.

Dans l’informatique et technologies en réseau, ces deux termes sont bien sûr très utilisés. Pourtant, je n’ai pas réussi à trouver, que ce soit à l’IETF ou au W3C, une définition explicite qui distinguerait les deux termes. Il sont parfois utilisés de manière équivalente mais, la plupart du temps, et selon le sujet évoqué, on constate que c’est un des termes qui prédomine. C’est donc qu’il y a à minima une distinction implicite.

Au niveau de la couche des protocoles applicatifs, on constate un primat du transfert sur le transport, on y parle exclusivement de transfert :

  • Simple Mail Tranfer Protocol
  • File Transfer Protocol
  • Hypertext Transfert Protocol

Le terme de transport, quant à lui, n’est présent que sur la couche qui porte son nom, par exemple au niveau TCP/UDP :

Cette distinction d’usage, même s’il elle n’est jamais thématisée en tant que telle, nous conduirait à affirmer que là où les protocoles de transports transportent des données, les protocoles applicatifs transfèrent des représentations.

Ainsi, c’est parce qu’il y a une sémantique applicative qui est transférée que l’on parlera de transfert. Il apparaît alors que c’est le niveau de sémantique qui nous force à utiliser transfert plutôt que transport. C’est un transfert parce que il y a du sens, celui d’un langage applicatif avec des représentations spéficiques associées (des types de fichiers et de documents, mais aussi des actions sur ces représentations).

Je dis un « niveau » de sémantique car il y a toujours un langage, une sémantique, dans chaque couche, puisqu’on parle de protocole. Mais les protocoles de transport ne « discutent pas » avec le contenu qu’ils transfèrent ; le dialogue avec le contenu commence au niveau du protocole applicatif. Dans le transport, il est juste question d’émettre et de recevoir (SEND et RECEIVE), dans le transfert on écrit, on lit, on modifie, on ajoute : il y a une richesse des actions plus importante que dans un protocole de transport (sans dire pour autant que les protocoles de transport soient « simples »).

C’est le modèle en couche qui permet d’articuler le transfert et le transport : le protocole de niveau applicatif travaille sans avoir à gérer le transport des données. Du coup, on a bien toujours du transport là ou il y a du transfert : pas de transfert sans transport (sauf peut-être lorsque l’on fait appel à des données en cache).

*

Il se trouve que la psychanalyse utilise également le terme de transfert. On peut même dire que la psychanalyse se constitue autour de la question du transfert pour en faire la cheville ouvrière de l’analyse (ie. le transfert n’est pas simplement un obstacle à l’analyse, il doit lui-même faire l’objet d’une analyse pour constituer le discours psychanalytique).

Or ce sont des représentations qui sont transférées par l’analysé vers l’analysant. Et le transfert est également qualifié de projection : c’est l’analysé qui projette sur l’analysant des représentations.

En ce sens, on est frappé de voir à quel point le style d’architecture du web peut avoir de fortes similarités avec la théorie psychanalytique.

Print Friendly
Signaler sur Twitter

{ 11 comments… read them below or add one }

Yves-Marie PONDAVEN novembre 28, 2009 à 6:10

Tu as oublié REST pour Representational State Transfer

Répondre

Christian novembre 28, 2009 à 6:51

Tu remarqueras que j’ai supprimé ton lapsus du premier commentaire .
Mais c’est vrai que « Sensational State Transfert », çà donne envie d’essayer 🙂

Sinon, oui, bien sûr REST. J’ai également regardé la thèse de Fieldling et je n’ai pas trouvé d’explication sur le choix de Transfert ou sur une distinction « architecturale » entre transfert et transport.

Répondre

karl novembre 28, 2009 à 10:15

REST est un style architectural qui est encore une couche au dessus de HTTP.
Je rejoins Christian dans son analyse. Chacun des domaines est d’ailleurs interprété en fonction de la culture propre des intervenants. Lorsque l’on SPDY de Google qui est une forme d’extension à HTTP. Ils ne s’intéressent proprement dit qu’à l’efficacité du transport et pratiquement pas à l’amélioration du transfert.

Google centralise tous les services dans une même coquille. Sa seule interaction au final n’est avec qu’avec les logiciels clients. L’interopérabilité avec les autres serveurs n’est presque pas un objectif à terme. Ils ont besoin de rapidité, ils ont des besoins spécifiques qu’ils maîtrisent au cœur de leurs applications. Lorsqu’on a créé un écosystème avec un fort contrôle sur tous les éléments du système, on peut se permettre d’imposer sa loi à l’écosystème. Microsoft l’a fait dans l’univers de la bureautique. Google le fait petit à petit pour le Web. Nous n’y sommes pas encore bien sûr.

Pour Google, le transfert n’est pas important ou plutôt il est si peu mis en pratique (quid de HTTP PUT, DELETE, etc., des mime types et des headers) sur le Web aujourd’hui, que Google peut se concentrer sur ce qui améliore le transport des données.

Répondre

Christian novembre 28, 2009 à 10:58

Je crois que ce qu’écrit Karl est très juste. Je crois aussi que cela va dans le sens de ton dernier billet sur SPDY, Yves-marie.
La compétition économique amène Google à consolider et à re-construire une architecture Client/Serveur distribuée en maîtrisant le client, les protocoles de transport, et bien sûr les serveurs. Google construit son WebFrame.

Répondre

Aurélien novembre 29, 2009 à 3:36

> »L’interopérabilité avec les autres serveurs n’est presque pas un objectif à term […]
Pour Google, le transfert n’est pas important ou plutôt il est si peu mis en pratique  »

Oui et non, google wave, le protocol pas l’interface vise l’intéropérabilité entre serveur.
Et Gdata l’API qui permet de manipuler une bonne partie des données stockées chez Google est construite sur Atom, le protocol la aussi et pas le format. Donc si ce n’est pas mis en pratique c’est notre faute pas celle de Google.

Répondre

Damien B novembre 30, 2009 à 11:54

Christian : intéressant ce modèle en couche, qui n’est pas le modèle OSI, d’où est-il issu ?

Aurélien : GData est construit sur le protocole et le format (mais la base est peu importante, vu que c’est pratiquement inutilisable sans un client dédié, c’est donc juste une facilité d’écriture du middleware), et GData ne permet d’accéder qu’à une minuscule partie des données stockées chez Google : les données publiques des services hébergés (de plus en plus restreint, cf. l’impossibilité de chercher les calendriers publics) et les données « privées » auxquelles le login donne accès. Au final, ça ne fait pas bezéf, comparé au trois dépôts de donnés principaux de Google (web indexé, Gmail et Deja). Et Google Wave en protocole serveur vise l’interopérabilité entre les serveurs… Wave. De même que NNTP assurait l’interopérabilité entre les serveurs News et IRCsp entre les serveurs IRC et CARP entre les serveurs de Cache. Bref, Wave ne rentre pas en ligne de compte dans cette discussion 🙂

Répondre

jadlat novembre 30, 2009 à 12:24

on postule aussi le transfert de compétences – je ne sais pas ce que cela donnerait du transport de compétences ?

Répondre

Christian novembre 30, 2009 à 5:05

> Christian : intéressant ce modèle en couche, qui n’est pas le modèle OSI, d’où est-il issu ?
N’est-ce pas ? 🙂 Je l’utilise pour simplifier, mais bien sûr il est faux

Répondre

Olivier G. novembre 30, 2009 à 5:27

Tiens, j’ai pour ma part envie d’aller voir du côté de la physique et plus particulièrement de la thermodynamique : « à où les protocoles de transports transportent des données, les protocoles applicatifs transfèrent des représentations. »

On peut rapprocher ça du transfert de chaleur entre deux matériaux, ou du transport de chaleur entre deux lieux. Encore une dichotomie transport d’information/transport de matière (le transfert de chaleur se fait sans intermédiaire matériel, le transport de chaleur nécessite un caloporteur — l’eau des radiateurs par exemple).

Répondre

Damien B novembre 30, 2009 à 9:52

N’est pas dans le sens où je n’ai jamais vu « Internet » en tant que couche 🙂

Répondre

karl décembre 4, 2009 à 5:19

Et pour avancer un peu plus dans le contrôle de la totalité de l’infrastructure.
http://code.google.com/intl/fr/speed/public-dns/docs/using.html

Répondre

Leave a Comment

{ 1 trackback }

Previous post:

Next post: