Summary

  • La série ordinaire Internet Talk Radio était préenregistrée et diffusée sous forme de fichiers. L’annonce de lancement disait que le FTP suffisait et précisait qu’IMS n’utilisait pas le MBONE pour ce service.
  • Le dispositif partait d’une production centrale et invitait des réseaux à relayer les copies via UUNET, des réseaux régionaux, EUnet, WIDE et IIJ. Il ne fournit ni inventaire complet des miroirs ni relevés de trafic.
  • Un spécial en direct avec NPR et le MBONE eut lieu séparément en mai 1993. Il ne transforme pas la série hebdomadaire « Geek of the Week » en diffusion continue.

Une annonce avant le premier fichier

Le 22 mars 1993, un message transmis à la liste de diffusion de RIPE reprenait le projet de Carl Malamud. Le service s’appelait Internet Talk Radio et devait commencer le 31 mars avec « Geek of the Week », une émission d’entretiens destinée aux acteurs des réseaux. L’archive conservée donne également le 31 mars comme date de sortie du premier épisode répertorié, un entretien avec Marshall T. Rose consacré notamment à OSI, X.400, à la politique de l’IETF et à SNMP version 2. L’annonce et la fiche de l’épisode décrivent une même activité en train de démarrer, plutôt qu’un récit rétrospectif lointain. Le message de la liste RIPE et la fiche de l’émission en donnent les preuves les plus directes.

Malamud présentait « radio » comme une métaphore. Le produit proposé était d’abord un enregistrement réalisé pour Internet. L’auditeur pouvait le récupérer, le conserver et le jouer à son rythme. L’annonce mentionnait le multicast comme une option pour le réseau qui recevrait le programme, puis posait une limite explicite : IMS n’utilisait pas le MBONE pour Internet Talk Radio. Autoriser un relais multicast ne signifie pas que l’émission elle-même est transmise en direct par multicast.

La différence modifie la scène initiale. Il n’était pas nécessaire que tous les auditeurs se connectent au même instant. Un fichier pouvait être placé sur un serveur régional, puis copié vers un système local ; chacun choisissait quand le télécharger et l’écouter. Le projet empruntait à la radio son rendez-vous éditorial, tout en donnant à l’utilisateur le contrôle du démarrage et de la lecture.

Un programme, plusieurs chemins dans le réseau

Le premier épisode devait durer environ une demi-heure. La note de mars estimait son volume à 15 mégaoctets en PCM standard, à 8 000 échantillons par seconde et en mu-law 8 bits. La présentation de Malamud à l’IETF traduisait ce codage en débit réseau, soit 64 kilobits par seconde, et décrivait plusieurs formats possibles. Dans un récit rétrospectif, le créateur évoque plutôt 30 mégaoctets pour une demi-heure. Ces chiffres ne sont pas des mesures interchangeables : le premier correspond à l’estimation de lancement pour un codage donné, le second à un souvenir ultérieur.

Aucun journal de transfert ni manifeste conservé ne permet d’établir une taille unique pour toutes les copies ; les deux valeurs restent donc attribuées à leurs sources.

La taille faisait du relais une composante de l’émission. L’annonce proposait un départ depuis UUNET, puis une distribution en éventail vers des réseaux régionaux pour éviter les transferts en double. Elle nommait mcsun chez EUnet comme premier point de stockage en Europe, WIDE et IIJ pour le Japon ; les clients d’Alternet pouvaient utiliser le FTP anonyme de UUNET. Les réseaux locaux étaient invités à contacter leur fournisseur, tandis que les fournisseurs pouvaient demander des instructions. Il s’agit d’un plan d’exploitation annoncé, pas d’un inventaire vérifié des miroirs actifs.

Les documents ne disent pas quels réseaux ont effectivement hébergé une copie, combien d’auditeurs ont utilisé chaque site ni quel volume a circulé.

L’archive d’IMS montre le service tel que les lecteurs pouvaient ensuite le consulter. Le premier « Geek of the Week » est découpé en sept fichiers audio, proposés en .au, .gsm et .ra. Les épisodes suivants apparaissent avec leurs dates et leurs invités. En 1994, l’index mentionne des entretiens avec des chercheurs et ingénieurs du réseau, dont Steve Crocker, Radia Perlman, Scott Bradner et Tim O’Reilly. L’archive conservait donc une grille éditoriale autant que des sons. Sa page servait de catalogue ; l’enregistrement restait un objet à récupérer dans un format que le système local savait lire. L’index de Geek of the Week conserve les dates, les invités et les formats.

Un fichier pouvait être placé là où le réseau pouvait le prendre en charge. La distribution dépendait moins d’un flux mondial unique, mais l’accès n’en devenait pas égal. À 64 kilobits par seconde, un fichier de 15 mégaoctets exige des heures sur une liaison comparable à un modem, avant même les retransmissions et les en-têtes. Le découpage en parties facilitait une récupération partielle ou une sélection ; il ne supprimait pas le coût des octets.

Un miroir régional pouvait éviter des trajets longue distance répétés lorsque les auditeurs téléchargeaient localement, mais les sources disponibles ne fournissent aucune mesure avant/après permettant de chiffrer l’économie.

« Multicasting » était une possibilité, pas une preuve

IMS signifiait Internet Multicasting Service, et la même organisation expérimentait le son en direct. Cela ne prouve pas que tous ses canaux employaient le même mode de diffusion. Une annonce distincte de mai 1993 décrit un épisode de « Science Friday » de NPR enregistré le 21 mai puis diffusé le 31 mai. Ce spécial associait la radio nationale en direct au MBONE et permettait à des participants sur Internet de poser des questions. Le message le situe sur le canal Internet Town Hall, séparé de la série ordinaire Internet Talk Radio. L’annonce archivée confirme cet événement synchrone et sa diffusion différée.

L’histoire ultérieure du service maintient cette distinction. L’archive d’IMS s’est enrichie d’événements du National Press Club, d’émissions d’affaires publiques, de TechNation, de contenus de la NASA et d’autres canaux. Un article du Washington Post en 1994 évoque des projets de flux en direct depuis la Chambre et le Sénat, en parallèle d’un service d’archives. Ces projets montrent qu’une organisation cherchait plusieurs usages pour le son ; ils ne changent pas la livraison initiale de « Geek of the Week ».

Les documents contemporains sont plus précis qu’une étiquette rétrospective : un service pouvait publier des fichiers, organiser des directs ponctuels et conserver les enregistrements.

L’annonce de lancement cherchait aussi à rassurer les réseaux soumis à leurs propres règles. Elle promettait de brèves mentions, à la manière de NPR, pour les sponsors Sun Microsystems et O’Reilly & Associates. Malamud disait que deux grands réseaux gouvernementaux au moins avaient indiqué que le service envisagé respectait leurs règles d’utilisation acceptable. Le message ne les nomme pas et ne reproduit aucune autorisation formelle. Il montre que la politique d’usage comptait pour le projet, mais ne prouve pas une dérogation générale.

Les diapositives de l’IETF décrivent aussi un régime de droits où les copies non commerciales pouvaient être illimitées tandis que les œuvres dérivées restaient restreintes. Copier un fichier audio était techniquement simple ; le droit de redistribuer chaque enregistrement dépendait encore de ses conditions.

Un dispositif de distribution, pas une promesse d’accès universel

L’expérience reliait une source éditoriale à de nombreux destinataires possibles. IMS choisissait et produisait l’émission ; les réseaux régionaux pouvaient choisir un protocole, un codage ou un point de stockage local ; les auditeurs choisissaient le moment du téléchargement. Le dispositif séparait la production de contenu des institutions qui le transportaient. Cette souplesse était un avantage technique, non la preuve que tous les réseaux concernés avaient autorisé le service ou que tous les auditeurs pouvaient y accéder.

Dans sa rétrospective, Malamud affirme que l’émission avait des auditeurs dans quelques dizaines de pays avant la fin de 1993 et utilisait alors beaucoup de bande passante. C’est un témoignage utile sur l’ambition du projet et la charge ressentie par son créateur, pas un décompte d’audience audité. L’annonce de lancement nomme des points régionaux sans inventorier les miroirs achevés ; l’archive prouve que des émissions et des liens vers plusieurs formats existaient, pas qu’un auditeur donné ait téléchargé une copie donnée. Le spécial de mai confirme un usage distinct du MBONE.

Aucun de ces faits ne fournit le dénominateur complet d’une audience.

Internet Talk Radio est important pour l’histoire d’Internet précisément pour cette raison. En 1993, « la radio sur Internet » ne signifiait pas obligatoirement un signal unique envoyé à une foule. Cela pouvait désigner un enregistrement converti en fichiers, relayé par des réseaux disposés à lui consacrer de la capacité et écouté selon l’emploi du temps de chacun.

Le modèle révélait des forces concrètes d’Internet — la copie, plusieurs formats, la coopération régionale et le contrôle de l’utilisateur — ainsi que ses limites : un gros fichier restait coûteux à récupérer, les droits devaient être négociés, et un plan de relais annoncé n’équivalait pas à une portée mesurée.

La conclusion la plus solide reste donc modeste. Internet Talk Radio a rendu un programme conçu pour Internet disponible sous forme d’enregistrements à récupérer, et ses responsables ont invité d’autres réseaux à participer à leur distribution. Les documents n’obligent pas à la proclamer première station, diffuseur universel ou précurseur certain d’un produit ultérieur. Ils montrent plutôt un service où le choix technique restait ouvert : envoyer un signal en direct ou laisser chaque destinataire décider quel fichier récupérer, depuis quel site et à quel moment.

Les documents qui précisent les limites

Les distinctions précédentes se vérifient dans l’annonce d’origine, les archives de programmes, le souvenir ultérieur du créateur et les documents distincts sur les événements en direct :