Quand l'IA entre dans le shack

Le vibe coding révolutionne-t-il les logiciels radioamateurs ?

RigPlane, SDR--, FoxSDR, IC-SDR, OrcSDR et AetherSDR : enquête sur une nouvelle génération de logiciels radio développés à une vitesse jusqu'ici inhabituelle.

Pendant longtemps, écrire un véritable logiciel radioamateur a exigé une combinaison assez rare de compétences : programmation système, traitement du signal (DSP), protocoles CAT, audio temps réel, USB, réseau, interfaces graphiques, connaissance fine des transceivers — et surtout, beaucoup de temps.

C'est l'une des raisons pour lesquelles le monde radioamateur s'est appuyé pendant des années sur un nombre relativement restreint de logiciels devenus incontournables : Hamlib, WSJT-X, fldigi, SDR#, HDSDR, SDR++, GNU Radio, SmartSDR, wfview, et quelques autres.

En 2026, quelque chose semble changer. En quelques mois apparaissent des logiciels extrêmement ambitieux, capables de gérer simultanément spectre, waterfall, CAT, audio réseau, modes numériques, ADS-B, AIS, satellites, télécommande web, DSP avancé — et parfois même le traitement complet d'un SDR directement sur un microcontrôleur.

Parmi eux : RigPlane, SDR--, FoxSDR, IC-SDR, OrcSDR et AetherSDR.

Ces six projets sont très différents. Certains contrôlent principalement un transceiver. D'autres sont des moteurs SDR généralistes. L'un transforme un ESP32-P4 en véritable appliance SDR autonome. Un autre cherche à remplacer une station SmartSDR complète. Mais ils partagent un point commun : leur vitesse de développement et leur ambition sont très éloignées de ce qu'un projet amateur individuel produisait généralement il y a encore quelques années.

Et c'est ici qu'intervient l'intelligence artificielle — pas comme simple autocomplétion de code, mais, pour certains de ces projets, comme un véritable collaborateur de développement.

1. Le phénomène le plus intéressant n'est pas l'IA : c'est la vitesse

Commençons par une observation simple. AetherSDR est probablement le cas le plus spectaculaire.

Le projet explique avoir démarré en mars 2026. Quelques mois plus tard, son dépôt affiche environ 2 700 commits, une intégration continue systématique, des commits signés, et un rythme revendiqué d'une cinquantaine de pull requests par semaine, en s'appuyant sur plusieurs outils IA — Claude Code, Codex, GitHub Copilot, Gemini, Aider, ainsi qu'un orchestrateur maison baptisé AetherClaude. Le projet résume lui-même la situation ainsi : une grande partie de la frappe est réalisée par des agents, mais les décisions d'architecture restent humaines, et rien n'atteint la branche principale sans revue humaine.

Ce contraste pourrait à lui seul devenir le fil conducteur de tout l'article.

La différence de rythme est considérable : là où un développeur solo enchaînait recherche de documentation, écriture, débogage, tests et packaging sur plusieurs semaines ou mois, un petit noyau humain peut désormais répartir ce travail entre plusieurs agents spécialisés, sous réserve que chaque changement passe par une intégration continue, des tests sur matériel réel et une revue humaine avant fusion.

2. « Vibe coding » ou développement assisté par agents ?

Cette distinction mérite d'être posée clairement, car elle change tout le jugement qu'on peut porter sur ces projets.

Le « vibe coding » est souvent caricaturé de façon minimaliste : on demande à une IA de produire un logiciel SDR, elle génère un programme, et celui-ci est publié tel quel — sans étape de vérification intermédiaire. Une telle approche serait évidemment très risquée appliquée telle quelle à du logiciel radio.

Un SDR combine en effet des exigences techniques peu tolérantes à l'approximation : synchronisation, threads temps réel, gestion USB, buffers IQ, FFT, filtrage numérique, AGC, modulation et démodulation, latence audio, contrôle matériel — et, potentiellement, émission RF. Une erreur de code n'y est donc pas seulement un bouton mal placé.

Les projets les plus sérieux de cette nouvelle génération sont précisément ceux qui associent l'IA à une discipline d'ingénierie établie : intégration continue, tests automatisés, revue humaine obligatoire, séparation explicite des fonctions d'émission. C'est cette discipline — plus que l'IA elle-même — qui détermine si le résultat est fiable.

3. AetherSDR : l'exemple le plus abouti d'un logiciel radio « AI-native »

AetherSDR mérite la section la plus développée. C'est une station logicielle native destinée notamment aux FlexRadio des séries 6000, 8000 et Aurora, fonctionnant nativement sous Linux, macOS et Windows (avec un build aarch64 utilisable sur Raspberry Pi). Le projet est écrit en Qt6 et C++20, parle directement le protocole SmartSDR, et vise à reproduire l'expérience complète d'une station SmartSDR : rendu GPU du spectre et du waterfall (réduction de charge CPU revendiquée d'environ 71 % par rapport à un rendu logiciel), plusieurs panadapters détachables avec tuiles waterfall VITA-49, une chaîne audio complète (gate, égaliseur, compresseur, de-esser, limiteur), et un pont — Aether-gate — permettant d'exposer des radios tierces (Icom, Kenwood, Yaesu via Hamlib, ou tout dongle SoapySDR) comme si elles étaient une FlexRadio.

Mais l'aspect réellement singulier de ce projet est sa méthode de développement. Le site du projet le qualifie explicitement de « AI-augmented open-source project ». L'environnement de travail s'appuie sur plusieurs outils IA en parallèle — Claude Code, Codex, GitHub Copilot, Gemini, Aider — coordonnés par un orchestrateur maison, AetherClaude, qui trie automatiquement les tickets entrants, rédige des plans d'implémentation et ouvre des pull requests pour les tickets qu'il juge éligibles. Chaque changement passe cependant par la même porte : commits signés, intégration continue au vert, revue par les responsables du code (CODEOWNERS) — quel que soit l'outil, humain ou IA, qui l'a produit. Le projet a même formalisé ses conventions dans une « Constitution » de quatorze principes, avec un fichier AGENTS.md que chaque assistant est censé lire en premier.

Le projet ne se contente d'ailleurs plus d'utiliser une IA pour écrire du code : il a construit une interface permettant à des agents d'observer et de piloter directement l'application elle-même.

Autrement dit, l'agent peut enchaîner modification, compilation, lancement, observation, action et vérification, sans intervention humaine à chaque étape. C'est sensiblement plus abouti qu'une simple génération de code par un assistant conversationnel.

4. RigPlane : refaire la couche de contrôle du transceiver

RigPlane prend une direction différente. Ce n'est pas un SDR généraliste, mais une nouvelle abstraction logicielle autour du contrôle des transceivers — anciennement connu sous le nom icom-lan avant de s'ouvrir à d'autres marques et de se renommer. Son cœur est écrit en Python/asyncio, avec une interface web servie directement au navigateur (pip install rigplane, puis rigplane web) et un pont compatible rigctld pour s'interfacer avec les logiciels existants.

Le point le plus intéressant de son architecture est ce modèle de capabilities. Plutôt que de tester « si la radio est un IC-7610, alors… », le code interroge des protocoles typés — ScopeCapable, AudioCapable, MeterCapable, StatePollable — que chaque backend implémente ou non. C'est une architecture nettement plus extensible que le branchement conditionnel classique, et elle permet à la même interface (Web UI, pont réseau rigctld, ligne de commande, scripts tiers) de fonctionner à l'identique sur n'importe quel backend qui honore ce contrat.

Le projet documente l'IC-7610 (double récepteur, LAN et USB CI-V) et l'IC-7300 comme plateformes stables et principales, le Yaesu FTX-1 comme stable également (17 modes, VHF/UHF, C4FM), et l'IC-705 comme validé par la communauté ; l'IC-9700, le Xiegu X6100 et le Lab599 TX-500 restent au stade de profils. Le dépôt revendique plus de 5 600 tests unitaires, avec des tests d'intégration visant WSJT-X, fldigi et JS8Call, et contient explicitement des fichiers .claude, CLAUDE.md et AGENTS.md ainsi qu'un mécanisme de revue assistée par agents. On peut donc parler ici d'un workflow agentique structuré, plutôt que d'affirmer sans nuance que le projet serait « 100 % vibe codé ».

5. SDR-- : transformer le SDR en Lego

SDR-- (parfois noté SDRMM ou sdrminusminus) est sans doute celui dont l'interface conceptuelle est la plus originale. Au lieu du modèle traditionnel linéaire — un flux IQ qui descend vers un VFO, une démodulation, puis l'audio — le logiciel propose de construire visuellement sa propre chaîne de traitement, nœud par nœud.

Le moteur de traitement du signal est écrit en Rust et tourne comme un serveur séparé, qui peut rester sur la même machine ou être déporté sur un ordinateur distant — un Raspberry Pi posté près de l'antenne, par exemple — pendant que l'interface, elle, s'utilise en application desktop ou directement dans un navigateur. Le projet annonce d'ores et déjà un support natif du RTL-SDR ainsi que des décodeurs pour ADS-B, AIS, POCSAG, FT8, SSTV et RDS, avec d'autres en cours d'ajout, un générateur de signaux intégré, et un dépôt de captures IQ prêtes à l'emploi pour tester les décodeurs. La feuille de route publique mentionne également, à terme, SSB, le scanning, l'identification de signaux, la localisation de source (direction finding), la cohérence multi-récepteurs et des fonctions de radar passif. Les releases, encore très récentes, couvrent Windows, Linux et macOS.

L'idée centrale mérite d'être formulée explicitement : SDR-- ne se présente pas comme « une application SDR », mais comme une plateforme de traitement RF programmable visuellement — une approche qui rapproche le projet de l'esprit de GNU Radio, tout en visant une expérience beaucoup plus orientée utilisateur final.

6. FoxSDR : réinventer le SDR généraliste

FoxSDR est également très ambitieux. Le projet est actuellement en bêta publique ouverte, écrit « from scratch » (sans reprendre de base de code existante), pour Windows dans un premier temps — un build Linux est en développement mais pas encore utilisable. Le logiciel propose spectre et waterfall, huit modes de démodulation (NFM, WFM, AM, DSB, USB, LSB, CW, et la réception stéréo FM avec RDS), squelch, AGC, réduction de bruit, notch manuel et automatique — et surtout une architecture de plugins.

Côté matériel, FoxSDR fournit ses propres pilotes (sans dépendre de SoapySDR) pour RTL-SDR, HackRF, Airspy R2/Mini et Airspy HF+, et passe par SoapySDR pour le reste (USRP, LimeSDR, SDRplay). Le catalogue de plugins de décodage couvre déjà un spectre impressionnant :

ADS-B · AIS · APRS · SSTV · NOAA APT · GOES HRIT · CW · RTTY · POCSAG · ACARS · satellites · VOR · WEFAX · balises de détresse 406 MHz · capteurs 433 MHz · Inmarsat-C · et d'autres encore, avec un catalogue qui reste amené à évoluer tant que le projet est en bêta.

L'autre originalité du projet est son interface distante intégrée en natif dans le navigateur, avec une parité de fonctionnalités annoncée entre le poste local et le contrôle à distance.

Le site du projet prend aussi une précaution assez rare dans ce paysage : il distingue explicitement les fonctions testées sur des signaux réels de celles qui n'ont été validées que sur des signaux synthétiques, et signale ouvertement lesquelles restent expérimentales. C'est précisément la bonne réponse à l'un des principaux problèmes du développement accéléré : une fonction qui compile n'est pas nécessairement une fonction RF qui fonctionne réellement sur l'air.

7. IC-SDR : une application complète apparue presque du jour au lendemain

IC-SDR intrigue pour une autre raison : la rapidité à laquelle il est apparu, déjà largement fonctionnel. Le projet est écrit en Go et cible Windows. Sa première version publique rassemble déjà dans une seule application les démodulateurs AM, NFM, WFM, LSB et USB, un waterfall et une analyse de spectre temps réel, un scanner de segments de fréquence à déclenchement instantané, un enregistreur audio avec suppression automatique des silences, un banc de mémoires, ainsi que des décodeurs pour AIS, ADS-B (1090 MHz et UAT 978 MHz), les radiosondes (RS41, DFM, M10/M20), l'APRS, le RTL_433 (capteurs et objets ISM, avec export CSV), le DMR, la SSTV, le TETRA, et une détection automatique multi-protocoles numériques (P25 I/II, NXDN, D-STAR, YSF, dPMR, ProVoice, M17, X2-TDMA) via DSD-neo.

Les versions suivantes, publiées à un rythme soutenu, ont déjà ajouté des outils satellites, de la cartographie, des calculs de distance et de locators, un profil de terrain avec analyse de zone de Fresnel, ainsi qu'une interface web pensée pour être utilisée depuis un téléphone. C'est typiquement le genre de projet qui, il y a quelques années, aurait nécessité une équipe et plusieurs mois rien que pour l'intégration de tous ces modules entre eux.

8. OrcSDR : le plus spectaculaire techniquement

OrcSDR mérite une section à part entière, car il fait quelque chose d'assez inhabituel : brancher directement un RTL-SDR sur un microcontrôleur ESP32-P4, sans PC, sans Raspberry Pi, sans système Linux caché derrière l'écran.

Le développeur (Erik Elfström) a construit un pilote USB « clean-room » permettant à l'ESP32-P4 de piloter nativement un RTL-SDR Blog V4 comme un périphérique embarqué à part entière, en s'appuyant sur trois transferts USB de 32 Kio en réception par callback. Une fois ce flux IQ soutenu par le microcontrôleur, ce pilote est devenu la fondation d'une radio complète : FFT, spectre et waterfall générés localement, audio FM large bande et bande étroite, une interface tactile organisée en tableaux de bord dédiés (FM, trunking P25, ADS-B, LoRa, outils RF, analyse Wi-Fi 2,4 GHz), et un connecteur ESP32-C6 embarqué qui fournit le Wi-Fi. Le matériel de référence — un M5Stack Tab5 à environ 60 USD écran et batterie compris — coûte sensiblement moins cher qu'un Raspberry Pi 5 seul aux prix actuels.

L'auteur présente ouvertement OrcSDR comme un projet réalisé avec une assistance IA importante, mais complétée par une validation extérieure explicite : rapports de bogues communautaires détaillés (modèle de récepteur, bande, antenne, réglage de gain, version d'OrcSDR, journal série), tests sur matériel réel, et un driver déjà validé aussi bien sur le M5Stack Tab5 que sur une carte de développement Waveshare ESP32-P4 distincte.

C'est peut-être l'exemple le plus parlant de ce que l'IA change réellement dans ce contexte : elle ne rend pas l'ESP32-P4 plus puissant. Elle réduit le coût humain nécessaire pour écrire, en parallèle, un pilote USB, un moteur DSP, une interface graphique, des décodeurs de protocoles, des tests et de la documentation — autant de briques qu'un seul développeur devait auparavant enchaîner successivement.

9. Six logiciels, six visions : le tableau comparatif

Ces six projets ne font surtout pas la même chose. Les confondre reviendrait à gommer ce qui les rend justement intéressants à observer ensemble.

Et une seconde lecture, tout aussi importante que la première : quel usage de l'IA est réellement documenté par chaque projet, par opposition à ce qui relève de la supposition.

Cette rigueur donne beaucoup plus de poids à l'ensemble : elle permet de parler d'une accélération réelle et documentée du secteur, sans prêter à chaque projet une origine qu'il ne revendique pas lui-même.

10. Ce que l'IA change réellement

C'est ici que l'article dépasse la simple revue de logiciels. Quatre transformations méritent d'être détaillées.

Un individu peut désormais attaquer des projets autrefois réservés à une équipe

Le logiciel radio combine énormément de disciplines différentes — USB, DSP, interface graphique, réseau, protocoles CAT, audio — qui exigeaient autrefois d'être maîtrisées simultanément par la même personne, ou de réunir une petite équipe aux compétences complémentaires. Un agent IA peut désormais fournir une compétence ponctuelle et de bon niveau dans chacune de ces zones, sous la supervision d'une personne qui comprend l'architecture d'ensemble.

Le temps entre l'idée et le prototype s'effondre

Là où une idée mettait auparavant des semaines à devenir un prototype fonctionnel, plusieurs agents travaillant en parallèle sur des sous-tâches bien délimitées peuvent ramener ce délai à quelques heures ou quelques jours — à condition, bien sûr, que le prototype passe ensuite par une phase de vérification sérieuse.

Les niches deviennent économiquement viables

Prenons un exemple volontairement très spécifique : un logiciel dédié à la combinaison IC-7610, Linux, contrôle distant, rotor RC-28 et intégration WSJT-X. Ce marché est minuscule comparé au logiciel grand public, et n'aurait probablement jamais justifié, seul, plusieurs mois de développement à temps plein. En réduisant fortement le coût de développement, l'IA rend ces micro-niches radioamateurs réellement développables.

L'utilisateur peut potentiellement devenir contributeur

AetherSDR pousse cette idée particulièrement loin : le projet explique qu'un radioamateur qui connaît bien son matériel peut désormais contribuer sans nécessairement maîtriser le C++, l'agent se chargeant de l'écriture pendant que l'opérateur vérifie le comportement radio réel. C'est peut-être le changement culturel le plus important de tous ceux évoqués ici.

11. Le risque : une IA ne possède pas de banc RF

C'est probablement le point qui mérite d'être poussé le plus loin techniquement. Un modèle de langage peut écrire une fonction qui calcule un rapport signal/bruit — mais il ne sait pas, par construction, si le résultat représente réellement le SNR de votre récepteur sur l'air. Il peut tout à fait implémenter un décodeur ADS-B, P25, DMR, TETRA ou RDS sans jamais avoir traité le moindre signal réel.

Il faut donc distinguer, au minimum, quatre niveaux de confiance très différents.

Plusieurs de ces projets apportent d'ailleurs, chacun à sa manière, un début de réponse à ce problème. FoxSDR distingue explicitement les fonctions testées « sur l'air » de celles qui n'ont été validées que sur des signaux synthétiques. SDR-- documente sa couverture de test et les limitations connues de ses décodeurs. OrcSDR insiste sur l'importance des captures IQ et de la validation sur matériel physique, avec des rapports de bogues structurés demandant explicitement modèle de récepteur, bande, antenne et gain. AetherSDR va jusqu'à construire une infrastructure permettant à des agents de tester automatiquement l'application, tout en maintenant une revue humaine à chaque étape.

L'IA augmente la quantité de code que l'on peut produire. Elle augmente donc, mécaniquement, la quantité de code qu'il faut ensuite être capable de vérifier.

12. La prochaine étape : piloter la station, pas seulement écrire le logiciel

Terminons par une projection. Aujourd'hui, la chaîne reste linéaire et à sens unique : un humain pilote un logiciel, qui pilote une radio. Demain, une partie de cette chaîne pourrait être déléguée à un agent orchestrateur, sous supervision humaine constante — en particulier pour tout ce qui touche à l'émission.

Une requête aussi simple que « cherche les ouvertures 2 m vers le nord, oriente l'antenne vers les balises actives et préviens-moi si une propagation apparaît » pourrait alors être traitée par un agent capable de consulter des sources en ligne comme PSK Reporter, de lire les spots publiés, de contrôler le rotor, de modifier le VFO, d'analyser le waterfall, de surveiller les balises, d'enregistrer l'IQ intéressant et de produire un rapport de synthèse.

Beaucoup des briques nécessaires existent d'ores et déjà, séparément : RigPlane fournit une couche de contrôle radio programmable et abstraite ; SDR-- expose de l'automatisation réseau et des chaînes de traitement construites visuellement ; AetherSDR expose déjà une partie de son interface à des agents et au protocole MCP. Rien ne garantit que ces briques convergeront exactement de cette façon — mais l'infrastructure nécessaire pour tenter l'expérience est, techniquement, déjà largement en place.

Nous sommes donc potentiellement au tout début de quelque chose de plus large que le simple vibe coding : la station radio programmable et pilotable par agents, avec l'émission comme frontière de sécurité clairement posée.

Conclusion

Le vibe coding ne va probablement pas remplacer GNU Radio, WSJT-X, Hamlib, ni les décennies d'expérience accumulées dans les logiciels radioamateurs existants. Mais il modifie radicalement une variable qui, jusqu'ici, limitait presque tout : le coût humain du développement logiciel.

Or le monde radioamateur est constitué de milliers de niches — chaque radio, chaque protocole, chaque mode numérique, chaque contrôleur, chaque besoin d'opérateur étant légèrement différent des autres. Dans un tel contexte, une réduction significative du coût de développement peut avoir un effet disproportionné par rapport à sa cause.

AetherSDR montre qu'une application native de plusieurs centaines de milliers de lignes peut aujourd'hui être développée avec une organisation largement agentique, sous gouvernance humaine explicite. OrcSDR montre qu'un expérimentateur individuel peut entreprendre seul un projet mêlant USB, DSP, microcontrôleur et protocoles radio, avec une assistance IA substantielle mais complétée de validation externe. RigPlane montre comment des architectures modernes de contrôle radio peuvent se construire autour d'API ouvertes et d'un workflow de développement clairement orienté agents.

À côté de ces trois cas documentés, SDR--, FoxSDR et IC-SDR témoignent eux aussi d'une accélération remarquable de l'innovation SDR — même si leurs auteurs ne revendiquent pas, dans les sources consultées pour cet article, une origine comparable en matière de développement assisté par IA.

La véritable transformation n'est donc probablement pas « l'IA sait écrire un logiciel radio ». Elle est plutôt : un radioamateur qui comprend correctement le problème peut désormais tenter de construire un logiciel qu'il n'aurait jamais eu le temps de développer seul.

Cela correspond d'ailleurs assez bien à l'esprit historique du radioamateurisme. Hier, on construisait son émetteur. Puis on a construit ses antennes. Puis ses interfaces numériques. Aujourd'hui, on peut commencer à construire son propre logiciel radio, assisté par des agents capables d'en écrire une partie à sa place.

Le shack, lui aussi, devient programmable.