La plupart de mes projets vivent dans un onglet de navigateur, avec une connexion qui marche à peu près tout le temps. Celui-ci est né pour l’exact opposé : faire passer des données quand il n’y a aucune garantie qu’un chemin réseau complet existe à un instant donné. Le projet s’appelle Orion-DTN, son développement est aujourd’hui en pause — mais une partie du matériel construit pour lui vit toujours, au quotidien, chez moi à Orléans, où il me sert tout simplement de passerelle Internet avec mon iPhone branché dessus en source.
DTN : un réseau pensé pour les liaisons qui coupent
Le DTN (Delay/Disruption Tolerant Networking) n’a pas été inventé pour les box ADSL. L’idée remonte aux années 2000, à un constat posé par Vint Cerf (l’un des co-inventeurs de TCP/IP) et l’équipe du JPL (le laboratoire de propulsion de la NASA) : TCP/IP ne peut tout simplement pas fonctionner sur une liaison avec 40 minutes de latence aller-retour vers Mars. Il fallait un protocole capable de stocker des données indéfiniment, d’attendre qu’un lien soit disponible, et de reprendre la transmission exactement là où elle s’était arrêtée.
Le protocole central de ce monde, le Bundle Protocol — aujourd’hui normalisé par l’IETF sous la RFC 9171 — repose sur un principe tout simple : au lieu de supposer qu’une route complète existe maintenant, chaque nœud du réseau stocke les données puis les retransmet dès qu’une liaison redevient disponible. Chaque unité de transport, un bundle, est auto-décrite : elle porte ses propres métadonnées de routage et sa propre durée de vie, et peut traverser plusieurs sauts hétérogènes (WiFi, radio, Ethernet…) en étant stockée sur disque entre deux contacts, parfois plusieurs jours. Du store-and-forward, mais appliqué à l’échelle du réseau entier plutôt qu’à une seule boîte mail.
J’utilise l’implémentation de référence de la NASA/JPL, ION-DTN (Interplanetary Overlay Network), avec son transport sous-jacent LTP (Licklider Transmission Protocol, pensé lui aussi pour les liaisons à forte latence), ainsi que des éléments du cadre CCSDS (Consultative Committee for Space Data Systems) — le standard qu’utilisent les vraies agences spatiales pour le formatage de leurs trames radio. Fait amusant et un peu vertigineux : c’est exactement ce même code ION qui, côté NASA, a déjà fait transiter des données entre des sondes de l’espace profond et les antennes de Goldstone.
Pourquoi ce choix pour un projet qui n’a jamais quitté l’atmosphère ? Parce qu’un bateau de course au large partage, à son échelle, les mêmes symptômes qu’une sonde spatiale : connectivité intermittente, coûteuse, parfois totalement coupée pendant des heures (grain, zone d’ombre satellite, antenne masquée par la houle), et plusieurs liaisons possibles qui n’ont pas toutes la même fiabilité ni le même coût. Le projet Orion-DTN, conçu à l’origine pour un IMOCA, visait exactement ce terrain : garantir qu’une donnée émise à bord finit par arriver à terre, quelle que soit la liaison disponible au moment où elle est envoyée.
Deux nœuds, à l’image du vocabulaire spatial
L’architecture logicielle reprend sans complexe le vocabulaire du DTN spatial, même appliquée à un bateau : un nœud CM4 (sur une carte Raspberry Pi Compute Module 4, embarqué à bord) joue le rôle de « spacecraft », et un nœud Shore à terre joue le rôle de « ground station ». Les deux font tourner ION-DTN et s’échangent des « bundles » (l’unité de transport du Bundle Protocol) par n’importe quelle liaison disponible à l’instant T — un tunnel VPN quand une connexion IP classique existe, ou directement par radio quand il n’y a rien d’autre.
Cette seconde option radio est la plus proche de l’esprit spatial du projet : une liaison LoRa point-à-point, avec un firmware maison tournant sur des modules ESP32-S3 (Heltec Wireless Tracker), qui encode ses trames selon les conventions CCSDS plutôt qu’un protocole LoRa propriétaire. À portée et débit LoRa classiques — de l’ordre de quelques centaines d’octets par paquet, pas plus d’un paquet par seconde — de quoi faire remonter de la télémesure ou de petits messages même quand aucune autre liaison ne fonctionne, exactement comme le ferait un lien radio avec une sonde lointaine, juste à une échelle de quelques kilomètres plutôt que de quelques unités astronomiques.
Une passerelle multi-WAN qui bascule seule
Côté connectivité « normale », le nœud CM4 jongle entre plusieurs liaisons montantes selon leur priorité : une liaison filaire agrégeant une connexion satellite (type Starlink ou un autre service satcom maritime), une liaison WiFi locale (marina, gare, aéroport…), et une liaison cellulaire de secours via un iPhone en partage de connexion, branché en USB. Petit détail pratique : les portails captifs des WiFi publics sont détectés automatiquement, avec affichage d’une URL et d’un QR code pour s’authentifier directement depuis un smartphone, sans avoir à sortir un clavier. Le tout bascule automatiquement d’une liaison à l’autre selon sa disponibilité et le mode opérationnel choisi (au port, en mer avec large bande, en mer en mode restreint…), sans jamais casser le tunnel DTN ni le VPN qui tourne par-dessus — le but étant justement qu’une coupure d’une liaison ne se traduise jamais par une perte de données, seulement par un délai de plus avant que le prochain bundle ne parte.
L’usage le plus concret qui tourne sur cette architecture (au-delà de la télémesure) : un pont mail. Un message déposé à bord est mis en file, transporté en bundle DTN jusqu’à Shore dès qu’une liaison existe, puis relayé vers un vrai serveur SMTP. Rien de spectaculaire en apparence — mais c’est une belle démonstration que le store-and-forward n’est pas qu’une théorie d’article scientifique : un mail écrit à bord sans connexion finit toujours par partir, sans que personne n’ait besoin de réessayer manuellement.
Dans le même esprit, un second pont fait transiter des fichiers plutôt que des mails : un petit serveur FTP fait office de « dropbox » embarquée — tout fichier déposé dans son dossier de sortie est automatiquement encapsulé en bundle et envoyé vers Shore (jusqu’à 25 Mo par fichier), et les fichiers reçus en sens inverse apparaissent de leur côté avec un horodatage. De quoi faire remonter un rapport, une photo ou un journal de navigation sans jamais avoir à se soucier de l’état du lien au moment de l’envoi.
Tout ce qui aurait pu se greffer autour
Une fois la passerelle DTN posée, la liste de ce qu’on peut faire transiter dessus s’allonge vite. Quelques pistes qui étaient sur la table avant la pause du projet, certaines déjà testées, d’autres restées à l’état d’idée : des bulletins météo et fichiers GRIB poussés automatiquement vers le bord pour alimenter un logiciel de navigation, une passerelle vers le réseau radioamateur Winlink (entièrement indépendante de tout opérateur commercial), la synchronisation incrémentale des journaux de navigation, du reporting de position façon AIS, des mises à jour de cartes marines livrées en bundle, de petites alertes capteurs (niveau de cale, batterie…) avec télécommande en sens inverse, un cache de pages web consultables hors connexion, des mises à jour firmware différées pour les instruments embarqués — et, plus ambitieux, un maillage opportuniste entre plusieurs bateaux équipés, qui échangeraient leurs bundles directement entre eux dès qu’ils se croisent, sans même repasser par la terre.
Aujourd’hui : en pause, et recyclé à la maison
Le développement actif d’Orion-DTN est pour l’instant arrêté. Mais le boîtier CM4, lui, n’est pas resté sur une étagère : il tourne désormais chez moi, à Orléans, où je m’en sers comme passerelle réseau tout simplement — en y branchant mon iPhone en USB comme source Internet, exactement la même liaison cellulaire de secours qui, à bord, ne servait qu’en dernier recours. Ce qui était pensé comme le filet de sécurité le moins prioritaire d’un système de connectivité maritime est devenu, à la maison, la source principale — une reconversion qui n’aurait pas été possible sans tout le travail de bascule automatique entre liaisons déjà fait pour le bateau.
La partie DTN/ION à proprement parler, elle, est au repos : pas de bundles qui transitent, pas de liaison LoRa active. Mais l’infrastructure réseau qui tournait autour — la gestion multi-WAN, le basculement cellulaire, le tunnel VPN vers Shore — continue de prouver, au jour le jour et sans prétention spatiale, qu’un système construit pour encaisser l’absence de réseau fait aussi, très bien, un routeur Internet ordinaire quand on n’a besoin que de ça.