Un réseau chiffré de bout en bout, indépendant du support et de toute infrastructure

Topo technique : principes, architecture, outils et cas d’usage

Octobre 2026 Jean-Pierre Broillet Microclub

Vous avez aimé, vous aimez Meshtastic. alors cous aimerez peut-être RETICULUM…

Sommaire

Sommaire 2

1. En bref 3

2. Philosophie et principes de conception 3

2.1 Aucune infrastructure requise 3

2.2 Chiffrement obligatoire et identités auto-générées 3

2.3 Pas d’adresse source 4

2.4 Fonctionner sur des liens très lents 4

2.5 Indépendance vis-à-vis du support 4

3. Architecture technique 4

3.1 Destinations et adressage 4

3.2 Annonces et découverte de chemins 4

3.3 Nœuds de transport 5

3.4 Liens et ressources 5

3.5 Cryptographie 5

4. Interfaces et supports physiques 6

4.1 Les RNodes 6

4.2 Modes d’interface 6

5. Les outils en ligne de commande 6

6. L’écosystème applicatif 7

6.1 LXMF : la messagerie 7

6.2 LXST : la voix en temps réel 7

6.3 Les applications utilisateur 7

6.4 Implémentations alternatives 8

7. Démarrer en pratique 8

7.1 Installation 8

7.2 Exemple de configuration 8

7.3 Premiers usages 8

8. Comparaison avec d’autres approches 9

9. Limites et points de vigilance 9

10. Cas d’usage typiques 10

11. Pour aller plus loin 10

1. En bref

Reticulum (souvent abrégé RNS, pour « Reticulum Network Stack ») est une pile réseau complète, conçue pour construire des réseaux maillés résilients et chiffrés au-dessus de n’importe quel support physique capable de transporter quelques octets : une radio LoRa, un lien WiFi, un câble Ethernet, une liaison série, un modem de radio amateur ou même un tunnel à travers Internet. Elle ne remplace pas une application, elle remplace la couche réseau : là où l’on utiliserait habituellement IP, TCP et TLS, Reticulum fournit l’adressage, le routage, le chiffrement et le transport fiable en un seul ensemble cohérent.

Le projet est créé et maintenu par Mark Qvist. L’implémentation de référence est écrite en Python et s’installe en une commande (pip install rns). Après une longue phase bêta, la version 1.0.0 est sortie en juillet 2025, suivie de versions de maintenance de la série 1.x qui ont notamment ajouté la prise en charge des RNodes LoRa haute puissance et la connexion des RNodes en WiFi ou Ethernet.

Ce que Reticulum rend possible, concrètement :

• de la messagerie asynchrone avec stockage et retransmission (protocole LXMF) ;
• des transferts de fichiers de taille arbitraire, avec compression, découpage et vérification d’intégrité ;
• des appels vocaux en temps réel (protocole LXST) ;
• du shell distant et de l’exécution de commandes à distance (rnsh, rnx) ;
• des « sites » et forums consultables hors Internet (Nomad Network) ;
• de la télémétrie et du partage de position (Sideband).

2. Philosophie et principes de conception

2.1 Aucune infrastructure requise

Il n’existe pas de « réseau Reticulum » unique au sens où il existe un Internet unique. Reticulum est un protocole : n’importe qui peut monter son propre réseau, isolé ou interconnecté avec d’autres. Deux ordinateurs portables reliés par un câble, trois radios LoRa dans une vallée ou une communauté de nœuds connectés par TCP à travers le monde sont tous des réseaux Reticulum valides, et ils peuvent fusionner dès qu’un lien les relie.

2.2 Chiffrement obligatoire et identités auto-générées

Tout trafic vers une destination est chiffré par défaut ; il n’y a pas de mode « en clair » pour les communications privées. Chaque entité possède une identité composée de deux paires de clés sur courbes elliptiques : une clé X25519 pour l’échange de clés (chiffrement) et une clé Ed25519 pour les signatures, soit un ensemble de 512 bits. Aucune autorité ne délivre ces identités : chacun les génère localement.

2.3 Pas d’adresse source

Les paquets Reticulum ne contiennent pas d’adresse source. Un observateur qui capte un paquet peut voir vers quelle destination il va, mais pas qui l’a émis. C’est une propriété forte pour la vie privée, très différente d’IP où l’adresse d’origine figure dans chaque en-tête.

2.4 Fonctionner sur des liens très lents

Reticulum est conçu pour rester utilisable avec des débits extrêmement faibles (de l’ordre de quelques centaines de bits par seconde, voire moins) et des latences élevées. La MTU par défaut est de 500 octets, l’établissement d’un lien chiffré ne demande que trois paquets (quelques centaines d’octets au total), et le maintien d’un lien ouvert ne coûte qu’une fraction de bit par seconde. C’est ce qui rend la pile pertinente sur LoRa ou sur radio HF, là où TCP/IP serait inutilisable.

2.5 Indépendance vis-à-vis du support

Les applications ne savent pas, et n’ont pas besoin de savoir, par quel support passent leurs données. Un message peut quitter un téléphone en Bluetooth, traverser un lien LoRa de plusieurs kilomètres, passer par Internet en TCP puis finir sur un réseau local en WiFi, sans que l’application n’ait à s’en soucier.

3. Architecture technique

3.1 Destinations et adressage

Dans Reticulum, on ne s’adresse pas à une machine mais à une destination : un point de terminaison identifié par un hachage tronqué de 128 bits (16 octets), dérivé de l’identité et d’un nom d’aspect (par exemple lxmf.delivery pour une boîte de réception de messagerie). Un même appareil peut exposer plusieurs destinations, et une destination peut changer d’appareil ou de réseau physique tout en gardant la même adresse : l’adresse est liée à la clé, pas à la topologie.

Il existe plusieurs types de destinations : single (chiffrée vers une identité unique, le cas courant), group (clé symétrique partagée), plain (non chiffrée, pour la diffusion publique) et link (canal établi entre deux pairs).

3.2 Annonces et découverte de chemins

Pour être joignable, une destination émet une annonce : un paquet signé contenant sa clé publique et éventuellement des données applicatives. Les nœuds de transport propagent ces annonces et mémorisent, pour chaque destination, par quelle interface et quel voisin elle est atteignable. Personne ne connaît la topologie complète : chaque nœud sait seulement quel est le prochain saut. La propagation des annonces est plafonnée (par défaut à environ 2 % de la bande passante d’une interface) pour éviter qu’elles ne saturent les liens lents.

Si un nœud ne connaît pas encore de chemin vers une destination, il peut émettre une requête de chemin ; un nœud qui connaît la réponse renvoie l’annonce correspondante.

3.3 Nœuds de transport

Tous les nœuds ne routent pas. Par défaut, une instance Reticulum est un simple point d’extrémité. Une instance configurée avec enable_transport = Yes devient un nœud de transport : elle relaie les paquets et les annonces pour les autres. On active typiquement ce mode sur des machines fixes et bien connectées (un Raspberry Pi avec une RNode sur un toit, un serveur passerelle entre LoRa et Internet), pas sur un téléphone mobile.

3.4 Liens et ressources

Un link est un canal virtuel chiffré et vérifié entre deux destinations, établi par un échange Diffie-Hellman éphémère : chaque lien a ses propres clés, ce qui assure la confidentialité persistante (forward secrecy). Une fois le lien ouvert, on peut y envoyer des paquets, faire des requêtes de type requête/réponse, ou transférer des ressources.

Une ressource est un bloc de données de taille quelconque (fichier, image, page) que Reticulum se charge de compresser, découper, séquencer, acheminer, réassembler et vérifier. C’est la brique sur laquelle reposent les transferts de fichiers.

3.5 Cryptographie

Ces primitives sont classiques et éprouvées ; l’originalité de Reticulum tient à leur assemblage et à leur sobriété en octets, pas à de la cryptographie nouvelle. À notre connaissance, le protocole n’a pas fait l’objet d’un audit de sécurité indépendant publié, ce qui est un point à garder en tête pour des usages sensibles.

4. Interfaces et supports physiques

Reticulum se branche sur les supports via des interfaces, déclarées dans le fichier de configuration ~/.reticulum/config. Une même instance peut utiliser plusieurs interfaces simultanément et router entre elles.

4.1 Les RNodes

Une RNode est un émetteur-récepteur LoRa générique, ouvert, qui fonctionne avec un micrologiciel dédié. On peut en fabriquer une à partir de cartes de développement courantes et bon marché (familles LilyGO T-Beam, T3S3, Heltec, etc.) en flashant le firmware avec l’utilitaire rnodeconf. LoRa offre des portées de plusieurs kilomètres en terrain dégagé (bien davantage avec des antennes en hauteur) au prix de débits faibles, de quelques centaines de bits à quelques dizaines de kilobits par seconde selon les paramètres.

4.2 Modes d’interface

Chaque interface peut recevoir un mode qui influence la façon dont les annonces et les chemins sont gérés : full (par défaut), gateway (une passerelle qui résout les chemins pour ses clients), access_point (point d’accès pour clients mobiles, avec des chemins à durée de vie courte), roaming (interface physiquement mobile) et boundary (frontière entre deux segments de réseau très différents, par exemple entre Internet et un réseau LoRa local).

5. Les outils en ligne de commande

Le paquet rns fournit un ensemble d’utilitaires qui couvrent l’administration du réseau et plusieurs usages directs :

Le shell distant interactif est fourni par un projet séparé, rnsh, qui offre une session de terminal complète (à la manière de SSH) à travers Reticulum, utilisable même sur un lien LoRa.

6. L’écosystème applicatif

6.1 LXMF : la messagerie

LXMF (Lightweight Extensible Message Format) est le protocole de messagerie de l’écosystème. Il gère la livraison directe quand le destinataire est joignable, et la livraison différée via des « propagation nodes » : des nœuds qui stockent les messages chiffrés et les remettent quand le destinataire réapparaît, à la manière d’un serveur de courrier mais sans pouvoir lire le contenu. LXMF permet même des « messages papier » encodés en QR code ou en lien, transportables physiquement.

6.2 LXST : la voix en temps réel

LXST est le protocole et le framework de transport audio et de signaux en temps réel au-dessus de Reticulum. Il alimente les appels vocaux de Sideband et inclut rnphone, un utilitaire de téléphonie en ligne de commande capable aussi de piloter de vrais combinés téléphoniques matériels. Les codecs utilisés s’adaptent à la bande passante disponible, mais une conversation fluide demande évidemment plus de débit qu’un message texte : sur LoRa, il faut des réglages radio rapides et des liaisons courtes.

6.3 Les applications utilisateur

6.4 Implémentations alternatives

L’implémentation Python reste la référence, mais plusieurs réimplémentations compatibles au niveau protocole sont apparues, souvent pour gagner en performance ou viser l’embarqué : Reticulum-Go (Go, avec une cible WebAssembly pour le navigateur), des implémentations en Rust (par exemple Leviculum, compatible avec les outils Python et visant aussi les microcontrôleurs nRF), et une pile Kotlin expérimentale utilisée en option par Columba. Leur maturité varie ; pour un premier déploiement, la version Python reste le choix le plus sûr.

7. Démarrer en pratique

7.1 Installation

pip install rns # ou : pipx install rns

rnsd # premier lancement : crée ~/.reticulum/config

rnstatus # vérifier les interfaces actives

Au premier lancement, la configuration par défaut active l’AutoInterface : deux machines sur le même réseau local se trouvent donc automatiquement, sans rien régler.

7.2 Exemple de configuration

Extrait de ~/.reticulum/config combinant le réseau local, un lien Internet vers un nœud distant et une radio LoRa :

[reticulum]

enable_transport = Yes

[interfaces]

[[Reseau local]]

type = AutoInterface

enabled = yes

[[Lien Internet]]

type = TCPClientInterface

enabled = yes

target_host = noeud.exemple.org

target_port = 4242

[[Radio LoRa]]

type = RNodeInterface

enabled = yes

port = /dev/ttyUSB0

frequency = 868000000

bandwidth = 125000

txpower = 14

spreadingfactor = 8

codingrate = 5

7.3 Premiers usages

rnid -g ~/.reticulum/mon_id # générer une identité

rncp -l # écouter pour recevoir des fichiers

rncp rapport.pdf <hash_destination> # envoyer un fichier

rnx <hash_destination> « uptime » # exécuter une commande à distance

rnprobe rnstransport.probe <hash> # tester l’accessibilité

Pour la messagerie, le plus simple est d’installer Sideband ou MeshChat sur deux appareils et d’échanger les adresses LXMF (affichées sous forme de hachage ou de QR code).

8. Comparaison avec d’autres approches

Meshtastic et Reticulum sont souvent comparés parce qu’ils utilisent le même type de matériel LoRa, mais ils ne jouent pas dans la même catégorie : Meshtastic est un produit de messagerie simple et populaire, Reticulum une fondation réseau généraliste sur laquelle on construit des applications. Les deux ne sont pas interopérables nativement.

9. Limites et points de vigilance

• Réglementation radio : le chiffrement est interdit sur les bandes radioamateur dans la plupart des pays, ce qui limite l’usage de Reticulum chiffré sur ces fréquences. Sur les bandes ISM LoRa en Europe (863-870 MHz), les règles de rapport cyclique (souvent 1 %, parfois 10 % selon la sous-bande) et de puissance maximale s’appliquent et limitent fortement le trafic utile.
• Débit : la voix et les gros fichiers fonctionnent bien sur WiFi ou Ethernet, mais sur LoRa il faut rester réaliste. Envoyer une photo peut prendre plusieurs minutes, et une conversation vocale suppose des paramètres radio rapides et des liaisons courtes.
• Performance de l’implémentation : écrite en Python, la référence est moins performante qu’une pile native sur du matériel modeste ou pour des nœuds à fort trafic, d’où l’intérêt des réimplémentations Go et Rust.
• Sécurité : primitives solides et conception soignée, mais pas d’audit indépendant publié à notre connaissance, et une base d’utilisateurs encore modeste.
• Licence : l’implémentation de référence est publiée sous la « Reticulum License », dérivée d’une licence permissive mais avec des restrictions d’usage (par exemple pour les systèmes conçus pour nuire à des personnes). Ce n’est donc pas une licence open source au sens strict de l’OSI ; à vérifier avant tout usage commercial ou institutionnel.
• Communauté et documentation : la documentation officielle est très complète, mais l’écosystème reste porté par un nombre restreint de contributeurs, avec un rythme de développement qui dépend fortement de son créateur.

10. Cas d’usage typiques

• Communications de secours lors de catastrophes ou de coupures d’Internet et du réseau mobile.
• Zones isolées : refuges, exploitations agricoles, expéditions, bateaux, chantiers, où l’on veut relier quelques sites sans abonnement.
• Résistance à la censure et vie privée : réseaux communautaires indépendants des opérateurs, absence d’adresses source, transport possible via I2P.
• Télémétrie et IoT : remontée de capteurs sur de longues distances avec des liens très sobres.
• Administration à distance de machines hors réseau via rnsh ou rnx à travers une liaison radio.
• Expérimentation pour radioamateurs, hackers et chercheurs en réseaux, grâce à l’interface Pipe qui permet d’inventer de nouveaux transports.

11. Pour aller plus loin

Le manuel officiel (markqvist.github.io/Reticulum/manual) est la référence : il détaille le protocole, la configuration de toutes les interfaces et l’API Python. Le dépôt GitHub markqvist/Reticulum héberge le code, le journal des versions et les discussions de la communauté. Les dépôts markqvist/LXMF, markqvist/LXST, markqvist/Sideband et markqvist/NomadNet couvrent les principales applications, et markqvist/RNode_Firmware le micrologiciel radio.

Arduino Uno + deux transducteurs HC-SR04

Jean-Pierre Broillet septembre 2026

Étude, câblage, calibration et programme C++ documenté

Projet expérimental d’un instrument électronique sans contact

1. Objet du projet

Le but est de réaliser un thérémine numérique avec un Arduino Uno et deux capteurs ultrasonores HC-SR04. Un capteur mesure la position d’une main pour commander la hauteur du son (pitch), tandis que le second commande le volume. Contrairement au thérémine historique, qui exploite la variation de capacité créée par les mains à proximité d’antennes radiofréquences, cette réalisation mesure directement des distances.

C’est aussi un instrument difficile à maîtriser, car le musicien ne dispose d’aucun repère physique pour placer ses notes.

L’intérêt pédagogique est important : acquisition ultrasonore, filtrage numérique, conversion d’une grandeur physique en paramètre musical, temporisation, génération audio et amplification.

Une virtuose du thérémine :

https://www.youtube.com/watch?v=lY7sXKGZl2w&list=RDlY7sXKGZl2w&start_radio=1

2. Architecture générale

Les deux capteurs doivent être suffisamment séparés et, si possible, orientés selon des axes différents. Cela diminue les risques qu’un HC-SR04 reçoive l’écho de l’impulsion émise par l’autre.

3. Composants proposés

• 1 × Arduino Uno
• 2 × HC-SR04
• 1 × petit amplificateur audio (LM386 ou module équivalent recommandé)
• 1 × haut-parleur 8 Ω
• 1 × bouton-poussoir CALIBRATION (évolution recommandée)
• 1 × bouton-poussoir MUTE (évolution recommandée)
• Résistances, condensateurs de découplage, plaque d’essai et alimentation 5 V adaptée

4. Affectation des broches

5. Schéma électrique de base

Important : ne pas brancher directement un haut-parleur de 8 Ω sur une sortie de l’Arduino. La broche ne peut pas fournir le courant nécessaire. Pour les premiers essais, un étage transistor peut suffire, mais un LM386 ou un petit amplificateur audio est préférable.

6. Séquencement des mesures ultrasonores

Les deux HC-SR04 ne doivent pas être déclenchés simultanément. Une mesure Pitch est effectuée, puis une temporisation est respectée avant la mesure Volume. Un capteur pourrait recevoir l’écho de l’impulsion émise par l’autre et donner une distance totalement fausse.

Une attente d’une trentaine de millisecondes constituent un bon point de départ pour le prototype.

7. Conversion de la distance en hauteur musicale

C’est ici que le projet devient intéressant.

Une conversion simplement linéaire, par exemple :

fonctionnerait, mais serait musicalement médiocre, parce que notre perception des hauteurs est logarithmique.

Il vaut mieux travailler par octaves :

avec

et N le nombre d’octaves.

et quatre octaves donnent :

C’est beaucoup plus naturel à jouer.

8. Filtrage des HC-SR04

Les mesures brutes peuvent varier de quelques millimètres à quelques centimètres, ce qui devient immédiatement audible sous forme de vibrato parasite.

Je propose donc un filtre exponentiel :

avec :

Une petite valeur donne un instrument très stable mais plus lent ; une grande valeur donne un instrument vif mais plus nerveux.

C’est donc un paramètre que je mettrais explicitement dans le programme.

9. Commande du volume

Pour le capteur Volume, la convention retenue est : main proche = silence, main éloignée = volume maximal. Dans la première version utilisant tone(), le niveau calculé sert surtout de seuil marche/arrêt. Une version évoluée utilisera une véritable modulation d’amplitude ou une sortie PWM filtrée.

10. Programme C++ complet – version de test

/*

================================================================

THEREMINE A ULTRASONS – Arduino UNO + 2 x HC-SR04

HC-SR04 n°1 : hauteur (PITCH)

HC-SR04 n°2 : volume

================================================================

*/

#include <Arduino.h>

#include <math.h>

const byte TRIG_PITCH = 7;

const byte ECHO_PITCH = 8;

const byte TRIG_VOLUME = 9;

const byte ECHO_VOLUME = 10;

const byte AUDIO_PIN = 3;

const float DIST_MIN = 5.0; // cm

const float DIST_MAX = 50.0; // cm

const float FREQ_MIN = 110.0; // Hz

const float NB_OCTAVES = 4.0;

const float ALPHA = 0.20;

float distancePitchFiltree = 25.0;

float distanceVolumeFiltree = 25.0;

float mesurerDistance(byte trigPin, byte echoPin)

{

digitalWrite(trigPin, LOW);

delayMicroseconds(3);

digitalWrite(trigPin, HIGH);

delayMicroseconds(10);

digitalWrite(trigPin, LOW);

// Timeout afin d’éviter un blocage si aucun écho n’est reçu.

unsigned long duree = pulseIn(echoPin, HIGH, 30000UL);

if (duree == 0)

return -1.0;

// Vitesse du son ≈ 0,0343 cm/us ; division par 2 : aller-retour.

return duree * 0.0343 / 2.0;

}

float limiter(float valeur, float minimum, float maximum)

{

if (valeur < minimum) valeur = minimum;

if (valeur > maximum) valeur = maximum;

return valeur;

}

float distanceVersFrequence(float distance)

{

distance = limiter(distance, DIST_MIN, DIST_MAX);

// Main proche -> x = 1 ; main éloignée -> x = 0.

float x = (DIST_MAX – distance) / (DIST_MAX – DIST_MIN);

// Loi exponentielle correspondant à NB_OCTAVES octaves.

return FREQ_MIN * pow(2.0, NB_OCTAVES * x);

}

int distanceVersVolume(float distance)

{

distance = limiter(distance, DIST_MIN, DIST_MAX);

// Main proche -> silence ; main éloignée -> maximum.

float x = (distance – DIST_MIN) / (DIST_MAX – DIST_MIN);

return constrain((int)(255.0 * x), 0, 255);

}

void setup()

{

pinMode(TRIG_PITCH, OUTPUT);

pinMode(ECHO_PITCH, INPUT);

pinMode(TRIG_VOLUME, OUTPUT);

pinMode(ECHO_VOLUME, INPUT);

pinMode(AUDIO_PIN, OUTPUT);

Serial.begin(115200);

Serial.println(« Theremine ultrasonique – initialisation »);

}

void loop()

{

// Mesure du capteur de hauteur.

float dPitch = mesurerDistance(TRIG_PITCH, ECHO_PITCH);

if (dPitch > 0)

distancePitchFiltree =

ALPHA * dPitch + (1.0 – ALPHA) * distancePitchFiltree;

// Séparation temporelle des émissions ultrasonores.

delay(30);

// Mesure du capteur de volume.

float dVolume = mesurerDistance(TRIG_VOLUME, ECHO_VOLUME);

if (dVolume > 0)

distanceVolumeFiltree =

ALPHA * dVolume + (1.0 – ALPHA) * distanceVolumeFiltree;

float frequence = distanceVersFrequence(distancePitchFiltree);

int volume = distanceVersVolume(distanceVolumeFiltree);

// Première version : tone() produit une onde carrée.

// Le volume est ici utilisé comme seuil d’activation.

if (volume > 10)

tone(AUDIO_PIN, (unsigned int)frequence);

else

noTone(AUDIO_PIN);

// Informations de mise au point sur le PC.

Serial.print(« Pitch : « );

Serial.print(distancePitchFiltree, 1);

Serial.print( » cm F = « );

Serial.print(frequence, 1);

Serial.print( » Hz Volume : « );

Serial.print(distanceVolumeFiltree, 1);

Serial.print( » cm Niveau = « );

Serial.println(volume);

delay(10);

}

11. Mais je modifierais ensuite la génération sonore

tone() est excellent pour vérifier le fonctionnement, mais pas pour obtenir un beau thérémine. Il produit essentiellement une onde carrée riche en harmoniques impaires.

Le projet devient beaucoup plus intéressant avec cette chaîne :

On pourrait générer une onde triangulaire ou une combinaison sinusoïde + harmoniques donnant un timbre beaucoup plus agréable.

12. Le « calage » que je recommande

C’est même un point que je considère essentiel.

Plutôt que d’imposer définitivement 5 et 50 cm dans le programme, le thérémine devrait posséder une procédure de calibration.

Au démarrage :

On peut ajouter deux boutons-poussoirs, ou mieux encore un bouton CALIBRATION et utiliser le moniteur série pour guider l’utilisateur.

Je verrais volontiers :

Le bouton MUTE serait particulièrement pratique : un thérémine sans moyen simple de couper le son devient vite pénible pendant les essais.

13. Une amélioration très importante

Il faudrait séparer mesure, traitement et production audio.

Dans le programme précédent, pulseIn() est bloquant. Cela suffit pour une démonstration, mais ce n’est pas idéal pour un véritable instrument.

La version évoluée pourrait fonctionner ainsi :

La génération sonore par Timer1 avec accumulateur de phase serait nettement supérieure : l’audio continuerait à être généré régulièrement pendant les calculs et les acquisitions.

14. Architecture finale

Arduino Uno + 2 HC-SR04 + bouton CALIB + bouton MUTE + sortie audio PWM + filtre RC + LM386 + haut-parleur 8 Ω.

Et surtout, je ferais évoluer le logiciel en trois étapes : d’abord la version tone() ci-dessus pour valider la géométrie et les capteurs ; ensuite une version avec vrai contrôle continu du volume ; enfin une version avec DDS/Timer, forme d’onde travaillée et calibration automatique.

Cette dernière version serait un véritable petit instrument numérique et non plus seulement une démonstration HC-SR04. Elle permettrait même d’ajouter ultérieurement vibrato, choix du timbre, changement du nombre d’octaves et quantification facultative sur les notes de la gamme.

L’accumulateur de phase

L’accumulateur de phase est une technique numérique très élégante pour fabriquer un signal périodique de fréquence précise. Dans notre thérémine, il permettrait de remplacer avantageusement tone().

Le principe

Imaginez un tour complet de cercle correspondant à une période du signal :

À chaque « tic » d’une horloge très régulière, on avance d’une certaine quantité sur ce cercle. Cette position est la phase.

On utilise donc une variable entière :

C’est cette variable phase que l’on appelle accumulateur de phase.

Plus increment est grand, plus on fait rapidement le tour, donc plus la fréquence sonore est élevée.

Exemple très simple

Supposons arbitrairement un accumulateur allant de 0 à 255.

Avec un incrément de 1 :

Il faut 256 coups d’horloge pour effectuer une période.

Avec un incrément de 4 :

Il ne faut plus que :

256/4 = 64

coups d’horloge pour une période.

La fréquence est donc quatre fois plus élevée.

Relation mathématique

Avec un accumulateur de phase de N bits possède :

2^N

états.

Si la fréquence d’échantillonnage est Fs et l’incrément de phase vaut K, la fréquence générée est :

Prenons par exemple un accumulateur 32 bits et une interruption audio à :

F_S = 31250Hz

Pour produire le La à 440 Hz :

K = 440 x 2³²/31250

ce qui donne environ :

Cela paraît énorme, mais pour un microcontrôleur ce n’est qu’un entier 32 bits.

Pour quelle raison, c’est mieux que tone() ?

tone() est pratique pour un prototype, mais l’accumulateur de phase permet de contrôler indépendamment fréquence, amplitude et forme d’onde. On peut ainsi produire une sinusoïde, un triangle, un signal enrichi en harmoniques, ajouter du vibrato et faire varier la fréquence de façon parfaitement continue.

Et il y a une propriété particulièrement intéressante pour le thérémine : lorsque la fréquence change, la phase continue. On ne redémarre pas la sinusoïde à zéro à chaque nouvelle mesure de la main. Les glissandos deviennent donc naturellement continus.

C’est précisément pour cette raison que je propose cette technique. Je suis d’avis que la prochaine étape intéressante est de construire une vraie version DDS + Timer, en expliquant en détail Timer1, fréquence d’échantillonnage, accumulateur 32 bits, table sinus et PWM, puis d’en tirer le programme C++ complet du thérémine.

Le sujet est plus profond qu’il n’y paraît, car la RTX 3090 est un bon exemple d’un phénomène historique : un composant conçu principalement pour le graphisme est devenu une petite machine de calcul neuronal accessible aux particuliers.

1. Pourquoi un GPU est-il si adapté à l’IA ?

Un processeur classique possède relativement peu de cœurs très sophistiqués.

Un GPU adopte presque la philosophie inverse : énormément d’unités de calcul relativement simples travaillant simultanément.

Or un réseau neuronal passe une énorme partie de son temps à effectuer des opérations du genre :

c’est-à-dire des multiplications matricielles. Prenons une couche d’un réseau :

avec :

Pour quelques neurones, rien d’impressionnant, de difficile. Mais avec des milliards de paramètres, il faut effectuer des milliards d’opérations similaires.

Et c’est précisément ce que les GPU savent faire extrêmement efficacement.

2. Les Tensor Cores changent encore la situation

Avec les RTX, NVIDIA a ajouté des circuits spécialisés : les Tensor Cores.

Ils sont particulièrement adaptés aux opérations matricielles utilisées par l’apprentissage profond.

Schématiquement :

peut être réalisée massivement en parallèle. Ainsi la RTX 3090 n’est plus simplement : « une carte graphique très rapide ». Elle devient pratiquement : un accélérateur de calcul matriciel vendu au grand public.

C’est une différence conceptuelle considérable.

3. Et c’est là que commence la question philosophique

À mon sens, la révolution la plus importante n’est pas : « les ordinateurs deviennent plus rapides ».

Elle est plutôt : la capacité cognitive artificielle se déplace progressivement du centre vers la périphérie.

Pendant longtemps, utiliser une IA puissante impliquait :

Mais une machine équipée d’un GPU de cette catégorie permet maintenant :

directement. Et cela change énormément de choses.

4. L’IA devient une propriété de l’individu

Imaginons un ordinateur personnel contenant une IA locale.

Elle peut disposer de :

• vos documents,
• vos livres,
• vos programmes,
• vos photographies,
• vos recherches,
• vos notes,
• vos bases de données,
• votre correspondance.

Tout cela peut potentiellement rester sur votre ordinateur.

On obtient alors quelque chose qui ressemble à :

Le PC avait démocratisé le calcul.

Internet avait démocratisé l’accès à l’information.

Le GPU pourrait contribuer à démocratiser le traitement intelligent de cette information.

5. Cela rappelle étrangement l’histoire du PC

Dans les années 1960 :

Puis sont arrivés les microprocesseurs.

Dans les années 1980 :

Nous observons peut-être aujourd’hui quelque chose d’analogue.

Première phase :

Deuxième phase :

Troisième phase possible :

puis :

La RTX 3090 n’est évidemment pas à elle seule responsable de cette évolution. Mais elle en constitue un symbole particulièrement intéressant.

6. Et il y a une conséquence encore plus profonde

Jusqu’à présent, l’ordinateur était principalement un outil.

Vous lui disiez : calcule ceci.

Il calculait.

Puis : affiche ceci.

Il affichait.

Puis : cherche ceci.

Il cherchait.

Avec l’IA générative, nous commençons à lui dire : réfléchis à ce problème.

Et la nature de la relation change.

Nous passons progressivement de :

à

voire, dans certains usages :

Le terme doit être utilisé avec prudence — le modèle ne possède pas nécessairement une compréhension ou une conscience comparable aux nôtres — mais fonctionnellement, pour l’utilisateur, la transformation est réelle.

7. Cela pose immédiatement la question de l’intelligence

Pendant des siècles, nous avons implicitement associé :

Les ordinateurs nous obligent progressivement à séparer :

de

Et c’est philosophiquement beaucoup plus important que les performances d’une carte graphique.

Car si certaines activités que nous considérions comme intellectuelles peuvent être obtenues par :

une question vertigineuse apparaît :

Quelle partie de ce que nous appelons intelligence provient réellement de propriétés exclusivement humaines ?

8. Et cela conduit à une autre question

Supposons une machine équipée d’une IA locale connaissant :

• tous vos travaux,
• vos raisonnements précédents,
• vos préférences intellectuelles,
• vos méthodes de calcul,
• vos erreurs habituelles,
• vos projets.

Vous lui posez un problème.

Elle ne répond plus comme une IA générique.

Elle raisonne en exploitant votre propre corpus intellectuel.

Nous obtenons alors quelque chose d’intéressant :

La frontière pertinente n’est donc peut-être plus :

mais :

9. Il existe cependant un paradoxe

L’IA nécessite actuellement des infrastructures gigantesques pour créer les grands modèles.

Entraîner un modèle de pointe demeure une activité industrielle.

Nous avons donc simultanément deux mouvements :

mais :

Une RTX 3090 ne permettra évidemment pas d’entraîner chez soi un modèle géant comparable aux modèles de frontière. En revanche, elle permet d’utiliser, adapter ou parfois affiner des modèles déjà entraînés. C’est un peu comparable à l’imprimerie : peu de personnes fabriquent une presse, mais énormément de personnes peuvent ensuite produire et diffuser des textes.

10. La carte TRX 3090 représente une étape historique assez amusante

On pourrait résumer l’histoire ainsi :

conçu pour calculer :

puis utilisé pour :

puis :

puis :

et finalement :

C’est une magnifique illustration d’un phénomène fréquent dans l’histoire des techniques :

Une invention devient véritablement révolutionnaire lorsqu’elle commence à servir à quelque chose pour laquelle elle n’avait pas été initialement conçue.

Et je pousserais volontiers cette discussion encore un cran plus loin

Il existe à mon avis une question encore plus fascinante que celle de la RTX 3090 :

Car on peut tracer une chaîne technologique extraordinaire :

Et derrière cette chaîne se cache une question philosophique encore plus troublante : comment quelques opérations mathématiques extrêmement simples — essentiellement multiplications, additions et fonctions non linéaires — répétées des milliards de fois finissent-elles par produire un système capable de discuter avec nous de physique, de philosophie ou de concevoir un programme ?

Celle-là mérite à elle seule une véritable investigation…

Lexique

CUDA signifie Compute Unified Device Architecture. C’est une technologie et une plateforme logicielle créée par NVIDIA qui permet d’utiliser le GPU comme un processeur de calcul général, et pas seulement pour fabriquer des images.La RTX 3090 possède 10 496 cœurs CUDA, contrairement aux quelques cœurs très puissants d’un CPU, ces milliers d’unités peuvent effectuer énormément d’opérations en parallèle.

GPU signifie Graphics Processing Unit, que l’on peut traduire par processeur graphique.

À l’origine, son rôle était de calculer très rapidement les images 2D et 3D des jeux vidéo : positions des objets, textures, éclairage, pixels, etc. Pour cela, il devait effectuer un très grand nombre de calculs similaires simultanément.C’est précisément cette caractéristique qui l’a rendu extrêmement intéressant pour l’IA.

Les Tensor Core sont des unités de calcul spécialisées intégrées aux GPU NVIDIA récents. Contrairement aux cœurs CUDA, plus généralistes, ils ont été conçus notamment pour effectuer extrêmement rapidement des calculs sur des matrices, ce qui les rend particulièrement adaptés à l’intelligence artificielle.

Une IA générative est une intelligence artificielle capable de produire un nouveau contenu, et pas seulement d’analyser ou de classer des données.

La différence essentielle est la suivante :

Elle peut générer du texte, des images, de la musique, de la vidéo, du code informatique, etc. ChatGPT est, par exemple, une IA générative spécialisée notamment dans le langage.

J-P Broillet 09.2026

Jean-Pierre Broillet 09.2026

Oui — mais sous une forme assez différente du fameux « ordinateur Josephson » imaginé dans les années 1970–1980.

Le projet historique d’IBM visait à remplacer les transistors par des jonctions Josephson supraconductrices afin de construire des ordinateurs classiques extrêmement rapides. IBM y travailla pendant plus d’une décennie, mais abandonna le programme en 1983, principalement parce que les progrès fulgurants du silicium rendaient l’avantage du Josephson insuffisant face aux difficultés de fabrication, de mémoire et surtout de cryogénie.

Et pourtant, l’idée revient fortement

Depuis quelques années, l’intérêt pour le calcul supraconducteur à jonctions Josephson augmente de nouveau. Un article IEEE de février 2026 parle explicitement de calcul supraconducteur « ultra-high-speed, ultra-low-power ».

La différence essentielle est qu’on n’utilise généralement plus la logique Josephson « latching » d’IBM. On emploie des familles telles que SFQ (Single Flux Quantum), RSFQ, ERSFQ/eSFQ, RQL ou encore AQFP. Elles utilisent toujours la jonction Josephson, mais représentent l’information par des quanta de flux magnétique et des impulsions extrêmement brèves.

Le résultat est assez extraordinaire : des circuits SFQ peuvent fonctionner à plusieurs dizaines de GHz, et des démonstrations atteignent la région des 100 GHz, avec des commutations de l’ordre de la picoseconde et une énergie de commutation extrêmement faible.

Il faut toutefois conserver un point crucial en tête : SFQ est un calcul classique, malgré le mot « quantum » dans Single Flux Quantum. Ce n’est pas un ordinateur quantique.

Et il y a maintenant un deuxième Josephson : le calcul quantique

C’est là que l’histoire devient particulièrement intéressante. La jonction Josephson est également devenue un composant fondamental de nombreux qubits supraconducteurs. Elle permet de fabriquer un circuit électrique macroscopique possédant des niveaux d’énergie quantifiés — en quelque sorte un « atome artificiel ». La recherche reste très active en 2026.

Et les deux branches commencent même à se rejoindre : des chercheurs étudient des circuits numériques Josephson fonctionnant à quelques kelvins pour réaliser l’électronique de commande des ordinateurs quantiques, afin d’éviter de ramener des milliers de connexions jusqu’à l’électronique située à température ambiante. Un travail publié en août 2026 décrit par exemple un accélérateur supraconducteur à 4 K, comportant moins de 17 000 jonctions Josephson, destiné à la discrimination de l’état des qubits.

Ce qui est assez savoureux historiquement

L’idée d’IBM n’était donc probablement pas mauvaise ; elle était trop en avance.

En 1983, le silicium progressait si rapidement que Josephson ne pouvait économiquement pas suivre.

Aujourd’hui, les problèmes de consommation électrique, d’interconnexions et de dissipation thermique des très grands systèmes de calcul rendent à nouveau intéressantes certaines des propriétés que recherchait IBM il y a près de cinquante ans.

Et compte tenu de votre intérêt pour l’électronique, je pense qu’il y a un aspect encore plus intéressant à examiner : comment fonctionne réellement une porte logique SFQ avec deux ou trois jonctions Josephson. On peut la suivre électriquement, impulsion par impulsion, et voir comment un quantum de flux

devient littéralement un bit d’information.

C’est une électronique assez fascinante : on retrouve condensateurs, inductances, courants et impulsions, mais avec la phase de la fonction d’onde supraconductrice qui intervient directement dans le fonctionnement du circuit.

https://newwaveparticle.com/josephson-junction-quantum-computer/

https://www.pascalchour.fr/divers/informatique/josephson.html

https://science.mainguet.org/quantum/ordiQ/machQ_05.htm

Laurent s’est gentiment proposé pour faire une présentation, le vendredi 14 novembre, sur le thème « le magnétisme ». Pour ceux que cela intéresse, je vous saurais gré de bien vouloir vous manifester en envoyant un mot « Je serai là » sur ma messagerie jean-pierre.broillet@outlook.com

Pour ceux qui se sont déjà manifestés, comme Alain, cela n’est pas nécessaire.

En vous remerciant, je vous souhaite un bon week-end

Jean-Pierre

Deux cas se présentent :

Cas 1 : Vi > 0 :

Lorsque Vi > 0, la partie « inverseuse » de A1 force sa sortie à être négative, ce qui permet à D1 de conduire et à D2 d’être bloquée. Comme aucun courant ne circule dans la résistance R connectée entre Vn1 et Vp2, les deux sont équipotentielles.

Vn1 = Vp2 = 0 V

La figure suivante montre son schéma équivalent

A partir du circuit équivalent, la tension de sortie peut être calculée :

Vo = Vi

Cas 2 : Vi < 0 : Lorsque Vi < 0, négatif, la tension de sortie de A1 passe au niveau positif, ce qui rend la diode D1 bloquée et la diode D2 conductrice.

La figure suivante montre son schéma équivalent

v

La tension de sortie de l’amplificateur A1 est de V. Comme l’entrée différentielle de A2 est nulle, la borne d’entrée inverseuse est également à la tension V, comme le montre la figure.

Appliquons la loi de Kirchhoff au nœud a :

Pour trouver Vo en fonction de V, nous nous concentrons sur le circuit équivalent de A2 (montage non-inverseur), comme le montre la figure.

=

En substituant la valeur de V dans l’équation ci-dessus, on obtient,

Par conséquent, pour Vi < 0, la sortie est positive. Ceci est illustré à la figure suivante.

Examinons ce montage avec la simulation Proteus. Pour ce faire nous appliquerons une tension de 2V DC, de 0V DC et -2V DC sur l’entrée. Si les calculs effectués ci-avant sont corrects, la tension de sortie doit être respectivement de +2 V DC, 0V DC et à nouveau +2V DC.

Avec + 2V

Avec 0V

Avec -2V

Vo = -Vi, car Vi < 0

Cerise sur le gâteau….

Un montage sans diode, avec un comparateur, des amplis op et un switch. Vous ne le trouverez nulle part ailleurs !

Fonctionnement du montage

Quelques mots tout d’abord sur le MAX912.

Les comparateurs doubles (dual), tels que le MAX912, possèdent grande vitesse de basculement (propagation) 10 ns, une faible consommation, des entrées différentielles et des sorties TTL complémentaires.

L’alimentation est simple +5V (ou ±5V).

Les sorties du MAX912 restent stables sur toute la région linéaire. Cette caractéristique élimine l’instabilité de sortie commune aux comparateurs à grande vitesse lorsqu’ils sont pilotés par un signal d’entrée lent.

Le DG419 est Analog Switch, avec les caractéristiques suivantes :

Low RDS(ON) (35Ω max)

Single-Supply Operation +10V to +30V

Bipolar-Supply Operation ±4.5V to ±20V

Low Power Consumption (35μW max)

Rail-to-Rail Signal Handling

TTL/CMOS-Logic Compatible

D’apprès son schéma synoptique, il appert qu’un niveau logique 1 (Switch 2 ON) sur la borne 6 (IN) relie, commute, les bornes 1 (D) et 8 (S2), alors qu’un niveau logique 0 (Switch1 ON) sur cette borne IN, reliera la borne D (1) à la borne S1 (2).

Lorsqu’une tension positive est appliquée sur l’entrée négative du comparateur, sa sortie bascule à l’état négatif (trace rouge), à contrario de la sortie complémentaire (trace bleue). De ce fait, c’est la tension de sortie du suiveur (U4) qui va se retrouver à la sortie du switch analogique. Une tension négative appliquée à l’entrée négative du comparateur va occasionner un basculement à l’état haut dudit comparateur et par conséquent, un passage à l’état bas de la sortie complémentaire. Cette sortie à l’état bas permet au signal d’entrée inversé (U3) de se retrouver à la sortie du switch. Cette sortie est représentée par la trace verte qui montre bien un comportement de redresseur. Les AOP utilisés pour un test réel ne sont pas des OP05, mais des AD746. Ceux-ci n’étant malheureusement pas encore disponible pour la simulation Proteus, d’où les OP05.

Ce montage fonctionne sans problème jusqu’à 500 kHz…

Jean-Pierre Broillet, Microclub, juin 2025

Source de courant à ampli-opérationnel

Afin de donner bonne suite à la présentation, de Laurent Francey et moi-même, sur les amplificateurs opérationnels (AOP), je vous propose quelques articles, un par type de montage.

Pour ce premier article topique nous allons aborder la source de courant à AOP.

Commençons tout d’abord par la configuration la plus simple.

Fig.1

Nous avons affaire ici à un montage suiveur. Son montage de base est le suivant :

Fig. 2

Avec comme équation de base, V_S = V_e

Ainsi, la tension présente sur l’entrée non-inverseuse de l’AOP se retrouve sur son entrée inverseuse, et par conséquent aux bornes de la résistance R (la tension différentielle, dans un fonctionnement linéaire, étant nulle).

Revenons à la Fig. 1

L’entrée positive de l’AOP est reliée au curseur d’un potentiomètre alimenté par une tension bipolaire de ± 10 V CC. Partant, cette tension se retrouvera aux bornes de la résistance R.

Regardons maintenant la simulation de ce circuit avec une tension d’entrée positive.

Fig. 3

Ladite tension de + 4V se retrouve intégralement aux bornes de la résistance R. Donc le courant y circulant, sera de +4V/R.

Fig. 4

A la fig. 4, c’est cette fois-ci une tension négative de -4V qui est appliquée à l’entrée non-inverseuse de l’AOP. Ce qui implique que le courant dans la résistance R sera de -4V/R et que notre source de courant est bipolaire.…

Avec un transistor en plus…

Fig. 5

Nous sommes en présence, ici, d’une source de courant avec charge à la masse.

R2 constituant la résistance de « charge ». La tension appliquée à l’entrée non-inverseuse de l’AOP est égale à : Vcc – la tension de la diode Zener, soit 15V – 3V = 12 V

Cette tension va se retrouver sur la borne inférieure de la résistance R3. La tension aux bornes de R3 sera de 15V (Vcc) – 12 V = 3 V. Par conséquent le courant circulant dans ladite résistance sera de 3V/3K = 1 mA. Preuve en est, la tension aux bornes de la résistance de charge est 100 Ω * 1 mA = 0.1 V .

Fig. 6

Quelques montages avec charge à la masse

Voici un montage pratique avec charge au Vcc, V⁺.

Fig. 7

Le courant dans la LED est égal à : Vin/Rsense

Un autre encore

Fig. 8

Maintenant, voyons à quoi ressemble une source de courant commandée par une tension. Précisons que nous n’aborderons pas les tensions de commandes alternatives, bien que plusieurs des montages vus ici, y sont compatibles.

Fig. 9

Le principe de la source de courant présentée à la Fig. 9 est basé sur le fait que le courant de sortie est monitoré par la tension aux bornes de R1. De manière à déterminer le courant de sortie, appliquons le KCL (Kirchoff’s Current Law) à l’entrée non-inverseuse, l’entrée inverseuse et à la sortie.

Fig. 10

V_O V_N U₁ U₂ I₂ V_P R₂²

(V_{O –} V_N )/R₂ – V_N/R₃ = 0 ;

(U_{1 –} V_P )/R₂ + ( U_{2 –} V_P )/R₂ = 0 ;

(V_{O –} U₂ )/R₁ + (V_{P –} U₂ )/R_{2 –} I₂ = 0 ;

Comme V_N = V_P, nous obtenons pour le courant de sortie I₂ =

Pour une seule valeur de R3, le courant de sortie devient indépendant de la tension de sortie ; c’est le cas où le second terme de l’équation est nul ! Et si

R3 =

La valeur du courant est

I2 = U1/(R1//R2)

En pratique R2 >> R1, et de fait I2 ~ U1/R1 ce qui est bien indépendant de la tension de sortie, de la charge.

L’histoire aurait pu s’arrêter là, mais c’était sans compter que les férus d’électronique analogique allaient s’emparer de l’affaire…

Ce qui est ennuyeux et compliqué à mettre en équation, c’est que nous avons un courant qui circule depuis Vo dans R2 et R3.

Et, c’est là, que les férus entrent en scène. Ils insèrent un montage suiveur à la borne inférieure de la résistance de setting du courant de sortie !

Cela donne le circuit suivant, Fig. 11 avec les équations idoines

Moins de texte, mais plus d’actes, vérifions avec le simulateur Proteus, la justesse des équations ci-dessus

Fig. 11.

U1 = 2*U3…U3 = 2.38 V, donc U1 = 4.76 V Ok !

U3 = (Ue + U2)/2 Ue = 1.2 V, U2 = 3.57 V, donc U3 = (1.2 V + 3.57 V)/2 = 2.38 V OK !

Ue = U1 – U2 ; 4.77 V – 3.57 V = 1.2 V Ok !

La tension aux bornes de la résistance de charge RCH (300 Ω) est 3.57 V. Ce qui implique que le courant la traversant est de 3.57 V/0.3 KΩ = 11.9 mA. I = Ue/Rset = 1.2 V / 100 Ω = 12 mA

Au vu de ce qui précède, la simulation démontre ladite justesse des équations !

Etant donné le peu de composants nécessaires à la réalisation de ce montage, il est vivement conseillé de le tester sur une bredboard.

Un, petit dernier, montage analysé…

Fig. 12

Nous avons ici, une source de courant de puissance, unipolaire, avec charge à la masse. L’étage de puissance est composé de deux transistors PNP montés en Darlington (et non pas tête bêche…comme il m’arrive de le dire). La tension d’alimentation (Vcc) est de 20 V. La valeur de la résistance R1 limitera le courant de sortie à 4 A. La tension minimale aux bornes de R1 est de 16 V. On notera que la tension présente sur l’entrée non inverseuse (18 V) se retrouve sur l’émetteur du transistor Q2. Nous sommes donc bien en présence d’un suiveur de tension. Le courant circulant dans ce transistor est donné par l’équation (Vcc – VE_Q2)/R4. En l’occurrence (20 V – 18V)/1Ω = 2A. Et, la tension aux bornes de R3 est bien de 4V, soit, 2Ω * 2A.

Quelques montages…trouvés sur la toile

https://www.analog.com/en/resources/analog-dialogue/articles/a-large-current-source-with-high-accuracy-and-fast-settling.html

Pour le Microclub Jean-Pierre Broillet, juin 2025