Le voilier : un système d'information navigant

Au fil des années, l'électronique et l'informatique ont progressivement investi les voiliers. GPS, traceurs de carte, AIS, pilotes automatiques, capteurs de batterie : ces équipements se sont ajoutés les uns après les autres, au point que beaucoup de plaisanciers ont aujourd'hui abandonné les outils traditionnels (compas, sextant, carnet de bord papier) pour s'appuyer presque exclusivement sur leurs instruments électroniques. Le voilier moderne est devenu un vrai système d'information navigant.

Comme dans une entreprise, chacun de ces sous-systèmes remplit une fonction précise et fournit une information nécessaire, parfois critique, au pilotage et à la sécurité du bateau.

L'essentiel

  • Un voilier moderne combine navigation, pilotage, énergie, communication/sécurité et instrumentation : des sous-systèmes spécialisés qui reposent sur des protocoles distincts et ne communiquent pas nativement entre eux, comme les applications métier d'une entreprise.
  • Cette dépendance croissante à l'électronique impose deux réflexes complémentaires : consolider l'information pour disposer d'une vision d'ensemble, et anticiper la panne d'un système sur lequel on s'appuie sans plan de secours.
  • Plan de continuité (rester opérationnel pendant la panne) et plan de reprise (redémarrer sans réintroduire d'erreur) sont deux plans distincts ; le second est le plus souvent négligé dans la préparation.
  • Le protocole NMEA 2000 assure une interopérabilité de base entre instruments, mais l'unification reste incomplète au niveau applicatif, un projet ouvert comme Signal K illustre la trajectoire vers un modèle de données commun.

Les actifs critiques à bord

On peut regrouper ces systèmes en quelques classes d'actifs :

  • Navigation et positionnement : GPS, traceur de carte, récepteur AIS. Cette classe fournit la position du bateau et la connaissance du trafic environnant.
  • Pilotage : pilote automatique, compas électronique, capteur de barre. Cette classe maintient le cap et décharge l'équipage de la barre sur de longues distances.
  • Énergie électrique : batteries, régulateurs de charge, panneaux solaires ou éolienne, moniteur de batterie. Cette classe conditionne le fonctionnement de tous les autres systèmes électroniques du bord.
  • Communication et sécurité : VHF fixe et portable, balise de détresse (EPIRB, PLB), émetteur AIS. Cette classe permet d'alerter et d'être localisé en cas d'urgence.
  • Instrumentation environnementale : anémomètre, sondeur, loch de vitesse. Cette classe informe sur l'état de la mer et du fond, et alimente indirectement le pilote automatique et la navigation.

Ces classes reposent sur des capteurs et des protocoles distincts (NMEA 0183, NMEA 2000, ou propriétaire selon les marques), avec un niveau de criticité qui varie fortement : de la perte, gênante, d'un anémomètre à la perte de l'énergie électrique ou de la communication en mer, qui peut mettre en danger l'équipage.

Continuité et reprise d'activité : anticiper la panne en mer

La dépendance croissante aux systèmes électroniques révèle deux sujets complémentaires. Le premier consiste à regrouper et consolider l'information produite par ces éléments, pour disposer d'une vision d'ensemble cohérente du bateau. Le second consiste à anticiper les cas de panne ou de dysfonctionnement, puisqu'un système sur lequel on s'appuie exclusivement devient un point de rupture unique dès lors qu'aucun plan de secours n'existe.

En gestion des risques, on distingue deux plans qui préparent l'indisponibilité d'un système : le plan de continuité d'activité (PCA), qui permet de poursuivre l'activité pendant que le système est indisponible, et le plan de reprise d'activité (PRA), qui détaille comment redémarrer une fois le système à nouveau disponible.

Le plan de continuité : rester opérationnel malgré la panne

À bord, pour les systèmes les plus critiques (énergie, communication et sécurité, navigation), le PCA repose sur deux moyens. Le premier est la redondance : deux banques de batteries séparées, une VHF portable étanche en complément de la VHF fixe, une balise de détresse personnelle (PLB) en plus de l'EPIRB du bateau, un GPS de secours indépendant du traceur principal. Le second est le repli en mode dégradé, c'est-à-dire le retour temporaire aux méthodes traditionnelles : navigation à l'estime, relevé manuel de la position au compas et à la carte papier, tenue d'un livre de bord manuscrit. Ce repli s'apparente à un flux compensatoire : quand l'automatisme fait défaut, l'équipage reprend la main avec les moyens du bord.

Le plan de reprise : redémarrer sans réintroduire d'erreur

Le PRA, lui, intervient une fois le système principal réparé ou rechargé : recaler la position estimée avec le point GPS retrouvé, vérifier la cohérence des données après une coupure d'alimentation, resynchroniser le pilote automatique avec le compas. Cette étape est souvent négligée dans la planification, alors qu'une reprise mal maîtrisée peut réintroduire une erreur de navigation aussi sûrement que la panne initiale.

Ce plan de continuité comme ce plan de reprise reposent sur la capacité à détecter la dégradation avant la panne franche : une batterie qui perd sa capacité, un moteur dont les heures d'utilisation approchent l'échéance d'entretien. C'est là le rôle de la télémétrie, sujet qui sera abordé dans le second volet de cette série, consacré à son intégration dans la gestion de flotte de voiliers.

Cette distinction entre continuité et reprise ne concerne pas que la navigation : elle se pose exactement dans les mêmes termes pour toute application critique d'entreprise. Je l'ai détaillée dans un article consacré aux sauvegardes et aux pannes système →.

Vers une vision consolidée

Plusieurs approches cohabitent aujourd'hui pour regrouper et consolider l'information produite par ces différents systèmes. Les grands éditeurs d'applications et d'électronique pour voilier (Raymarine, B&G, Garmin) s'appuient sur un bus physique largement partagé, le standard NMEA 2000, ce qui permet déjà une interopérabilité de base entre équipements de marques différentes. L'ouverture reste en revanche plus limitée au niveau des applications et des interfaces logicielles, chaque éditeur ayant construit son propre écosystème d'affichage et de configuration. La trajectoire probable, à mesure que la demande de consolidation grandit, est une ouverture progressive à ce niveau applicatif également.

Le projet ouvert Signal K illustre cette trajectoire. Il traduit les principaux protocoles de bord (NMEA 0183, liaison série des instruments plus anciens ; NMEA 2000, réseau plus récent et plus rapide ; GPIO d'un Raspberry Pi, pour raccorder des capteurs non standards) dans un langage commun structuré autour du format JSON. Un serveur Signal K agit comme passerelle : il collecte les flux hétérogènes du bord et les rend accessibles à n'importe quelle application capable de s'y connecter (par exemple via une API HTTP ou WebSocket), indépendamment du fabricant d'origine des instruments.

Cette passerelle joue, à l'échelle du bateau, le rôle qu'un middleware joue entre les applications d'une entreprise : traduire des formats hétérogènes vers un langage commun, sans imposer de changer les instruments d'origine.

Conclusion

Le parallèle avec le système d'information d'une entreprise tient donc sur deux plans à la fois : la multiplication de sous-systèmes spécialisés qui ne communiquent pas nativement entre eux, et la nécessité de bâtir une continuité et une reprise d'activité face à la défaillance de l'un d'entre eux. Un modèle de données unifié comme Signal K répond au premier plan.

Cette unification technique pose une question qui dépasse la seule navigation. Une fois que les données du bateau existent sous une forme structurée et interrogeable, quel usage peut-on en faire au-delà de l'affichage en temps réel à bord ? La question de l'intégration avec des outils de gestion, de maintenance ou de planning de flotte devient alors pertinente. C'est l'objet du second article de cette série.

Ce constat vaut aussi pour un système d'information d'entreprise : silos applicatifs sans vision d'ensemble, absence de plan de continuité ou de reprise en cas de panne d'un applicatif critique. Si cette situation vous est familière, un Diagnostic complet peut clarifier les priorités. Vous pouvez me contacter pour en parler.

Questions fréquentes

En quoi un voilier est-il comparable au système d'information d'une entreprise ?
Un voilier moderne combine plusieurs sous-systèmes électroniques spécialisés (navigation, pilotage, énergie, communication, instrumentation) qui reposent sur des capteurs et des protocoles distincts et ne communiquent pas nativement entre eux. C'est la même situation que des applications métier (CRM, ERP, facturation, comptabilité) qui fonctionnent chacune correctement mais sans échange structuré entre elles.
Quelle est la différence entre un plan de continuité (PCA) et un plan de reprise (PRA) ?
Le plan de continuité d'activité (PCA) permet de poursuivre l'activité pendant qu'un système est indisponible, par exemple naviguer à l'estime le temps de retrouver un GPS en panne. Le plan de reprise d'activité (PRA) détaille comment redémarrer correctement une fois le système de nouveau disponible, sans réintroduire d'erreur au moment du redémarrage. Les deux plans sont complémentaires, mais le second est plus souvent négligé.
Le protocole NMEA 2000 suffit-il à unifier les données d'un voilier ?
NMEA 2000 assure une interopérabilité de base entre instruments de marques différentes, au niveau du bus physique. L'ouverture reste en revanche limitée au niveau des applications et des interfaces logicielles, chaque éditeur ayant construit son propre écosystème. Des projets ouverts comme Signal K traduisent les protocoles de bord dans un format commun pour rendre les données accessibles indépendamment du fabricant d'origine.
Ce parallèle avec la navigation s'applique-t-il vraiment à une PME sans lien avec le nautisme ?
Oui, sur les deux plans qui structurent l'article : la multiplication de sous-systèmes spécialisés qui ne communiquent pas nativement entre eux, et la nécessité d'anticiper la panne d'un système sur lequel on s'appuie sans redondance. C'est exactement la situation d'une PME avec un CRM, un ERP et un outil de facturation qui fonctionnent chacun correctement, mais sans flux structuré ni plan de continuité entre eux.