Disclaimer : je rappelle qu’il s’agit d’une page personnelle et les propos tenus sont les miens et non ceux de mon employeur. En particulier concernant ce post : j’ai souhaité parler d’une solution technique pour effectuer des appels téléphoniques depuis une connexion internet IP grand public telle que Starlink, et ce qui est présenté ici est du “best-effort” et n’est en théorie pas adapté aux communications d’urgence ou de sécurité, qui relèvent de la conformité au SMDSM

La disponibilité des services grand public tels que Starlink n’est absolument pas garantie de la même manière que les systèmes SMDSM (sans même parler de souveraineté). La pérennité à long terme n’est pas non plus garantie (la durée de vie moyenne d’un satellite en orbite basse est de ~5 ans. Il faut constamment envoyer de nouveaux satellites pour remplacer les anciens. Rien ne dit que le modèle économique de ces constellations soit viable à long terme)

Les bandes de fréquences de ces systèmes sont élevées (> 10 GHz), avec une disponibilité incertaine en cas de fortes intempéries (néanmoins les retours d’expérience terrain semblent montrer que Starlink est particulièrement fiable, même par gros temps)

Starlink/VSAT étant un dispositif de confort (non-SMDSM), il ne peut pas être connecté aux batterie de secours radio. Idem pour les équipements VoIP décrits plus bas.

la ligne SIP présentée plus bas n’est probablement pas garantie côté opérateur (je n’ai pas vérifié mais il est probable que les CGU d’OVH exluent explicitement les communications d’urgence et dise que le service peut tomber en panne…)

la solution SIP présentée plus bas n’est pas garantie côté terminal (un logiciel libre comme Linphone peut bugger/planter au pire moment, idem pour un système Android, idem pour l’OS et l’applicatif embarqué dans un Linksys PAP2T…). Rappelons aussi que tous ces équipements (téléphone IP ou boitier SIP) ne seront pas connectés aux batteries de secours radio (pas plus que Starlink).

Cliquer ici pour le contexte initial qui a motivé ce post

Contexte initial
En fait, en dépit du Disclaimer plus haut, ce post a été motivé initialement par une situation particulière concernant les communications d'urgence et de sécurité en Nouvelle Calédonie, car le COSS/MRCC (centre de secours) n'est pas équipé d'une station d'écoute MF/HF. En théorie, un navire émettant un message par ce biais peut être potentiellement entendu ailleurs (Fidji, Australie, ...) mais de manière incertaine en terme de propagation radio, et en ajoutant la barrière de la langue (même si un officier radio CGO parle normalement raisonnablement l'anglais).

Il semblerait qu’équiper le MRCC avec une station HF se chiffrerait en centaines de milliers d’euros, et si cela était avéré il est clair que ce budget est difficilement envisageable par les temps qui courent (surtout pour une technologie MF/HF sur le déclin). Dans le contexte économique difficile du territoire, les armateurs ayant fait le choix d’investir sur une solution MF/HF pour se conformer à leurs obligations ont besoin de temps pour migrer vers une solution Iridium. Il se trouve que ces navires sont souvent également équipés en VSAT ou en Starlink pour apporter de la connectivité internet de confort à l’équipage. L’usage n’est évidemment pas le même, mais l’idée est de regarder ce qui pourrait être facilement mis en place à très court terme pour disposer de communications téléphoniques “avec les moyens du bord” en cas de besoin et à côté / en plus des dispositifs SMDSM officiels.

Or Starlink/VSAT se contentent d’apporter une liaison internet/IP. Ils ne fournissent pas un service de bout en bout permettant d’effectuer un appel

Le COSS/MRCC a de son côté une infrastructure prévue pour enregistrer les communications depuis la VHF et le téléphone, mais pas depuis une messagerie internet telle que Whatsapp (peut-être qu’un jour le MRCC envisagera de mettre en place son propre proxy SIP (e.g. Asterisk / Yate) reliée à son infra de téléphonie, ou une solution tierce analogue à Whatsapp mais souveraine (e.g. Matrix / Jami / Janus…), mais pour l’heure ce qui suit visera à les joindre par téléphone. Ceci deviendra d’ailleurs trivial si l’OPT déploie un jour la VoWifi, mais ce n’est pas le cas à l’heure actuelle). On va donc regarder comment mettre en place une ligne téléphonique utilisable depuis n’importe quelle connexion IP - y compris Starlink - en répétant à nouveau que c’est du best-effort non garanti (cf. disclaimer plus haut. Si vous mettez en oeuvre la solution, vous en assumez la responsabilité !).

Une fois qu’on a dit tout ça, on va pouvoir entrer dans le vif du sujet :)

Solution VoIP

La mise en place d’une ligne téléphonique depuis une connexion internet IP a déjà été un peu explorée dans ce précédent post (à ceci près qu’ici la liaison IP est fournie par Starlink) et on va re-décrire rapidement la souscription à une liaison SIP. Je ne connais aucun fournisseur sur le territoire Calédonien proposant une offre adéquate, et je propose donc de s’appuyer sur l’offre OVH ci-dessous, qui permet d’obtenir un numéro métropolitain (avec des frais d’appel vers la Nouvelle-Calédonie qui sont d’après ma compréhension de 0.286 € / minute vers les fixes et 0.434 € / minute vers les mobiles. Bien sûr il est possible que des alternatives plus intéressantes existent mais c’est ce que j’ai trouvé de mieux à ce jour). Pour souscrire :

Créer un compte OVHcloud et souscrire à l’offre https://www.ovhcloud.com/fr/phone/voip/ (la moins chère coûte 1 € / mois hors frais de communication). J’ai personnellement rencontré des bugs/difficultés par le passé avec les autres méthodes que la CB donc je préconise de commencer par un paiement CB - peut-être est-ce résolu aujourd’hui. Cependant ceci implique une vigilance afin d’être certain de la continuité mensuelle du paiement, y compris au moment de l’expiration de la CB (la ligne sera coupée en cas de défaut de paiement !). Il est possible de choisir un numéro géographique e.g. commençant par 01, 02, … (ce qui permet d’ailleurs d’appeler la famille ou les amis en métropole en faisant la blague “devine d’où je t’appelle” ? :) ou un numéro neutre commençant par 09.
une fois cette offre souscrite, on obtient 1°/ un identifiant (qui est le numéro de téléphone au format international e.g. 00331234567890), 2°/ un identifiant de proxy (serveur mandataire), e.g. sbc6.fr.sip.ovh. 3°/ il faut se connecter à l’interface OVH pour créer/modifier le mot de passe SIP
Il faudra rentrer ces trois paramètres dans les réglages du terminal SIP choisi. Le terminal peut être un téléphone IP d’entreprise, ou un téléphone filaire classique branché sur une box VoIP (e.g. Linksys PAP2T, décrit sur cette page - bien penser à activer “NAT mapping” et “NAT keepalive”), ou une application SIP sur smartphone telle que Linphone (ou Jami ou BareSIP. Il y en a de nombreuses autres).

Une fois les réglages effectués, le navire / l’utilisateur dispose d’une ligne téléphonique pleinement fonctionnelle (localisée en métropole, mais permettant techniquement d’effectuer des appels depuis tout endroit du globe, et également d’être appelé) ! N.B. évidemment comme la ligne est située en métropole, il faut absolument penser à ajouter le préfixe +687 lorsqu’on souhaite joindre un correspondant situé en Nouvelle-Calédonie.

N.B. A priori je comprends que Starlink ne bloque pas les communications SIP/RTP, mais je n’ai pas accès à un terminal Starlink pour le confirmer. Si ce trafic était bloqué, il faudrait mettre en place un VPN. Je n’ai pas non plus eu l’opportunité de voir si des réglages additionnels étaient nécessaires e.g. sur le NAT (je mettrai à jour cette page si nécessaire).

Vibe-coding d’une appli Android

On arrive à l’autre partie qui a un peu motivé ce post : trouver un prétexte pour essayer Claude Code (tout le monde parle de vibe-coding en ce moment et j’étais curieux de voir ce que ça donne :). J’ai donc demandé à Claude d’écrire une application Android qui puisse s’apparenter au bouton “détresse” des systèmes SMDSM, i.e. d’envoyer (par mail, en l’occurence) en un clic rapide les informations d’identification du navire (MMSI), de position, et de degré de gravité de la situation.

J’ai pour cela créé un compte chez Anthropic, mis 5$ dans la machine, et tapé les 3 prompts suivants :

Can you create an android app that would have 1°/ settings (with fields "MMSI", "phone number", "target email"), 2°/ a main display that would show latitude/longitude/time from GPS, and a "SEND" button that would send an email to the aforementioned "target email" together with the MMSI, phone number, latitude, longitude, time informations
In the main window (above "send" button), can you add a combo box with the following options: ["ROUTINE", "SECURITE", "PANPAN", "MAYDAY"], and have the email include that choice both in the subject and in the body of the email ?
Can you add 1°/ an entry with "MRCC phone number" in the settings, and 2°/ on the main window, a button "call" that would trigger linphone (assuming linphone is previously pre-installed with the proper settings) in order to call the MRCC with the aforementioned MRCC phone number settings

C’était très impressionnant et l’application générée a compilé sous Android Studio et fonctionné du premier coup sans aucune retouche de ma part, aussi bien dans l’émulateur que sur un vrai téléphone (en récupérant correctement la latitude/longitude, en les insérant correctement dans l’e-mail envoyé, en déclenchant correctement un appel vocal via Linphone, etc.) ! Le résultat (code source et .apk) est disponible sur ce dépôt Github.

Je rappelle quand même que

il s’agit d’un proof-of-concept rapide, et je ne suis pas expert en programmation Android. L’appli peut très bien échouer à envoyer un mail, ou à récupérer les données GPS, etc.
l’application a été peu testée. Elle a été générée par IA. L’ensemble du code généré n’a pas été relu en détail (mais je le mets en open-source sous licence GPLv3 pour quiconque souhaite le vérifier)
comme le précise la licence GPL, l’utilisateur l’utilise à ses risques et périls, et sans aucune garantie (je suis bien sûr preneur de tout bug-report)

Digresssion sur la question de souveraineté

Cette première expérience plus haut avec le vibe-coding d’une appli Android m’amène à rappeler que

Anthropic (qui a créé Claude Code) est une société américaine, avec tout ce que ça implique par les temps qui courent. En particulier, le fait que le modèle d’IA fonctionne dans le cloud implique qu’il soit en capacité d’uploader la totalité de la base de code chez Anthropic (ce qui n’est pas grave ici puisque c’est Claude qui a généré l’ensemble du code, et de toute façon je l’ai placé sous licence GPL, mais ça pourrait être un problème avec des bases de code préexistantes et contenant par exemple des secrets industriels)
Les CGU peuvent changer à tout moment. Par exemple il semble désormais interdit d’utiliser Claude pour développer un concurrent (en comparaison : je ne crois pas que le CLUF de Visual Studio ait interdit à un quelconque moment de l’utiliser pour développer un concurrent à Visual Studio…). A mesure qu’on va devenir de plus en plus dépendant de ce type de technologie, il faudra prendre garde à ne pas s’inféoder à des sociétés qui pourraient nous dicter ce qu’on a le droit de développer ou non…
On donne un accès en lecture/écriture sur une partie du filesystem à l’agent IA, avec tout ce que ça peut comporter de risques

J’ai entendu beaucoup de bien de Mistral / Devstral. Je ferai un essai prochainement.