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. C’est une architecture réseau développée à l’origine pour les communications spatiales : entre la Terre et une sonde interplanétaire, il n’existe jamais de chemin TCP/IP de bout en bout — les délais se comptent en minutes ou en heures, et la liaison peut couper sans prévenir (la Terre tourne, la sonde aussi). Le protocole central de ce monde, le Bundle Protocol, 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 — 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), 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.
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, et une liaison cellulaire de secours via un iPhone en partage de connexion, branché en USB. 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.
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.