Options Bluetooth manquantes (micro/A2DP) : explication des profils

Le modèle mental : profils, rôles et pourquoi les options disparaissent

Quand les gens disent « mon casque Bluetooth », ils veulent généralement dire « un petit ordinateur qui peut parler plusieurs dialectes Bluetooth, parfois en même temps, souvent mal ».
Votre système d’exploitation choisit ensuite quel dialecte utiliser en fonction de ce qu’il croit que vous voulez : sortie haute qualité, audio bidirectionnel, économie d’énergie, ou « ce qui ne plante pas aujourd’hui ».

Deux vérités clés

• La lecture stéréo haute qualité (A2DP) et le micro de casque (HSP/HFP) sont généralement des profils différents.
  Beaucoup de casques ne peuvent pas assurer simultanément une sortie stéréo haute qualité et l’entrée micro via le Bluetooth classique.
• La sélection de profil est une politique, pas une fatalité.
  Quelque chose sur votre système (BlueZ + serveur audio + démon de politique) décide quel profil activer.
  Si cette politique casse, les options disparaissent de l’interface comme si elles n’avaient jamais été prises en charge.

Ce que « manquant » signifie habituellement

« A2DP manquant » ou « micro manquant » signifie rarement que le casque n’a pas la fonctionnalité. Le plus souvent :

• Le profil n’est pas exposé parce que la pile audio manque un module/plugin codec.
• Le démon Bluetooth tourne, mais le serveur audio n’a pas négocié le profil.
• Des problèmes de firmware/pilote empêchent la création du transport (vous le voyez connecté, mais les points de terminaison audio échouent).
• La politique vous a collé sur le mauvais profil parce qu’une application a demandé le micro une fois.
• Le support mains-libres est présent mais désactivé faute de backend téléphonie (commun sur Linux).

Une citation à afficher sur le mur de toute personne qui débogue ce genre de problème :
« L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan

Voilà votre mission ici : remplacer l’espoir par un diagnostic reproductible.

Faits intéressants & courte histoire (utile pour le débogage)

1. A2DP est arrivé pour standardiser la lecture stéréo. Les premiers usages audio Bluetooth étaient surtout orientés casque téléphonique ; le support de la « musique » est apparu plus tard, et cela se voit dans la partition actuelle.
2. SBC est obligatoire pour A2DP, pas « le meilleur codec ». Si vous obtenez SBC, cela peut simplement être le seul codec commun négocié — pas la preuve que votre système est « bas de gamme ».
3. HSP/HFP ont été conçus pour la voix étroite. Le chemin « casque » supposait historiquement une voix autour de 8 kHz. La voix large bande est arrivée plus tard et reste inégale selon les appareils.
4. L’audio Bluetooth sur Linux était autrefois une fonctionnalité PulseAudio greffée sur BlueZ. Les anciennes configurations utilisaient des modules séparés ; les modernes s’appuient sur PipeWire/WirePlumber et les plugins SPA.
5. BlueZ évite intentionnellement d’être un « serveur audio ». Il offre la plomberie Bluetooth ; votre serveur audio choisit profils, codecs et routage.
6. mSBC (large bande) pour HFP est un champ de mines de négociation. Certains casques déclarent le support puis se comportent mal. Résultat : « micro manquant » ou « connecté mais pas d’audio ».
7. LE Audio (LC3) est un nouveau monde, pas un simple rafistolage. Il change le transport et les capacités. Sur Linux le support s’améliore vite, mais n’attendez pas une uniformité entre distributions et noyaux.
8. Certaines clés Bluetooth USB sont livrées avec des combinaisons de firmware peu testées. La même famille de chipsets peut se comporter différemment selon la révision du firmware ; « ça marche sur mon portable » n’est pas une garantie.

Blague #1 : Bluetooth est la seule technologie radio qui peut être bloquée à la fois par le corps humain et la politique d’entreprise.

Mode d’emploi pour diagnostic rapide : vérifier premier/deuxième/troisième

Quand des options manquent, vous voulez trouver rapidement le goulot d’étranglement : matériel/pilote, démon Bluetooth, serveur audio, ou politique.
Faites ces vérifications dans l’ordre. Ne faites pas de freestyle.

Premier : confirmer que l’OS voit le contrôleur et qu’il est sain

• Si le contrôleur est bloqué, aucun profil ne fonctionnera.
• Si le firmware ne se charge pas, vous aurez des connexions instables et des points de terminaison manquants.

Deuxième : confirmer que BlueZ voit les services du casque

• Vous cherchez les UUID annoncés qui correspondent aux profils audio.
• Si le casque n’annonce pas HFP/HSP, vous n’obtiendrez pas de profil micro (sauf via LE Audio, qui est séparé).

Troisième : confirmer que le serveur audio tourne et a le support Bluetooth activé

• PipeWire a besoin de son plugin SPA Bluetooth ; PulseAudio a besoin de ses modules Bluetooth.
• WirePlumber (ou un autre gestionnaire de session) prend les décisions de politique qui cachent/montrent les profils.

Quatrième : vérifier le profil négocié et pourquoi il a été choisi

• Si vous avez A2DP mais pas de micro : vous êtes en profil musique.
• Si vous avez un micro mais pas A2DP : vous êtes probablement en HSP/HFP (ou la politique vous y a verrouillé).
• Si vous n’avez ni l’un ni l’autre : échec de création des transports ou plugins manquants.

Cinquième : rechercher les erreurs de codec et de transport dans les logs

• Les erreurs mentionnant SBC/aptX/LDAC, ou « transport acquire », pointent vers l’intégration de la pile audio.
• Les erreurs mentionnant des timeouts HCI pointent vers le contrôleur/firmware/radio.

Réalité des profils : A2DP vs HSP/HFP vs LE Audio (et ce que « micro » signifie vraiment)

A2DP (Advanced Audio Distribution Profile)

A2DP sert la sortie audio haute qualité. Pensez musique, vidéos, sons système.
Il n’est pas conçu pour transporter l’entrée micro au sens classique.
Donc quand votre interface affiche « A2DP Sink » et que vous vous demandez où est passé le micro : il n’est jamais allé nulle part ; il n’a jamais fait partie de ce profil.

A2DP s’accompagne généralement de codecs comme SBC (de base), et éventuellement AAC, aptX, aptX HD, LDAC, et d’autres selon l’appareil et le support de la pile.
La disponibilité des codecs affecte la qualité et la latence, mais ne produit pas le support micro.

HSP/HFP (Headset Profile / Hands-Free Profile)

HSP/HFP servent l’audio bidirectionnel. C’est là que l’entrée micro apparaît sur la plupart des casques Bluetooth classiques.
Le coût : la sortie audio tombe souvent en mono, en bande étroite, et avec plus de compression. Le large bande (mSBC) améliore parfois la situation.

Si votre application de réunion exige un micro, votre système peut basculer automatiquement le casque en HFP.
Ce n’est pas malveillant. C’est la seule manière d’obtenir l’entrée micro sur le Bluetooth classique pour beaucoup de casques.
La raison pour laquelle l’option « A2DP » disparaît est que le système ne peut pas utiliser les deux simultanément comme vous l’attendez.

LE Audio (LC3) et pourquoi ça change la donne

LE Audio vise à supporter des flux audio plus flexibles, une meilleure efficacité et des codecs modernes (LC3).
Il peut améliorer les expériences audio bidirectionnelles, mais il faut un support cohérent pour :
le contrôleur, le noyau, BlueZ, le serveur audio et le firmware du casque. Un maillon faible et vous revenez aux profils classiques.

Pourquoi l’interface ment (un peu)

Les interfaces audio de bureau ont tendance à présenter les profils comme des « modes de qualité », alors qu’il s’agit en réalité de services différents avec des transports différents.
Certaines interfaces masquent les profils qui échouent à s’activer, ce qui donne l’impression que le casque « ne le supporte pas ».
Il se peut que si. C’est peut-être votre pile qui ne le supporte pas.

Blague #2 : Le profil « Hands-Free » est nommé ainsi pour les administrateurs, car vos mains vont être très occupées à le réparer.

Piles audio Linux : PulseAudio vs PipeWire vs WirePlumber (qui décide)

Sur les bureaux Linux modernes, vous avez habituellement :

• BlueZ pour la gestion des appareils Bluetooth et les points de terminaison de transport.
• PipeWire comme moteur audio (remplaçant souvent PulseAudio et parfois le routage JACK).
• WirePlumber (ou un autre gestionnaire de session) pour appliquer la politique : quel appareil, quel profil, quels routages.

Sur les configurations plus anciennes, vous pourriez avoir :

• PulseAudio comme moteur audio avec des modules Bluetooth.
• Des pièces d’intégration optionnelles qui varient selon la distribution.

Pourquoi c’est important

Les profils manquants sont souvent causés par le mauvais composant qui prend la décision :
BlueZ voit l’appareil, mais PipeWire ne charge pas le plugin Bluetooth ; ou WirePlumber bloque HFP car il ne trouve pas de backend téléphonie ; ou PulseAudio n’a pas le bon module.

La politique est l’endroit où « ça marchait avant » meurt

Les démons de politique retiennent les préférences, réagissent à l’ouverture de flux par les applications et essaient de garder la stabilité.
Stable, c’est bien. Stable peut aussi vouloir dire « bloqué ».
Quand le système verrouille votre casque en HFP parce qu’un onglet du navigateur a demandé l’accès au micro, il fait exactement ce qu’on lui a demandé.

Tâches pratiques (commandes, ce que signifie la sortie, et quoi faire ensuite)

Les commandes ci‑dessous supposent un système Linux avec systemd. Ajustez légèrement les noms de services pour votre distro.
Chaque tâche inclut : commande, interprétation de la sortie, et décision.

Tâche 1 : Vérifier si Bluetooth est bloqué (rfkill)

cr0x@server:~$ rfkill list
0: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no

Signification : Si l’un des blocages indique « yes », le contrôleur peut exister mais ne fonctionnera pas.
Décision : Si soft blocked, débloquez. Si hard blocked, vérifiez l’interrupteur BIOS ou la touche du portable.

Tâche 2 : Vérifier que le contrôleur est actif (bluetoothctl)

cr0x@server:~$ bluetoothctl show
Controller 24:EE:9A:12:34:56 (public)
	Name: cr0x-laptop
	Powered: yes
	Discoverable: no
	Pairable: yes

Signification : « Powered: yes » est requis. Si « Powered: no », rien d’autre n’a d’importance.
Décision : Si powered est no, exécutez bluetoothctl power on et voyez pourquoi il était éteint (politique, économie d’énergie).

Tâche 3 : Confirmer que le noyau voit l’HCI Bluetooth et les modules chargés

cr0x@server:~$ lsmod | grep -E 'btusb|bluetooth'
btusb                  69632  0
bluetooth             851968  22 btrtl,btintel,btbcm,btusb

Signification : Pour les contrôleurs USB, vous voulez typiquement btusb. L’absence de modules peut signifier que la clé n’est pas supportée ou est bloquée.
Décision : Si rien n’apparaît, confirmez que le périphérique existe en USB/PCI et que les modules noyau ne sont pas blacklistés.

Tâche 4 : Chercher des échecs de firmware/pilote dans dmesg

cr0x@server:~$ dmesg -T | grep -iE 'bluetooth|btusb|firmware' | tail -n 20
[Tue Feb  4 10:12:21 2026] Bluetooth: hci0: Firmware revision 0x2b
[Tue Feb  4 10:12:21 2026] Bluetooth: hci0: Found device firmware: intel/ibt-20-1-3.sfi
[Tue Feb  4 10:12:22 2026] Bluetooth: hci0: Malformed MSFT vendor event: 0x02

Signification : Firmware trouvé est bon. Des timeouts répétés, « failed to load firmware », ou des réinitialisations HCI pointent vers des problèmes contrôleur/firmware.
Décision : Si le firmware manque, installez le paquet de firmware pour votre distro. Si les timeouts persistent, essayez une autre clé ou mettez à jour noyau/firmware.

Tâche 5 : Vérifier la santé du service BlueZ

cr0x@server:~$ systemctl status bluetooth --no-pager
● bluetooth.service - Bluetooth service
     Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled)
     Active: active (running)
       Docs: man:bluetoothd(8)
   Main PID: 842 (bluetoothd)

Signification : Si non actif, l’appairage peut « fonctionner à moitié » via des états en cache, mais les points de terminaison audio ne se comporteront pas correctement.
Décision : Si échec, vérifiez les logs et redémarrez ; corrigez la configuration ou les dépendances manquantes.

Tâche 6 : Inspecter les logs BlueZ pour erreurs de profil/transport

cr0x@server:~$ journalctl -u bluetooth -b --no-pager | tail -n 40
Feb 04 10:21:08 cr0x-laptop bluetoothd[842]: Endpoint registered: sender=:1.62 path=/MediaEndpoint/A2DPSink/sbc
Feb 04 10:21:08 cr0x-laptop bluetoothd[842]: Endpoint registered: sender=:1.62 path=/MediaEndpoint/A2DPSink/aac
Feb 04 10:22:11 cr0x-laptop bluetoothd[842]: src/service.c:btd_service_connect() a2dp-sink profile connect failed for 88:C9:E8:AA:BB:CC: Protocol not available

Signification : « Endpoint registered » suggère que le serveur audio a enregistré des endpoints A2DP auprès de BlueZ. « Protocol not available » signifie généralement un support de transport manquant ou un échec de négociation.
Décision : Si les endpoints ne s’enregistrent jamais, concentrez-vous sur l’intégration PipeWire/PulseAudio Bluetooth. Si la connexion échoue, concentrez-vous sur un décalage codec/profil ou la politique.

Tâche 7 : Confirmer que PipeWire tourne (commun sur bureaux modernes)

cr0x@server:~$ systemctl --user status pipewire --no-pager
● pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled)
     Active: active (running)

Signification : Si PipeWire ne tourne pas, l’UI des profils sera vide ou trompeuse.
Décision : Démarrez/activez-le, ou si vous utilisez volontairement PulseAudio, assurez-vous que PulseAudio tourne et que PipeWire n’est pas à moitié installé.

Tâche 8 : Confirmer que WirePlumber tourne (moteur de politique)

cr0x@server:~$ systemctl --user status wireplumber --no-pager
● wireplumber.service - Multimedia Service Session Manager
     Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled)
     Active: active (running)

Signification : Sans gestionnaire de session, les appareils peuvent apparaître mais ne pas être routés ni se voir appliquer des profils.
Décision : S’il est inactif, démarrez-le ; si vous utilisez un autre gestionnaire de session, confirmez qu’il est installé et configuré.

Tâche 9 : Lister les appareils audio PipeWire et voir les profils disponibles

cr0x@server:~$ wpctl status
PipeWire 'pipewire-0' [1.2.7, cr0x@server, cookie:123456]
 └─ Clients:
        34. WirePlumber                        [1.2.7]

Audio
 ├─ Devices:
 │      52. Bluetooth Headset                 [bluez5]
 ├─ Sinks:
 │      78. Bluetooth Headset                 [vol: 0.62]
 ├─ Sources:
 │      81. Bluetooth Headset                 [vol: 1.00]

Signification : Présence de l’appareil est bonne. Si l’appareil existe mais que la source est absente, le chemin micro n’est pas créé (probablement pas de HFP/HSP actif ou bloqué).
Décision : Si seul le sink existe, vérifiez si HFP est désactivé ou non supporté. Si aucun n’existe, la connexion BlueZ existe peut-être mais PipeWire n’a pas créé de nœuds.

Tâche 10 : Inspecter les détails du périphérique pour l’état du profil

cr0x@server:~$ wpctl inspect 52 | sed -n '1,120p'
id 52, type PipeWire:Interface:Device
	media.class = "Audio/Device"
	device.name = "bluez_card.88_C9_E8_AA_BB_CC"
	device.description = "Bluetooth Headset"
	bluez5.profile = "a2dp-sink"
	bluez5.address = "88:C9:E8:AA:BB:CC"

Signification : Vous êtes explicitement en a2dp-sink. C’est pourquoi le micro peut être absent ou inutilisable.
Décision : Si vous avez besoin du micro, passez à un profil HFP/HSP (si disponible) ou utilisez un périphérique micro séparé.

Tâche 11 : Changer de profil (PipeWire/WirePlumber)

cr0x@server:~$ wpctl set-profile 52 handsfree-head-unit
Profile set

Signification : Si cela réussit, vous devriez voir un nœud source apparaître et A2DP disparaître ou se dégrader.
Décision : Si cela échoue, le profil est indisponible ; confirmez que le casque annonce HFP/HSP et que votre pile le supporte.

Tâche 12 : Vérifier les profils que le système croit exister

cr0x@server:~$ pactl list cards short
52	bluez_card.88_C9_E8_AA_BB_CC	module-bluez5-device.c

Signification : Même sur des systèmes PipeWire, les outils de compatibilité PulseAudio peuvent afficher des cartes.
Décision : Utilisez ce nom de carte pour interroger les profils et ports via pactl list card.

Tâche 13 : Lister les profils de carte (ce qui est réellement sélectionnable)

cr0x@server:~$ pactl list card bluez_card.88_C9_E8_AA_BB_CC | sed -n '/Profiles:/,/Active Profile:/p'
Profiles:
	a2dp-sink: High Fidelity Playback (A2DP Sink) (sinks: 1, sources: 0, priority: 40, available: yes)
	headset-head-unit: Headset Head Unit (HSP/HFP) (sinks: 1, sources: 1, priority: 30, available: yes)
Active Profile: a2dp-sink

Signification : C’est le résultat clé. Il vous dit si le système pense que HSP/HFP existe.
Décision : Si HSP/HFP montre « available: no », le casque peut ne pas l’annoncer, ou la politique l’a désactivé, ou le backend manque.

Tâche 14 : Changer de profil avec pactl (fonctionne via PipeWire-Pulse aussi)

cr0x@server:~$ pactl set-card-profile bluez_card.88_C9_E8_AA_BB_CC headset-head-unit

Signification : Si le micro apparaît après cela, le « micro manquant » n’était que « mauvais profil ».
Décision : Décidez si vous acceptez la qualité audio casque pendant les appels. Sinon, utilisez un micro dédié et gardez A2DP.

Tâche 15 : Vérifier que le casque annonce les bons UUID (bluetoothctl)

cr0x@server:~$ bluetoothctl info 88:C9:E8:AA:BB:CC
Device 88:C9:E8:AA:BB:CC (public)
	Name: Bluetooth Headset
	Paired: yes
	Trusted: yes
	Connected: yes
	UUID: Audio Sink                (0000110b-0000-1000-8000-00805f9b34fb)
	UUID: Handsfree                 (0000111e-0000-1000-8000-00805f9b34fb)
	UUID: AV Remote Control         (0000110e-0000-1000-8000-00805f9b34fb)

Signification : « Audio Sink » correspond à A2DP. « Handsfree » correspond à HFP. Si les UUID Handsfree/Headset sont absents, votre profil micro peut ne jamais apparaître.
Décision : Si les UUID ne sont pas présents, cessez de blâmer Linux et suspectez le mode casque (certains ont des bascules « gaming » vs « phone ») ou des bizarreries du fabricant.

Tâche 16 : Réinitialiser un appairage instable (supprimer et ré-appairer proprement)

cr0x@server:~$ bluetoothctl
[bluetooth]# disconnect 88:C9:E8:AA:BB:CC
Successful disconnected
[bluetooth]# remove 88:C9:E8:AA:BB:CC
Device has been removed
[bluetooth]# scan on
Discovery started
[bluetooth]# pair 88:C9:E8:AA:BB:CC
Pairing successful
[bluetooth]# trust 88:C9:E8:AA:BB:CC
Changing 88:C9:E8:AA:BB:CC trust succeeded
[bluetooth]# connect 88:C9:E8:AA:BB:CC
Connection successful

Signification : Cela efface les services en cache et peut corriger les cas où « le profil a disparu après une mise à jour ».
Décision : Si le ré-appairage restaure les profils, votre problème était une corruption d’état ou une découverte de services obsolète, pas un pilote manquant.

Tâche 17 : Surveiller les logs en temps réel en changeant de profil

cr0x@server:~$ journalctl --user -u pipewire -u wireplumber -f
Feb 04 10:31:42 cr0x-laptop wireplumber[1290]: bluez5: activating profile headset-head-unit
Feb 04 10:31:42 cr0x-laptop pipewire[1210]: bluez5-device: transport acquire 88:C9:E8:AA:BB:CC
Feb 04 10:31:42 cr0x-laptop pipewire[1210]: spa.bluez5: Failed to set codec configuration: Not supported

Signification : « Failed to set codec configuration » signifie souvent que le casque et la pile ne s’accordent pas sur un codec vocal (mSBC vs CVSD) ou que les capacités sont mal rapportées.
Décision : Forcer un codec plus simple si possible (désactiver mSBC dans la config), ou mettre à jour BlueZ/PipeWire, ou accepter que le HFP de ce casque soit cassé sur cette pile.

Tâche 18 : Vérifier que vous ne faites pas tourner des serveurs audio en conflit

cr0x@server:~$ ps -ef | grep -E 'pipewire|pulseaudio' | grep -v grep
cr0x      1210    1090  0 10:18 ?        00:00:02 /usr/bin/pipewire
cr0x      1211    1090  0 10:18 ?        00:00:01 /usr/bin/pipewire-pulse

Signification : C’est normal pour les setups PipeWire (PipeWire fournissant la compatibilité PulseAudio).
Si vous voyez aussi un démon pulseaudio autonome, vous avez peut‑être une guerre de territoire.
Décision : Choisissez une pile. Ne lancez pas les deux sauf si vous aimez diagnostiquer des périphériques fantômes.

Tâche 19 : Vérifier les modules Bluetooth de PulseAudio (pour les anciens systèmes PulseAudio)

cr0x@server:~$ pactl list modules short | grep -E 'bluez|bluetooth'
28	module-bluetooth-policy
29	module-bluetooth-discover

Signification : Si ces modules ne sont pas chargés, vous pouvez avoir de l’appairage mais pas de cartes/profils audio.
Décision : Chargez-les (temporairement) ou corrigez la config PulseAudio pour qu’ils se chargent au démarrage.

Tâche 20 : Vérifier les indices de disponibilité des codecs (propriétés PipeWire)

cr0x@server:~$ wpctl inspect 52 | grep -iE 'a2dp|codec|bluez5'
	bluez5.profile = "handsfree-head-unit"
	bluez5.codec = "CVSD"

Signification : Voir CVSD implique que vous êtes en profil vocal avec codec de base. Ce n’est pas « mauvais », c’est « prévisible ».
Décision : Si mSBC casse les appels, privilégiez la stabilité CVSD. La qualité audio ne vaut rien si le micro tombe en plein milieu d’une phrase.

Tâche 21 : Vérifier l’état de gestion d’alimentation de l’adaptateur Bluetooth (source fréquente de flake)

cr0x@server:~$ cat /sys/module/bluetooth/parameters/disable_ertm
N

Signification : Certains appareils ont des problèmes avec certains modes de lien ; des paramètres comme les basculements ERTM peuvent affecter la stabilité (selon noyau/version).
Décision : Ne changez pas les paramètres noyau à l’aveugle. Ne modifiez que si vous pouvez reproduire et revenir en arrière, idéalement dans un environnement contrôlé.

Tâche 22 : Valider que la partie ALSA n’est pas le goulot d’étranglement (pour micros non Bluetooth)

cr0x@server:~$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 2: Webcam [USB Webcam], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Signification : Si votre micro de casque est instable, utiliser un micro USB/webcam séparé peut être une solution pratique.
Décision : Lors des réunions, priorisez la fiabilité : gardez A2DP pour la sortie et utilisez un périphérique de capture dédié.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom : « A2DP a disparu ; seul Headset/HFP apparaît »

• Cause racine : Une application a ouvert un flux d’entrée, la politique est passée en HFP et y est restée.
• Fix : Repassez en A2DP via wpctl set-profile ou pactl set-card-profile. Ensuite, refusez la permission micro aux applications qui n’en ont pas besoin.

2) Symptom : « Option micro entièrement absente »

• Cause racine : Le casque n’annonce pas les UUID HSP/HFP dans le mode actuel, ou le backend HFP est désactivé dans votre pile.
• Fix : Vérifiez les UUID avec bluetoothctl info. Si absents, changez le mode/firmware du casque. Si présents, vérifiez la config PipeWire/WirePlumber pour l’activation de HFP.

3) Symptom : « Connecté, mais pas de son en A2DP »

• Cause racine : L’acquisition du transport échoue ; mismatch de négociation codec ; ou le serveur audio n’a pas enregistré les endpoints auprès de BlueZ.
• Fix : Inspectez journalctl -u bluetooth et les logs PipeWire. Confirmez les endpoints enregistrés. Essayez de changer de codec (ou revenir à SBC) et ré-appairez.

4) Symptom : « Le son marche, le micro marche, mais la qualité est affreuse »

• Cause racine : Le codec vocal HSP/HFP (CVSD) est par conception en bande étroite, et la sortie est souvent mono.
• Fix : Utilisez A2DP pour la sortie et un micro séparé ; ou essayez le large bande (mSBC) si stable ; ou passez à du matériel LE Audio de bout en bout.

5) Symptom : « Le changement de profil échoue : Not supported / Protocol not available »

• Cause racine : Plugin/module audio Bluetooth manquant, ou incompatibilité de versions entre BlueZ et le serveur audio.
• Fix : Vérifiez que le plugin SPA Bluetooth de PipeWire est installé ; assurez-vous que les services tournent ; mettez à jour vers un ensemble compatible (noyau/BlueZ/PipeWire). Redémarrez si des composants ont été mis à jour en cours de session.

6) Symptom : « Ça marche après reboot, ça casse après suspension »

• Cause racine : Bugs de gestion d’alimentation du contrôleur ; course lors de la reconnexion ; état de transport obsolète.
• Fix : Redémarrez les services audio utilisateur (systemctl --user restart pipewire wireplumber) et basculez Bluetooth. Si fréquent, testez un noyau/firmware plus récent ou un autre adaptateur.

7) Symptom : « Le casque se connecte au laptop mais le micro n’apparaît jamais dans les apps de réunion »

• Cause racine : Permissions sandbox d’application ou paramètres de portail ; le périphérique d’entrée existe mais n’est pas sélectionné ; ou l’app liste seulement des périphériques ALSA dans certains modes.
• Fix : Vérifiez que la source existe via wpctl status. Sélectionnez-la explicitement dans l’application. Vérifiez les invites et paramètres de permission.

Checklists / plan étape par étape

Checklist A : « J’ai besoin d’A2DP pour la musique et le micro du casque ne m’importe pas »

1. Définissez le profil sur A2DP : pactl set-card-profile ... a2dp-sink.
2. Choisissez un micro séparé : micro de webcam ou micro USB ; confirmez avec arecord -l.
3. Dans les applications de réunion, sélectionnez explicitement le micro séparé.
4. Retirez la permission micro pour les onglets de navigateur aléatoires et les applications de chat « utiles ».

Conseil engagé : c’est la configuration la plus fiable pour les appels professionnels sur Bluetooth classique aujourd’hui.
Ce n’est pas élégant. C’est stable.

Checklist B : « J’ai besoin du micro casque pour les appels, j’accepte une sortie de moindre qualité »

1. Confirmez que le casque annonce les UUID Handsfree/Headset via bluetoothctl info.
2. Basculez sur le profil casque : wpctl set-profile ... handsfree-head-unit.
3. Surveillez les logs pendant le changement ; si des erreurs codec apparaissent, préférez la stabilité CVSD plutôt que des aspirations mSBC.
4. Testez d’abord dans un enregistreur simple (pas un meeting dans le navigateur) pour isoler les problèmes d’application.

Checklist C : « Les profils manquent ; il faut les récupérer »

1. Vérifiez que le contrôleur est sain : rfkill list, bluetoothctl show, lignes firmware dans dmesg.
2. Vérifiez la santé et les logs de BlueZ : systemctl status bluetooth, journalctl -u bluetooth.
3. Vérifiez les services audio : systemctl --user status pipewire wireplumber.
4. Vérifiez les profils de carte : pactl list card ....
5. Supprimez et ré-appairez l’appareil pour rafraîchir la découverte de services.

Checklist D : « Ça marche sur un portable, pas sur l’autre »

1. Comparez les versions du noyau et de BlueZ (mêmes versions majeures importantes).
2. Comparez les versions PipeWire/WirePlumber et si les plugins Bluetooth sont installés.
3. Comparez l’adaptateur Bluetooth (interne vs clé) et les logs firmware.
4. N’ignorez pas l’environnement radio : ports USB 3 et interférences 2,4 GHz peuvent dégrader la stabilité.

Trois mini-histoires d’entreprise issues de la production

Mini-histoire 1 : L’incident causé par une mauvaise supposition

Une entreprise de taille moyenne a déployé un « casque standard » pour un effectif hybride. La checklist d’achats disait « Bluetooth, suppression de bruit, supporté sur Linux ».
C’était l’optimisme corporatif habituel : si ça s’appaire, ça marche.

Le premier jour d’une semaine d’assemblée générale, une pluie de tickets est tombée : « Mon micro a disparu. » Les gens entendaient la réunion, mais personne ne pouvait parler.
La première réaction de l’IT fut de blâmer le client de visioconférence. Sensible, sauf que le bug se reproduisait dans trois applications différentes.

La mauvaise supposition : ils pensaient qu’A2DP impliquait la capacité micro. Ils s’étaient standardisés sur une sortie « High Fidelity » et n’avaient jamais validé l’audio bidirectionnel.
Les images de bureau étaient configurées pour préférer A2DP et ne pas basculer automatiquement en HFP parce que le mode HFP du casque précédent était instable.

La solution était ennuyeuse mais efficace : documenter le compromis, fournir un script de bascule de profil en un clic, et distribuer un micro USB bon marché aux équipes qui faisaient beaucoup d’appels.
Pour une partie des utilisateurs, ils ont choisi des casques filaires car la latence et les basculements de profil les faisaient souffrir.

Après coup, ils ont mis à jour le test d’acceptation matériel : « Pouvez-vous enregistrer 30 secondes d’audio depuis le micro du casque pendant la connexion, sans fouiller l’UI ? »
L’achats a détesté ça. Les opérations ont adoré.

Mini-histoire 2 : L’optimisation qui a mal tourné

Une autre organisation a voulu « optimiser l’autonomie » des portables en étant agressive sur la gestion d’énergie.
Ils ont diffusé une configuration de flotte qui ajustait le comportement de suspension et mettait rapidement les radios hors tension quand inactives.

La conséquence inattendue : les reconnexions Bluetooth après suspension ont commencé à entrer en compétition avec le démarrage de la session utilisateur.
BlueZ reconnectait le casque, mais PipeWire/WirePlumber manquaient le timing initial de découverte de services.
Les utilisateurs voyaient un appareil connecté avec des profils manquants, ou le profil A2DP apparaissait mais ne parvenait pas à acquérir le transport.

Les ingénieurs ont essayé de corriger en ajoutant des boucles de redémarrage (« si ça échoue, redémarre les services »). Ça a empiré.
Maintenant, pendant les premières minutes après le réveil, le système thrashait : reconnexions, démontages, réenregistrements d’endpoints, et parfois laissait le casque dans un état cassé.

La solution a été… d’arrêter d’être trop malin. Ils ont assoupli la politique d’extinction radio et ajouté un petit délai déterministe avant d’appliquer la politique de routage aux dispositifs audio Bluetooth fraîchement connectés.
Ils ont aussi ajouté de l’observabilité : des logs capturant les changements de profil, pas seulement « Bluetooth connecté ».

L’autonomie est restée correcte. La fiabilité des réunions s’est améliorée de façon dramatique. Et la file de tickets a cessé de ressembler à une attaque par déni de service.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise avec une culture SRE stricte traitait l’« image de bureau » comme un produit. Ils la versionnaient, la testaient et déployaient les mises à jour en anneaux.
Pas excitant. Pas courant non plus.

Lors de leur migration de PulseAudio vers PipeWire, ils ne l’ont pas faite en mode big-bang.
Ils ont lancé des groupes pilotes, capturé la liste des casques Bluetooth en usage et validé la disponibilité des profils pour chacun : codecs A2DP, comportement HFP, suspend/reprise.

Pendant le déploiement, une mise à jour a changé les préférences de codec Bluetooth par défaut. Une petite classe de casques a négocié un codec « meilleur » puis est tombée en panne en plein appel.
Le groupe pilote l’a repéré en quelques heures, avec des logs montrant des échecs de configuration codec lors de l’activation de profil.

La pratique ennuyeuse : ils avaient un test de régression qui changeait littéralement de profil, enregistraient de l’audio et vérifiaient que les nœuds existaient dans PipeWire.
Ils ont utilisé les mêmes commandes que vous utilisez dans cet article. Pas de magie. Juste des vérifications reproductibles.

Ils ont figé la préférence codec sur une baseline connue pour cette classe de casques et ont avancé seulement après vérification de la stabilité.
Personne n’a écrit de billet triomphal. Le support est resté silencieux. C’est la vraie condition de succès.

FAQ

1) Pourquoi le micro de mon casque disparaît quand je choisis « High Fidelity (A2DP) » ?

Parce que A2DP sert la lecture, pas la capture micro. Pour les casques Bluetooth classiques, la capture micro nécessite généralement HSP/HFP, qui remplace souvent A2DP.

2) Pourquoi A2DP disparaît quand j’active le micro ?

Passer en HSP/HFP active un autre transport optimisé pour la voix. Beaucoup de casques ne peuvent pas faire de sortie stéréo A2DP tout en fournissant l’entrée micro sur le Bluetooth classique.

3) Mon casque prend en charge un micro sur mon téléphone. Pourquoi pas sur mon portable Linux ?

Les téléphones ont souvent des stacks HFP matures et des réglages constructeurs. Sur Linux, le support HFP dépend de BlueZ + serveur audio + configuration de politique. Des plugins manquants ou des backends désactivés peuvent masquer HFP complètement.

4) Comment savoir si mon casque annonce les services Hands-Free ?

Utilisez bluetoothctl info <MAC> et cherchez des UUID comme « Handsfree » ou « Headset ». S’ils ne sont pas là, l’OS ne va pas les inventer.

5) PipeWire tourne. Pourquoi n’ai-je toujours pas de profils Bluetooth ?

PipeWire a besoin du support Bluetooth via ses plugins SPA, et d’un gestionnaire de session comme WirePlumber pour appliquer la politique. Si les endpoints ne sont pas enregistrés dans les logs BlueZ, la couche d’intégration manque ou est cassée.

6) Dois‑je utiliser mSBC wideband pour une meilleure qualité d’appel ?

Si c’est stable sur votre casque et votre pile, oui. Si vous voyez des échecs de configuration codec ou des coupures, utilisez CVSD. La fiabilité bat la qualité théorique dans les réunions réelles.

7) Puis‑je forcer le système à rester en A2DP tout en utilisant le micro du casque ?

En général non sur le Bluetooth classique. L’approche pragmatique : garder A2DP pour la sortie et utiliser un micro séparé (USB/webcam). Ou passer à du matériel LE Audio de bout en bout.

8) Pourquoi ça marche jusqu’à ce que j’ouvre un onglet de navigateur, puis les profils changent ?

Le navigateur a demandé l’accès au micro ; la politique a basculé sur un profil vocal. Refusez la permission micro quand c’est possible, ou basculez manuellement en A2DP après l’appel.

9) Quel est le moyen le plus rapide de voir quel profil est actif ?

Sur PipeWire : wpctl inspect de l’appareil Bluetooth et vérifiez bluez5.profile. Avec pactl : vérifiez « Active Profile » sous pactl list card.

10) Dois‑je redémarrer pour régler ça ?

Pas d’habitude. Redémarrer les services utilisateur (pipewire, wireplumber) et ré-appairer le casque efface souvent l’état obsolète. Redémarrez seulement si le noyau/firmware a été mis à jour.

Conclusion : prochaines étapes qui ne vous font pas perdre l’après-midi

Traitez l’absence d’options micro/A2DP comme un échec de négociation, pas comme une malédiction mystique.
Validez d’abord le contrôleur et BlueZ. Ensuite validez le serveur audio et la politique. Puis regardez quel profil est actif et pourquoi.
L’interface utilisateur est l’endroit où on débogue en dernier, pas le premier.

Prochaines étapes pratiques

1. Exécutez bluetoothctl info et confirmez que l’appareil annonce les services audio attendus.
2. Exécutez pactl list card ou wpctl inspect et confirmez quels profils sont disponibles et lequel est actif.
3. Si vous avez besoin de fiabilité pour les appels, choisissez une des options :
   • A2DP pour la sortie + micro séparé (ennuyeux, efficace), ou
   • Mode casque HFP (qualité inférieure, mais intégré), ou
   • Chemin de montée vers LE Audio (meilleur avenir, présence inégale aujourd’hui).
4. Si le changement de profil échoue, arrêtez de basculer des réglages au hasard et lisez les logs pendant le changement. Les chaînes d’erreur indiquent généralement quelle couche est cassée.

L’audio Bluetooth est une pile de décisions. Rendez ces décisions explicites, et le problème de « l’option manquante » redeviendra de l’ingénierie.