Le microphone ne fonctionne pas sous Linux : comment le tester et le réparer

Sous Linux, un microphone qui ne fonctionne pas est bien plus souvent simplement désactivé que réellement défectueux. Le canal de capture ALSA est désactivé par défaut sur de nombreuses distributions ; la capsule fonctionne donc, mais le pilote ne transmet rien. Une source par défaut incorrecte ou une application confinée dans un bac à sable explique la plupart des cas restants. Le signal remonte une pile de couches : le pilote du noyau ALSA, puis PipeWire ou PulseAudio, puis l’application elle-même. N’importe quelle couche peut le rejeter, et le résultat est toujours le même : le silence. La solution appropriée dépend entièrement de la couche à l’origine du blocage. Ce guide identifie cette couche, puis la répare à l’aide d’étapes à effectuer à la fois en interface graphique et en ligne de commande. Commencez par effectuer un test rapide du microphone ou consultez l’indicateur d’entrée du bureau pour vérifier le bon fonctionnement du matériel. Vérifiez ensuite si votre distribution utilise PipeWire ou PulseAudio, car les commandes ci-dessous varient en fonction de cette réponse.

Microphone Linux hors service : liste de contrôle pour une réparation rapide

✓	Effectuez un test à l’aide de notre test de microphone ou du vumètre d’entrée audio du bureau.
✓	Réactivez le canal Capture dans alsamixer et augmentez son niveau.
✓	Définissez la bonne entrée dans pavucontrol (ou wpctl sur PipeWire).
✓	Vérifiez que votre utilisateur fait partie du groupe audio.
✓	Redémarrez l'audio : systemctl --user restart pipewire pipewire-pulse ou pulseaudio -k.

Testez votre microphone Linux en moins d’une minute

Vérifiez que le microphone capte bien le son avant de modifier le moindre paramètre. La solution au problème « aucun signal » est totalement différente de celle pour « j’ai un signal, mais personne ne m’entend ». Un indicateur de niveau en temps réel fournit la réponse la plus rapide et la plus fiable, car il réagit à votre voix en temps réel. Une boucle d’enregistrement puis de lecture peut masquer des erreurs de sélection de périphérique ; commencez donc par utiliser un indicateur de niveau. Ouvrez notre test de microphone en ligne et autorisez l’accès lorsque le navigateur vous le demande. Parlez ensuite normalement. Si l’indicateur de niveau bouge pendant que vous parlez, cela signifie que le microphone, le pilote et le serveur audio fonctionnent correctement. Le problème se situe alors plus haut dans la chaîne, au niveau du routage ou dans une application spécifique. Si le niveau reste stable, le signal est bloqué ou une entrée incorrecte a été sélectionnée.

Testez votre microphone →

Votre ordinateur de bureau expose également le microphone de manière native. Sous GNOME, ouvrez Paramètres › Son › Entrée et sélectionnez votre périphérique ; la barre de niveau d’entrée devrait bouger lorsque vous parlez. Sous KDE Plasma, ouvrez Paramètres système › Audio et observez le vumètre situé à côté du périphérique d’enregistrement. Supposons que la barre bouge à cet endroit, mais qu’une application ne capte toujours rien. Vous avez alors prouvé que le problème est spécifique à l’application et non à l’ensemble du système ; passez donc aux sections ci-dessous consacrées au routage et aux autorisations. Le tableau répertorie les emplacements graphiques où votre bureau affiche le microphone, ainsi que ce que la valeur affichée à chaque emplacement confirme.

Où chercher	Chemin	Ce que cela confirme
GNOME Jauge d’entrée	Paramètres › Son › Entrée	Indique si le système reçoit un signal et de quel appareil il provient
KDE Panneau audio	Paramètres système › Audio	Le périphérique d'enregistrement actif et son acheminement par application
Réglage du volume	pavucontrol › Périphériques d'entrée	État de mise en sourdine, gain et port matériel sélectionné
Onglet Enregistrement	pavucontrol › Enregistrement	Quelle application capture depuis quel périphérique, en temps réel

Identifiez votre serveur audio avant de procéder au dépannage

Le son sous Linux est organisé en couches, et la solution appropriée dépend de la couche à l’origine du problème. À la base se trouve ALSA, le pilote au niveau du noyau qui communique avec la carte son. Au-dessus, un serveur audio assure le mixage des flux et leur acheminement entre les applications. Deux serveurs dominent le marché. Les distributions modernes intègrent PipeWire. Fedora a été la première à l’adopter, et Ubuntu l’utilise par défaut depuis la version 22.10. PipeWire utilise une couche de compatibilité appelée pipewire-pulse, ce qui permet aux anciens outils de continuer à fonctionner sans modification. Les anciennes versions et certaines configurations conservatrices utilisent encore PulseAudio. Les deux serveurs s’appuient sur ALSA, et un canal mis en sourdine dans ALSA permettra de couper le son de l’un ou de l’autre.

Identifiez votre serveur avant de perdre du temps avec le mauvais outil. Exécutez la commande wpctl status dans un terminal. Une liste claire des sources et des destinations indique que PipeWire est actif. Si la commande est absente, vous êtes très probablement sur PulseAudio ; vérifiez-le avec pactl info. Cela est important car les commandes diffèrent. PipeWire fonctionne avec wpctl, tandis que PulseAudio utilise pactl. L’outil graphique pavucontrol fonctionne avec les deux, car pipewire-pulse répond aux mêmes appels. Le tableau ci-dessous résume les outils principaux et leur fonction respective.

Outil	Type	Fonction
pavucontrol	Graphique	Active les entrées, règle le gain, sélectionne le port et affiche les chemins d’enregistrement par application
alsamixer	Terminal (TUI)	Contrôle la carte ALSA brute : mise en sourdine de la capture, activation de la capture et gain matériel
arecord / aplay	Terminal	Répertorie les périphériques de capture et permet d’enregistrer ou de lire un fichier directement via ALSA
wpctl	Terminal	Répertorie les périphériques PipeWire, définit la source par défaut et active ou désactive sa sourdine

Pourquoi un microphone en état de marche reste-t-il muet sur Linux ?

Un canal de capture ALSA mis en sourdine est la cause principale du problème

ALSA contrôle chaque canal de capture indépendamment, et l’un d’entre eux peut être mis en sourdine au détriment de tous les autres. Lorsque cela se produit, l’indicateur du bureau affiche zéro, quel que soit le niveau de volume que vous réglez dans le logiciel. Cette seule condition est à l’origine d’un plus grand nombre de microphones « défectueux » sous Linux que n’importe quel défaut matériel. Le piège réside dans le fait que cela passe souvent inaperçu depuis le mixeur graphique. La solution se trouve dans alsamixer, un mixeur en mode terminal qui donne accès aux paramètres bruts de la carte. Lancez-le, puis appuyez sur F6 pour sélectionner votre carte son. Appuyez sur F4 pour passer à la vue Capture. Mettez en surbrillance le canal Capture à l’aide des touches fléchées. Si la mention MM apparaît sous la barre, cela signifie qu’il est désactivé ; appuyez sur M pour le réactiver. Un canal de capture doit également être activé. Appuyez sur Space sur l’élément sélectionné jusqu’à ce que la mention CAPTURE s’affiche en rouge, puis augmentez le niveau à l’aide de la flèche vers le haut. De nombreux ordinateurs portables proposent également ici un réglage Internal Mic Boost (amplification du micro interne), réglé sur zéro en usine. En l’augmentant, vous pouvez réactiver un microphone qui semblait ne plus fonctionner.

Source par défaut incorrecte et routage défectueux

Le serveur audio choisit une source par défaut, et ce n’est pas toujours celle que vous souhaitez. Branchez un casque USB, une webcam avec microphone intégré ou un périphérique de capture HDMI, et le serveur peut immédiatement le désigner comme source. Des erreurs de routage se cachent également au sein de certaines applications. PipeWire et PulseAudio permettent à chaque programme d’enregistrer à partir d’un périphérique différent, défini pour chaque flux. Une application peut donc être orientée vers une source qui ne produit aucun signal, alors que la configuration par défaut du système fonctionne. L’onglet Enregistrement de pavucontrol met cela directement en évidence, en répertoriant toutes les applications en cours de capture ainsi que le périphérique qu’elles utilisent. Suspectez d’abord un problème de routage dès lors que le microphone fonctionne dans un programme mais pas dans un autre. Les casques Bluetooth compliquent encore davantage la situation. Un casque utilisant le profil A2DP haute qualité ne dispose d’aucun microphone. Le système doit le basculer vers le profil HSP/HFP avant que le micro à perche n’apparaisse, ce qui entraîne une baisse de la qualité audio.

Autorisations, groupes et applications en bac à sable

Le contrôle d’accès bloque l’accès au microphone sans afficher de message d’erreur. Auparavant, un utilisateur devait appartenir au groupe audio pour pouvoir accéder aux périphériques audio. La plupart des ordinateurs de bureau modernes gèrent cela via la session, mais une installation minimale ou sur serveur peut encore l’exiger. Le confinement des applications (sandboxing) constitue un problème plus récent et plus important. Les applications packagées sous la forme de Flatpak ou Snap s’exécutent au sein d’une couche de confinement qui peut refuser l’accès au microphone même lorsque le reste du système fonctionne normalement. L’application ne reçoit alors que le silence, sans message d’erreur. Vous pouvez vérifier et accorder ces autorisations via Flatseal, un éditeur graphique pour les portails Flatpak, ou depuis le terminal avec la commande flatpak permissions. Les navigateurs ajoutent leur propre couche distincte par-dessus. Un site doit être autorisé au sein du navigateur, quel que soit l’état du système. Nos guides Firefox et Chrome traitent en détail de cette invite dans le navigateur.

Résolution du problème, en commençant par la cause la plus courante

Appliquez ces solutions dans l’ordre. Ne passez pas directement aux mesures les plus radicales. L’ordre est délibéré. Il permet de résoudre d’abord la plupart des cas, avec le moins de perturbations possible. La réactivation du son et le routage sont à l’origine de la plupart des pannes de microphone sous Linux. Ce n’est qu’ensuite que la procédure passe au redémarrage du serveur audio. Après chaque modification, revenez au test du microphone ou à votre indicateur de niveau d’entrée sur le bureau. Vérifiez à nouveau la présence d’un signal avant de passer à l’étape suivante, afin de toujours savoir quelle étape a fait la différence.

Activer le son et configurer l’acheminement avec pavucontrol

Commencez par installer et ouvrir pavucontrol, car cet outil permet de résoudre graphiquement les pannes les plus courantes. Accédez à l’onglet Périphériques d’entrée. Repérez votre microphone et vérifiez que le bouton de mise en sourdine situé à côté de sa barre de niveau n’est pas activé. Augmentez le volume d’entrée s’il est trop faible. Vérifiez le menu déroulant Port, car les ordinateurs portables regroupent souvent un micro interne et une prise casque sous un seul périphérique. Ouvrez ensuite l’onglet Enregistrement pendant que votre application est en cours d’exécution. Chaque application répertoriée dispose d’un sélecteur de périphérique à droite. Indiquez explicitement à l’application récalcitrante le microphone approprié. Cette simple réaffectation résout de nombreux cas signalés comme « cela fonctionne partout sauf ici ». Les applications de visioconférence disposent également de leur propre sélecteur ; veillez donc à configurer le périphérique au sein de celles-ci. Nos guides pour Zoom et Discord vous expliquent pas à pas comment utiliser ces panneaux de configuration.

Activez la capture dans alsamixer, puis effectuez un test depuis le terminal

Accédez à alsamixer lorsque le mixeur graphique affiche un indicateur plat. Suivez les étapes de désactivation du mode silencieux et d’activation de la capture décrites ci-dessus : F6 pour la carte, F4 pour la capture, puis M et Space sur le canal Capture. Une fois le canal armé, vérifiez le chemin d’accès matériel directement via ALSA. Exécutez la commande arecord -l pour répertorier tous les périphériques de capture détectés par le noyau. Si votre microphone n’apparaît pas ici, le problème est lié au pilote ou à la connexion, et non aux paramètres. S’il apparaît, enregistrez un court extrait et lisez-le à l’aide de arecord -d 5 test.wav && aplay test.wav. Le fait d’entendre votre voix confirme que le chemin ALSA fonctionne, ce qui permet de circonscrire le problème au serveur ou à l’application. Sur PipeWire, procédez de la même manière avec wpctl status pour lire l’ID de la source, puis wpctl set-default <id> et wpctl set-mute <id> 0.

Redémarrez le serveur audio lorsque le compteur reste figé

Supposons que le canal ne soit pas mis en sourdine, que la source correcte soit sélectionnée et que le vumètre ne bouge toujours pas. Le serveur audio est probablement bloqué. Il s’agit d’un état connu après une mise en veille, après le remplacement à chaud d’une interface USB ou après une mise à jour du pilote. Le redémarrage du serveur force la reconstruction de l’ensemble du graphe audio sans nécessiter de redémarrage du système. Sous PipeWire, exécutez systemctl --user restart pipewire pipewire-pulse wireplumber. Sous PulseAudio, exécutez pulseaudio -k ; le démon redémarrera alors automatiquement. Le son sera brièvement coupé pendant cette opération. Considérez cette procédure comme un « bouton de réinitialisation » pour une pile bloquée, et non comme une étape de routine. Le tableau ci-dessous établit une correspondance entre les symptômes courants, leurs causes habituelles et la solution la plus rapide.

Symptôme	Cause probable	Solution
Jauge du bureau à zéro, tous les périphériques	Canal de capture mis en sourdine dans ALSA	Réactivez le son et armez la capture dans alsamixer (M, puis Space)
Fonctionne dans une application, mais pas dans une autre	Routage par application vers la mauvaise source	Réattribuez le périphérique dans pavucontrol › Enregistrement
Le micro ne fonctionne plus après avoir branché un casque	La source par défaut a été transférée vers un nouvel appareil	Configurez la source via wpctl set-default ou pavucontrol
Micro du casque Bluetooth manquant	L'appareil est en profil A2DP	Faites-le passer en HSP/HFP dans la liste des profils de pavucontrol
Une seule application n'entend que le silence	Flatpak ou le bac à sable de Snap bloque le micro	Accordez l'accès dans Flatseal ou via flatpak permissions
Le signal ne revient qu’après chaque redémarrage	Le serveur audio est bloqué après la mise en veille	Redémarrez pipewire et wireplumber, ou exécutez pulseaudio -k

Assurer le bon fonctionnement de votre microphone sous Linux

Quelques bonnes habitudes permettent de garantir le bon fonctionnement du microphone une fois qu’il est rétabli. Maintenez le système à jour, car PipeWire et WirePlumber proposent fréquemment des correctifs concernant le routage et le Bluetooth. Épinglez le microphone de votre choix comme source par défaut, afin qu’un casque nouvellement connecté ne puisse pas s’emparer discrètement de cet emplacement. Vérifiez de temps à autre vos autorisations dans Flatpak et n’accordez l’accès au microphone qu’aux applications qui en ont besoin. Lorsque le microphone doit fonctionner à la fois dans un navigateur, une application de bureau et le terminal, testez-le dans chacun de ces environnements. Un microphone qui fonctionne parfaitement avec arecord peut tout de même être bloqué à un niveau supérieur, au sein d’un bac à sable ou d’un onglet de navigateur. Le comportement varie également selon la distribution et l’environnement de bureau ; ainsi, une correction disponible sous Fedora peut se trouver dans un autre menu sous Ubuntu. Si vous passez d’une machine à l’autre, notre guide Chromebook présente les mêmes vérifications sur ChromeOS.

Foire aux questions

Comment savoir si mon système utilise PipeWire ou PulseAudio ?

Exécutez wpctl status dans un terminal. La présence d’une liste de sources et de destinations indique que PipeWire est en cours d’exécution. Si la commande n’est pas disponible, exécutez pactl info et consultez la ligne Server Name. Fedora et Ubuntu 22.10 ou versions plus récentes utilisent PipeWire par défaut ; les versions antérieures utilisent PulseAudio.

Mon microphone fonctionne avec arecord, mais pas dans mes applications. Pourquoi ?

Le fait que la capture via arecord fonctionne prouve que le chemin d’accès matériel ALSA est correct. Le problème provient du serveur audio ou de l’application. Ouvrez l’onglet Enregistrement dans pavucontrol et configurez l’application pour qu’elle utilise la source appropriée. Si l’application utilise Flatpak, vérifiez ses autorisations d’accès au microphone dans Flatseal.

Pourquoi le microphone de mon casque Bluetooth n'apparaît-il pas ?

Le mode A2DP haute qualité ne prend pas en charge le microphone. Le casque doit basculer vers le profil HSP ou HFP pour que son microphone sur tige soit disponible. Ouvrez pavucontrol, recherchez le périphérique dans la liste Configuration ou Profils, puis sélectionnez le profil du casque. Attendez-vous à une baisse de la qualité audio lorsque vous effectuez cette opération.

Comment réactiver le microphone depuis le terminal ?

Sur ALSA, ouvrez alsamixer, appuyez sur F4 pour afficher la vue de capture, sélectionnez Capture, puis appuyez sur M pour réactiver le microphone. Sur PipeWire, recherchez l’ID de la source à l’aide de wpctl status, puis exécutez wpctl set-mute <id> 0. Un canal de capture ALSA désactivé est la cause la plus courante d’une entrée silencieuse.

Comment redémarrer l’audio Linux sans redémarrer le système ?

Sous PipeWire, exécutez systemctl --user restart pipewire pipewire-pulse wireplumber. Sous PulseAudio, exécutez pulseaudio -k : le démon redémarrera alors automatiquement. Le son est coupé pendant une seconde, le temps que le serveur reconstruise son graphe. N’utilisez cette méthode qu’après l’échec des vérifications de réactivation du son et de routage.