Installer le driver NVIDIA sous Linux : le guide par distribution
Écrit par Vincent
2 août 2026
Le driver NVIDIA Linux se décline en deux variantes de module noyau : une variante ouverte et une variante propriétaire.
Le choix entre les deux ne dépend pas de vos préférences mais de l’architecture de votre carte graphique.
Installez-le toujours depuis les dépôts de votre distribution plutôt que depuis le fichier .run du site NVIDIA, sous peine de devoir le réinstaller à chaque mise à jour du noyau.
L’essentiel
Variante à choisir : ouverte pour Turing (GeForce GTX 16xx et RTX 20xx) et plus récent, propriétaire pour Maxwell, Pascal et Volta.
Versions au 1er août 2026 : branche Production 595.84, branche Fonctionnalité 610.43.03, branche Legacy 470.256.02.
Distributions couvertes : Ubuntu et Linux Mint, Debian 13, Fedora 44, Arch et Manjaro, openSUSE Leap et Tumbleweed.
Point de blocage le plus fréquent : le Secure Boot refuse de charger un module non signé, ce qui se traduit par un écran noir. Le comportement diffère selon la distribution.
Prérequis : un compte avec les droits sudo, environ 20 minutes, un redémarrage obligatoire.
Procédure conforme aux documentations officielles listées en fin d’article, consultées le 1er août 2026.
Driver NVIDIA Linux : module ouvert ou propriétaire ?
Depuis la version 515 du pilote, NVIDIA publie le code source de ses modules noyau. Chaque version existe donc en deux variantes, et c’est le point qui détermine tout le reste de la procédure.
La variante ouverte utilise ces modules open source. NVIDIA la recommande pour les architectures Turing, Ampere, Ada Lovelace, Hopper et Blackwell. Attention à une exception contre-intuitive : Volta, pourtant contemporain de Turing, n’est pas pris en charge par la variante ouverte.
La variante propriétaire utilise les anciens modules fermés. Elle reste nécessaire pour Maxwell, Pascal et Volta. En revanche, elle ne prend pas en charge Blackwell, c’est-à-dire les GeForce RTX 50xx et suivantes.
Architecture GPU
Séries commerciales
Variante à installer
Blackwell et plus récent
RTX 50xx
Ouverte, obligatoire
Ada Lovelace
RTX 40xx
Ouverte, recommandée
Ampere
RTX 30xx
Ouverte, recommandée
Turing
GTX 16xx, RTX 20xx
Ouverte, recommandée
Volta
Titan V, Quadro GV100
Propriétaire uniquement
Pascal
GTX 10xx
Propriétaire uniquement
Maxwell
GTX 900, GTX 750 et 750 Ti
Propriétaire uniquement
Kepler et antérieur
GTX 600, GTX 700 hors 750 et 750 Ti
Pilote legacy ou nouveau
Deux pièges dans ce tableau. Les GTX 750 et 750 Ti portent une référence de série 700 mais reposent sur une puce Maxwell : elles fonctionnent avec le pilote propriétaire courant.
Volta, malgré une sortie en 2018, reste cantonné à la variante propriétaire. C’est l’architecture qui décide, jamais l’année de sortie.
Identifier sa carte graphique
Une commande suffit à connaître le modèle exact :
# Affiche les contrôleurs graphiques détectés sur le bus PCI
lspci | grep -iE "3d|display|vga" | grep -i nvidia
Le code entre crochets donne le modèle commercial, et le préfixe qui le précède indique l’architecture : GK pour Kepler, GM pour Maxwell, GP pour Pascal, GV pour Volta, TU pour Turing, GA pour Ampere, AD pour Ada Lovelace, GB pour Blackwell.
Dans l’exemple ci-dessus, GM206 désigne une carte Maxwell, qui réclame donc la variante propriétaire.
Si plusieurs lignes s’affichent, votre machine possède plusieurs GPU.
Sur un ordinateur portable, c’est le cas classique d’une configuration hybride Intel ou AMD plus NVIDIA, dite Optimus, qui demande une configuration supplémentaire une fois le pilote installé. Chaque distribution la documente séparément : reportez-vous à sa page dédiée.
Prérequis
Un compte disposant des droits sudo, une connexion réseau, et un redémarrage en fin de procédure. Ce redémarrage n’est pas optionnel : le pilote libre nouveau et le pilote NVIDIA sont incompatibles, et décharger nouveau à chaud mène généralement à une console noire.
Cette manipulation touche à l’affichage, et une erreur peut vous laisser sans interface graphique au démarrage suivant. Avant de commencer, un instantané système avec Timeshift vous garantit un retour en arrière propre.
Étape 1 : régler la question du Secure Boot
Cette étape vient en premier parce que sur plusieurs distributions, l’ordre compte : la clé doit être enrôlée avant l’installation du pilote.
Sur une machine avec Secure Boot activé, le noyau refuse de charger un module non signé. Le pilote s’installe alors sans erreur visible, puis ne se charge pas au redémarrage.
Résultat courant : un écran noir, ou une session graphique de secours en basse résolution.
Le comportement diffère radicalement d’une distribution à l’autre, ce qui explique que les procédures trouvées en ligne se contredisent souvent.
Distribution
Ce qui se passe
Ubuntu, Linux Mint via ubuntu-drivers
Modules précompilés signés par Canonical. Rien à faire.
Ubuntu via DKMS
Modules non signés par Canonical. Enrôlement manuel nécessaire.
Debian
DKMS. Clé à enrôler avant d’installer le pilote.
Fedora, RPM Fusion
Clé à créer et importer avant d’installer le kmod.
openSUSE
Paire de clés créée et signée automatiquement, à valider au redémarrage.
Arch
Paquet binaire nvidia-open non signé. Signature à gérer manuellement.
Attention
Sur Debian et Fedora, l’enrôlement de la clé doit précéder l’installation du pilote.
Si vous inversez l’ordre, le module est construit sans être signé, le pilote ne se charge pas, et vous obtenez un écran noir au démarrage suivant. Il faut alors reconstruire le module après coup.
Le principe est toujours le même : vous générez une paire de clés dite MOK, pour Machine Owner Key, vous demandez son importation, puis vous la validez physiquement au redémarrage.
Voici la procédure Fedora, la plus explicitement documentée par le projet qui empaquette le pilote.
# Installe les outils nécessaires
sudo dnf install kmodtool akmods mokutil openssl
# Génère la paire de clés avec les valeurs par défaut
sudo kmodgenca -a
# Demande l'enrôlement de la clé publique
sudo mokutil --import /etc/pki/akmods/certs/public_key.der
La dernière commande réclame un mot de passe à usage unique. Choisissez-en un simple, sans caractère spécial : vous devrez le saisir au redémarrage sur un clavier en disposition américaine.
Sur openSUSE, la mécanique diffère : la paire de clés est créée automatiquement à l’installation du pilote et le mot de passe demandé au redémarrage est celui de root, pas un mot de passe temporaire.
Notez aussi qu’à chaque mise à jour du pilote, l’ancienne clé est marquée pour suppression : une entrée Delete MOK apparaît alors en plus de Enroll MOK, et il faut la traiter de la même manière.
Au redémarrage, un écran bleu intitulé MOK Manager apparaît avant le chargement du système. Sélectionnez successivement Enroll MOK, puis Continue, puis Yes, saisissez le mot de passe, et choisissez Reboot.
Si vous manquez cet écran, la clé n’est pas enrôlée et le module ne se chargera pas. Relancez la commande sudo mokutil --import et redémarrez de nouveau.
Un point de sécurité à connaître sur Fedora : la clé privée reste stockée en clair dans /etc/pki/akmods sur votre disque.
RPM Fusion demande de considérer le chiffrement de la partition racine comme une exigence obligatoire dans ce cas de figure, faute de quoi la clé est lisible par quiconque accède physiquement à la machine.
Désactiver le Secure Boot dans l’UEFI reste possible et résout le problème en une manipulation. C’est un contournement, pas une solution : vous perdez une protection contre les rootkits chargés au démarrage, sur l’ensemble du système, y compris un éventuel double amorçage avec Windows.
Étape 2 : installer le driver NVIDIA Linux selon votre distribution
L’installation du driver NVIDIA Linux suit une méthode propre à chaque famille de distributions. Si vous hésitez encore sur la distribution à adopter, notre comparatif des distributions Linux vous aidera à situer la vôtre parmi les grandes familles.
Ubuntu et Linux Mint
Canonical fournit un outil dédié, ubuntu-drivers, que la documentation officielle recommande. Il présente un avantage net sur le Secure Boot : il installe par défaut des modules précompilés et signés par Canonical, qui se chargent sans intervention de votre part.
Mettez d’abord le système à jour, puis redémarrez si le noyau a changé :
sudo apt update && sudo apt upgrade
Listez ensuite les pilotes disponibles pour votre carte :
# Affiche les pilotes candidats pour le matériel détecté
sudo ubuntu-drivers list
Laissez enfin l’outil choisir le pilote le mieux adapté :
sudo ubuntu-drivers install
Pour imposer une branche précise, reprenez le numéro exact affiché par la commande list, en remplaçant XXX ci-dessous :
# Installe explicitement une branche donnée
sudo ubuntu-drivers install nvidia:XXX
Les paquets suffixés -server visent les serveurs et le calcul, pas un poste de bureau. Ne les installez pas pour un usage classique.
Debian 13 (trixie)
Les pilotes NVIDIA vivent dans les composants non libres du dépôt. Vérifiez que contrib, non-free et non-free-firmware sont activés, au minimum pour la suite de base et la suite de sécurité.
Selon l’âge de votre installation, la configuration se trouve dans /etc/apt/sources.list ou dans un fichier .sources de /etc/apt/sources.list.d/ :
deb http://deb.debian.org/debian/ trixie main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security/ trixie-security main contrib non-free non-free-firmware
Installez ensuite les en-têtes du noyau, indispensables à la compilation du module par DKMS :
Deux limites à connaître. La série 550 empaquetée dans Debian 13 ne prend pas en charge Blackwell : pour une RTX 50xx, il faut passer par les dépôts NVIDIA.
Si vous utilisez un noyau issu de trixie-backports, vous devez installer le pilote depuis trixie-backports également, les deux étant étroitement couplés.
Fedora 44
Fedora passe par RPM Fusion, dont la section nonfree doit être active. Le paquet akmod-nvidia reconstruit automatiquement le module à chaque mise à jour du noyau.
# Met le système à jour, puis redémarrez si le noyau a changé
sudo dnf update -y
# Installe le pilote courant
sudo dnf install akmod-nvidia
Pour une carte Maxwell ou Pascal, la branche 595 livrée par défaut sur Fedora 44 ne convient plus : RPM Fusion documente une série legacy pour les GPU sortis entre 2014 et 2017.
Les cartes Volta ne sont explicitement couvertes par aucune de ces deux séries dans la documentation RPM Fusion. Si vous possédez une Titan V ou une Quadro GV100, vérifiez la compatibilité de la branche avant d’installer quoi que ce soit.
Après la transaction, la construction du module prend jusqu’à cinq minutes. Ne redémarrez pas avant qu’elle soit terminée. Vérifiez son achèvement ainsi :
modinfo -F version nvidia
Une version s’affiche si tout va bien. Le message modinfo: ERROR: Module nvidia not found signifie que la construction est encore en cours, ou qu’elle a échoué.
Une commande dnf autoremove peut ensuite supprimer akmod-nvidia en le considérant comme inutile. Protégez-le :
sudo dnf mark user akmod-nvidia
Arch Linux et Manjaro
Le paquet officiel se trouve dans le dépôt Extra. Choisissez la variante selon votre noyau :
Pour une carte Maxwell, Pascal ou Volta, la variante ouverte ne fonctionnera pas.
Le paquet nvidia-580xx-dkms est disponible via AUR, accompagné de nvidia-580xx-utils : l’espace utilisateur est versionné, et le paquet nvidia-utils standard entrerait en conflit. Désinstallez toute variante ouverte déjà présente avant la bascule.
Le paquet nvidia-utils met automatiquement nouveau sur liste noire au redémarrage. Si vous exécutez des applications 32 bits, ajoutez lib32-nvidia-utils depuis le dépôt multilib.
openSUSE Leap et Tumbleweed
Les pilotes sont fournis par le dépôt NVIDIA dédié à openSUSE, ajouté par défaut sur Leap et Tumbleweed. Vérifiez d’abord s’il est déjà présent :
Si la commande ne renvoie rien, ajoutez le dépôt correspondant à votre version :
# Leap 16.0 : adaptez le numéro de version à la vôtre
sudo zypper addrepo https://download.nvidia.com/opensuse/leap/16.0/ nvidia
# Tumbleweed
sudo zypper addrepo https://download.nvidia.com/opensuse/tumbleweed/ nvidia
openSUSE utilise une nomenclature propre, à connaître pour choisir le bon paquet. La série G07 correspond à la variante ouverte pour les GPU Turing et plus récents ; les séries G04, G05 et G06 regroupent les pilotes legacy propriétaires destinés aux cartes antérieures.
Vérifiez d’abord votre GPU :
inxi -aG
Pour une carte Turing ou plus récente, une seule commande suffit :
Le suffixe signed a une conséquence pratique directe : ce paquet est précompilé et signé pour le Secure Boot, ce qui vous évite la génération manuelle de clé décrite à l’étape 1.
Pour une carte antérieure à Turing, orientez-vous vers les séries legacy G04, G05 ou G06 selon le modèle.
Attention toutefois : le mainteneur des paquets NVIDIA chez SUSE recommande de verrouiller plusieurs paquets G06 avec zypper addlock, car ils sont régulièrement sélectionnés à tort par le gestionnaire de paquets. Consultez sa documentation avant d’installer une série legacy.
Si vous migrez d’une série G06 vers G07, la bascule n’est pas automatique : désinstallez d’abord l’ensemble des paquets NVIDIA existants.
Étape 3 : vérifier le driver NVIDIA Linux
Redémarrez, puis interrogez le pilote :
nvidia-smi
La commande affiche un tableau avec la version du pilote, le modèle du GPU, sa température et sa consommation. Si ce tableau s’affiche, l’installation est réussie.
Vérifiez au besoin que les modules sont chargés :
lsmod | grep nvidia
Vous devez voir apparaître nvidia, nvidia_modeset et nvidia_drm.
Le module nvidia_uvm n’est chargé qu’à la demande, lors d’un usage CUDA ou d’un appel à nvidia-smi : son absence n’est pas un défaut. Une sortie entièrement vide, en revanche, signifie que le pilote n’est pas chargé.
Enfin, nouveau ne doit plus être présent en mémoire. Cette commande ne doit rien renvoyer :
lsmod | grep nouveau
Désinstaller le pilote et revenir à nouveau
Attention
Les commandes ci-dessous suppriment le pilote graphique en cours d’utilisation. Exécutez-les depuis une console texte ou juste avant un redémarrage, et assurez-vous que le pilote libre nouveau pourra prendre le relais, faute de quoi vous démarrerez sans interface graphique.
# Ubuntu et Linux Mint
sudo apt purge --auto-remove '*nvidia*'
# Debian : le firmware nouveau est dans un paquet dédié
sudo apt purge --auto-remove '*nvidia*'
sudo apt install firmware-nvidia-graphics
# Fedora
sudo dnf remove 'xorg-x11-drv-nvidia*'
# Arch Linux
sudo pacman -Rns nvidia-open nvidia-utils
# openSUSE : identifiez d'abord les paquets issus du dépôt NVIDIA
zypper lr
zypper search -ir NVIDIA
Sur openSUSE, la désinstallation ne suffit pas : il faut aussi retirer la mise sur liste noire de nouveau. Vérifiez qu’aucun fichier de /etc/modprobe.d/ ne contient blacklist nouveau, retirez rd.driver.blacklist=nouveau de /etc/default/grub, puis régénérez la configuration et l’initrd :
Éditer /etc/default/grub sans régénérer grub.cfg n’a aucun effet : nouveau resterait bloqué au démarrage.
Redémarrez pour terminer.
Erreurs courantes du driver NVIDIA Linux
Écran noir après le redémarrage
Le module ne s’est pas chargé, presque toujours pour une raison de signature Secure Boot. Basculez sur une console texte avec Ctrl+Alt+F3, puis cherchez un refus explicite dans les journaux :
sudo dmesg | grep -i nvidia
Un message du type Lockdown: modprobe: unsigned module loading is restricted ou Required key not available confirme le diagnostic : la clé n’est pas enrôlée. Reprenez l’étape 1. Inutile de démarrer sur un noyau antérieur, la clé manque pour tous les noyaux.
nvidia-smi renvoie « No devices were found »
Le pilote libre nouveau est encore chargé et entre en conflit avec le pilote NVIDIA. Vérifiez-le, puis mettez-le sur liste noire :
lsmod | grep nouveau
echo "blacklist nouveau" | sudo tee /etc/modprobe.d/disable-nouveau.conf
echo "options nouveau modeset=0" | sudo tee -a /etc/modprobe.d/disable-nouveau.conf
sudo rmmod nouveau || true
sudo update-initramfs -u
Redémarrez pour appliquer le changement. La dernière commande est spécifique à Debian et Ubuntu ; sur Fedora et openSUSE, utilisez sudo dracut -f --regenerate-all.
« Driver/library version mismatch »
Les bibliothèques utilisateur ont été mises à jour alors que le module noyau chargé est resté sur l’ancienne version. Le cas se produit typiquement après une mise à jour du système. Un redémarrage recharge le module à jour et résout le problème.
La compilation du module échoue
Sur Debian et Ubuntu, le message No kernel headers were found, skipping module build indique que les en-têtes correspondant à votre noyau manquent.
Installez le métapaquet générique plutôt que la version figée affichée dans le message, qui redeviendra fausse à la prochaine mise à jour du noyau :
Si l’échec persiste avec un message Bad return status for module build, votre noyau est probablement trop récent pour la version du pilote. C’est fréquent après l’installation d’un noyau issu des backports sans le pilote correspondant.
Conflit après une installation par fichier .run
L’installateur .run de NVIDIA écrase des bibliothèques du système et n’est pas suivi par le gestionnaire de paquets. Le mélanger avec les paquets de la distribution casse l’installation dans la quasi-totalité des cas. Purgez complètement l’un avant d’installer l’autre.
Questions fréquentes
Faut-il choisir la variante ouverte ou propriétaire ?
L’architecture de votre carte décide, pas vous. Turing et plus récent prennent la variante ouverte, que NVIDIA recommande désormais par défaut. Maxwell, Pascal et Volta n’ont d’autre choix que la propriétaire. Les GeForce RTX 50xx et suivantes ne fonctionnent qu’avec la variante ouverte.
Faut-il désactiver le Secure Boot pour installer le pilote ?
Non, sauf en dernier recours. Sur Ubuntu et Linux Mint via ubuntu-drivers, comme sur openSUSE avec les paquets signés, les modules se chargent sans manipulation particulière.
Sur Debian, Fedora et Arch, l’enrôlement d’une clé MOK prend quelques minutes et préserve une protection utile contre les rootkits de démarrage.
Existe-t-il une application NVIDIA pour Linux ?
L’application NVIDIA disponible sous Windows n’a pas d’équivalent sous Linux. L’outil fourni s’appelle nvidia-settings : il gère la résolution, la fréquence de rafraîchissement, la configuration multi-écrans et affiche la température du GPU.
Comment passer de la variante propriétaire à la variante ouverte ?
Désinstallez complètement la première avant d’installer la seconde, en suivant la section de désinstallation de cet article.
Les deux variantes fournissent des modules portant les mêmes noms : les faire cohabiter produit des conflits de paquets ou un système qui ne démarre plus en mode graphique.
Que faire d’une carte trop ancienne pour le pilote courant ?
Les branches legacy restent disponibles : 580xx pour Maxwell et Pascal, 470xx pour Kepler, 390xx pour Fermi.
Leur durée de maintenance dépend de la politique de support publiée par NVIDIA, qu’il faut vérifier au cas par cas. Sur une carte de cette génération, le pilote libre nouveau est souvent le choix le plus raisonnable pour un usage bureautique.
Le pilote libre nouveau suffit-il ?
Pour de la bureautique et de la navigation, oui. Il ne permet en revanche ni les performances 3D nécessaires au jeu, ni CUDA, ni l’encodage matériel NVENC. Le pilote propriétaire reste indispensable dès que le GPU doit réellement travailler.
Conclusion
Pour installer correctement le driver NVIDIA Linux, deux décisions doivent être prises avant la première commande : choisir la variante adaptée à l’architecture de votre carte et gérer le Secure Boot selon votre distribution.
Sur Ubuntu et Linux Mint, ubuntu-drivers install règle les deux questions d’un coup. Sur openSUSE, les paquets signés s’en chargent presque entièrement.
Sur Debian, Fedora et Arch, l’enrôlement de la clé MOK doit précéder l’installation du pilote, faute de quoi l’écran noir au redémarrage est le résultat le plus probable.
Si votre objectif est le jeu, l’installation du pilote n’est que la première étape : notre comparatif des distributions Linux pour le gaming détaille les distributions qui livrent déjà une image préconfigurée pour NVIDIA.
Pour tirer le meilleur de la machine une fois le pilote en place, le guide pour optimiser les performances de Linux couvre les réglages qui comptent vraiment.
Dernière vérification des commandes et des versions : 1er août 2026, d’après les documentations officielles listées ci-dessous.
Vincent est le créateur de MémoLinux. Venu de Windows par curiosité, il est resté sur Linux pour sa logique et le plaisir de comprendre ce qui se passe sous le capot. Il documente ici les commandes et les procédures qu’il utilise lui-même, avec leurs sources officielles et leur date de vérification.
