Deux personnes qui veulent se comprendre doivent d'abord s'accorder sur la façon de se parler. La langue employée,
l'ordre dans lequel on annonce les choses, la manière de dire "j'ai bien reçu". Entre machines, cet accord porte un
nom. On l'appelle un protocole, et c'est simplement un ensemble de règles que les deux parties respectent pour
échanger sans ambiguïté.
Rien ne vaut un exemple concret. Nous allons en prendre un et le garder tout au long de ce chapitre et des suivants,
l'envoi d'une lettre à ta grand-mère.
Une lettre pour mamie
Imagine que tu souhaites communiquer avec ta grand-mère bretonne par courrier pour lui demander sa recette de
crêpes.
Tu écris ta lettre en suivant votre protocole de communication "Salut mamie, file ta recette de crêpes, kenavo".
Pour que ta lettre arrive jusqu'à mamie, tu dois la déposer à la poste de ton village. Tu as là aussi un protocole à
respecter pour qu'ils acceptent de te rendre ce service, "place ta lettre dans une enveloppe avec un timbre, écris
ton adresse et l'adresse de destination".
Comme tu veux t'assurer de la bonne réception de ta lettre, tu l'envoies en recommandé.
Le bureau de poste veut envoyer la lettre vers un centre de tri. Ils ont entre eux aussi un protocole en place, "mets
la lettre dans un paquet avec toutes les autres lettres de la journée".
Pour acheminer le paquet, le bureau fait appel à un transporteur en respectant son protocole, "voici l'adresse du
centre de tri".
Ta lettre se retrouve sur la route jusqu'au centre de tri. Le centre déballe le paquet, regarde l'adresse sur la
lettre puis met la lettre dans un autre paquet à destination d'un autre centre.
Des services empilés les uns sur les autres
En résumé, pour obtenir le service "recette des crêpes", tu fais indirectement appel à d'autres services : bureau de
poste, centre de tri, transporteur.
Chacun utilise son propre protocole, et surtout, chacun ignore complètement ce que font les autres. Le transporteur
n'a jamais lu ta lettre, et toi tu ne sais pas par quelle autoroute elle est passée.
Ta lettre a été embarquée dans une enveloppe, puis dans un paquet, puis dans un camion. À l'arrivée, on déballe
dans l'ordre inverse jusqu'à ce que mamie tienne enfin ta demande de recette entre les mains.
Tu as ainsi accès à un réseau mondial. Ta grand-mère recevra ta lettre où que vous habitiez.
Cool, tu viens de comprendre comment fonctionne Internet ! 😎
Qui écrit les règles
Un protocole n'a d'intérêt que si tout le monde applique les mêmes règles. Elles sont donc écrites noir sur
blanc, dans des documents publics, numérotés et gratuits, que n'importe qui peut lire, les RFC, publiées par
l'IETF dont nous reparlerons dans le chapitre sur Internet. Il n'y a ni
brevet ni licence à payer pour les appliquer, et c'est une des raisons pour lesquelles Internet a pu grandir
aussi vite.
Cette ouverture a un revers, l'inertie. Changer une règle suppose que les deux camps changent en même temps,
sur toute la planète, sans casser ce qui marche. C'est pourquoi un protocole ne se remplace presque jamais, il
s'améliore par petites touches compatibles avec l'ancien. Tu comprendras mieux, en lisant les chapitres qui
suivent, pourquoi la nouvelle version des adresses IP met trente ans à
s'imposer et pourquoi le courrier électronique repose encore sur des règles des années 1980.
Tu entendras aussi le mot protocole en dehors du réseau, pour désigner le contrat d'une API, c'est-à-dire l'accord sur la façon dont deux logiciels se parlent. C'est la même idée, des règles fixées à l'avance pour que deux parties qui ne se connaissent pas se comprennent du premier coup.
Des milliers de protocoles
Il existe des milliers de protocoles, offrant tout autant de services : consultation de pages web, envoi d'emails,
transfert de fichiers, acheminement de données sans perte, protection des échanges contre les curieux...
Tu en croiseras beaucoup dans les chapitres qui suivent. Retiens surtout le principe, une communication réussie
n'est jamais un seul protocole, mais un empilement de protocoles qui se rendent service les uns aux autres. Cet
empilement a lui aussi un nom, et nous le détaillerons dans le chapitre sur le
modèle TCP/IP.
Au quotidien, tu croiseras ces noms dans un cahier des charges, ou quand un prestataire demande si tu préfères
recevoir les commandes "en SFTP ou par API". Il ne te demande pas de choisir une technologie, il te demande
par quel jeu de règles vos deux systèmes vont se parler, et la réponse dépend surtout de ce que ton équipe
sait déjà faire.