Tauri 2.12 et Rust 1.90 : Tutoriel App Desktop [2026]

Tauri vient de passer en version 2.12.3 et le changement le plus discret de cette mise à jour est aussi le plus contraignant pour les développeurs : la version minimale de Rust exigée (MSRV) grimpe désormais à Rust 1.90. Si vous avez un projet Tauri qui tourne encore sur une toolchain plus ancienne, la prochaine mise à jour de dépendances risque de casser votre build sans prévenir. Ce tutoriel vous montre comment partir de zéro, installer la bonne version de Rust, générer un projet Tauri 2.12 propre et livrer une application desktop multiplateforme fonctionnelle, avec mises à jour automatiques et packaging pour Windows, macOS et Linux, en douze étapes et environ deux heures de travail.

Le mot-clé « tauri » dépasse les 2 900 recherches mensuelles en France selon les données DataForSEO consultées pour cet article, avec une concurrence encore qualifiée de faible. Autrement dit, la demande est là, mais le contenu francophone à jour sur la version 2.12 reste rare. C’est le créneau que ce guide vient combler, avec des commandes testées, des extraits de code réels et une liste de pièges qui font perdre des heures aux débutants.

Google · Sources préférées

Ne manquez aucune actu tech sur Google

Ajoutez TrendinTech France une seule fois dans l'app Google pour retrouver nos articles dans vos suggestions.

Ajouter

Qu’est-ce que Tauri 2.12 et pourquoi choisir Rust pour le desktop en 2026

Tauri est un framework open source qui permet de construire des applications desktop et mobiles multiplateformes en combinant un frontend web (React, Vue, Svelte, ou simple HTML/CSS/JS) avec un backend écrit en Rust. Contrairement à Electron, qui embarque un moteur Chromium complet dans chaque application, Tauri s’appuie sur le moteur de rendu natif du système : WebView2 sur Windows, WebKit sur macOS, et WebKitGTK sur Linux. Le résultat concret, c’est un exécutable final nettement plus léger et une consommation mémoire au repos largement inférieure.

Le projet officiel décrit Tauri comme un moyen de construire des applications desktop et mobiles plus petites, plus rapides et plus sécurisées avec un frontend web, et le dépôt GitHub de l’organisation tauri-apps dépasse aujourd’hui les 111 000 étoiles et plus de 4 000 forks, avec une activité de développement mise à jour le 12 octobre 2026. Cette traction s’explique en partie par l’engouement pour Rust lui-même : selon l’enquête développeurs 2025 de Stack Overflow, Rust est utilisé par environ 14 % des répondants pour du développement intensif, et c’est surtout le langage le plus admiré de l’enquête, avec 72 % des répondants qui expriment de l’admiration pour lui (source : Stack Overflow Developer Survey 2025).

Pour un développeur JavaScript ou TypeScript qui n’a jamais touché à Rust, l’intérêt de Tauri est justement de ne pas avoir à réécrire tout son frontend. Seule la partie « système » de l’application (accès fichiers, notifications natives, fenêtres, mises à jour) passe par des commandes Rust, le reste de l’interface reste du code web classique. C’est ce qui rend Tauri accessible à des équipes qui n’ont pas de compétence Rust approfondie, tout en gardant la possibilité d’écrire du code bas niveau performant là où c’est utile.

Tauri vs Electron en 2026 : ce que montrent les chiffres

Avant de se lancer dans l’installation, il est utile de comprendre pourquoi autant d’équipes migrent leurs applications Electron vers Tauri. Le tableau ci-dessous résume les différences structurelles entre les deux approches, telles que documentées par le projet Tauri et observées sur des projets comparables.

Critère	Tauri 2.12	Electron
Moteur de rendu	WebView natif du système (WebView2, WebKit, WebKitGTK)	Chromium embarqué dans chaque app
Langage backend	Rust	Node.js
Taille typique d’un installateur	Quelques Mo à ~15 Mo pour une app simple	Souvent 80 à 150 Mo, Chromium inclus
Modèle de sécurité	Permissions et capabilities explicites par fenêtre	Accès Node.js large par défaut si mal configuré
Support mobile	Android et iOS en bêta avancée	Non supporté nativement
Tests automatisés	tauri-driver (WebDriver) en version 2.1.0	Spectron déprécié, alternatives tierces

La ligne la plus parlante pour la plupart des équipes reste la taille de l’installateur et la consommation mémoire, directement liées à l’absence d’un Chromium complet embarqué dans chaque build Tauri. Cela ne veut pas dire qu’Electron est un mauvais choix : son écosystème est plus mature sur certains points, notamment le débogage via les DevTools Chrome et la disponibilité de modules Node.js existants. Mais pour une application où la taille de téléchargement, la consommation RAM ou la sécurité par défaut comptent, Tauri a un avantage structurel difficile à combler pour Electron.

Tauri face à Flutter Desktop et .NET MAUI : un troisième regard

Electron n’est pas le seul concurrent de Tauri sur le terrain du desktop multiplateforme. Flutter Desktop, porté par Google, et .NET MAUI, porté par Microsoft, visent le même objectif avec des approches techniques très différentes. Flutter Desktop compile son propre moteur de rendu graphique (Skia ou Impeller selon la version) et dessine chaque pixel lui-même, sans passer par le moteur web du système. Cela donne un rendu identique sur toutes les plateformes, au prix d’un binaire plus lourd que Tauri et d’un écosystème de widgets qui reste pensé mobile-first.

.NET MAUI, de son côté, s’appuie sur des composants d’interface natifs par plateforme (UIKit sur macOS, WinUI sur Windows), ce qui donne une intégration visuelle très fidèle à chaque OS, mais impose d’écrire la logique métier en C# plutôt qu’en JavaScript ou TypeScript. Pour une équipe déjà familière avec React ou Vue, Tauri reste souvent le chemin le plus court vers une application desktop fonctionnelle, car il recycle directement les compétences frontend existantes et ne demande d’apprendre Rust que pour la couche système, pas pour l’intégralité de l’interface.

Le choix entre ces trois options dépend surtout de ce que l’équipe sait déjà faire. Une équipe mobile Flutter qui veut étendre son app existante au desktop ira naturellement vers Flutter Desktop. Une équipe .NET qui cible exclusivement Windows et macOS avec un budget design soigné choisira souvent .NET MAUI. Une équipe web, qui a déjà un frontend React ou Vue et veut juste l’emballer en application desktop légère avec un accès système minimal, trouvera dans Tauri le compromis le plus rapide à mettre en production.

Prérequis : les versions exactes à installer avant de commencer

Ce tutoriel a été rédigé avec les versions suivantes, publiées entre fin septembre et le 10 octobre 2026. Utiliser des versions plus anciennes de Rust provoquera des erreurs de compilation dès l’étape 4, puisque Tauri 2.12 impose une MSRV (version minimale supportée) à Rust 1.90.

Composant	Version requise	Date de publication
Rust (toolchain + rustc)	1.90 ou supérieur	MSRV imposée par Tauri 2.12
Tauri (crate core)	2.12.3	10 octobre 2026
Tauri CLI	2.12.2	10 octobre 2026
@tauri-apps/api (npm)	2.12.3	10 octobre 2026
@tauri-apps/cli (npm)	2.12.2	10 octobre 2026
tauri-build	2.7.2	10 octobre 2026
tauri-runtime	2.12.1	30 septembre 2026
Tao (fenêtrage)	0.37.1	26 septembre 2026
tauri-driver (tests)	2.1.0	26 septembre 2026
Node.js	20 LTS ou supérieur	recommandé par la doc officielle

Vous aurez aussi besoin, selon votre système, de dépendances spécifiques : les outils de compilation Microsoft C++ sur Windows, Xcode Command Line Tools sur macOS, et les paquets GTK/WebKitGTK sur Linux. Ces dépendances sont détaillées à l’étape suivante.

Pourquoi suivre la cadence de release de l’écosystème Tauri

Un point que beaucoup de tutoriels passent sous silence : Tauri n’est pas un seul paquet, mais une dizaine de crates et de paquets npm qui évoluent ensemble, parfois à des rythmes légèrement différents. Entre le 26 septembre et le 10 octobre 2026, l’écosystème a vu sortir coup sur coup Tauri 2.12.0, puis 2.12.3 pour le crate core, tauri-runtime 2.12.1, tauri-build 2.7.2, Tao 0.37.1 pour la gestion des fenêtres, et tauri-driver 2.1.0 pour les tests WebDriver. Ignorer cette cadence et ne mettre à jour qu’un seul de ces paquets à la fois est l’une des causes les plus fréquentes d’incompatibilités silencieuses dans un projet Tauri qui vieillit.

La bonne pratique consiste à traiter la mise à jour de Tauri comme un bloc cohérent plutôt que comme des dépendances Cargo isolées. Avant de lancer cargo update sur un projet existant, vérifiez d’abord la version de Rust installée localement et en CI, car c’est elle qui détermine si la nouvelle MSRV (1.90 pour Tauri 2.12) est satisfaite. Ensuite, mettez à jour le crate tauri, le CLI, et le package npm @tauri-apps/api dans la même passe, puis relancez l’intégralité de votre suite de tests, y compris les tests WebDriver via tauri-driver si vous en avez, avant de fusionner la mise à jour.

Cette discipline coûte quelques minutes supplémentaires à chaque cycle, mais elle évite le scénario classique où une équipe découvre, le jour d’une release client, qu’un changement mineur dans un plugin (comme la relecture de l’option allowDowngrades directement depuis la configuration plutôt que depuis l’appel de la commande) casse un comportement qui fonctionnait sans accroc depuis des mois.

Étape 1 : installer Rust 1.90 avec rustup

Rustup est le gestionnaire officiel de toolchains Rust. Il installe rustc, cargo et le gestionnaire de composants en une seule commande, et permet de mettre à jour facilement vers une version plus récente quand Tauri relève sa MSRV, comme c’est le cas avec cette version 2.12.

# macOS et Linux
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# Windows (PowerShell) : téléchargez rustup-init.exe depuis rustup.rs
# puis exécutez-le avec l'option par défaut (toolchain stable)

# Vérifier la version installée
rustc --version
cargo --version

Si vous avez déjà Rust installé depuis un certain temps, mettez-le à jour avant de continuer, sinon la compilation du projet Tauri échouera avec une erreur de type « package requires rustc 1.90 or newer ».

rustup update stable
rustup default stable
rustc --version   # doit afficher 1.90.0 ou plus récent

Étape 2 : installer les dépendances système selon votre plateforme

Tauri a besoin d’un webview et d’un compilateur C/C++ natif pour lier les bibliothèques système. Les dépendances diffèrent selon l’OS de développement.

Windows : installez les Build Tools de Visual Studio avec la charge de travail « Développement Desktop en C++ », et assurez-vous que WebView2 Runtime est présent (il l’est par défaut sur Windows 10/11 à jour).
macOS : installez les outils en ligne de commande Xcode avec xcode-select --install. WebKit est déjà fourni par le système.
Linux (Debian/Ubuntu) : installez les paquets de développement GTK, WebKitGTK et les bibliothèques liées à l’AppIndicator et à librsvg.

# Ubuntu / Debian
sudo apt update
sudo apt install -y libwebkit2gtk-4.1-dev build-essential curl wget file \
  libxdo-dev libssl-dev libayatana-appindicator3-dev librsvg2-dev

Sur les distributions basées sur Fedora ou Arch, les noms de paquets changent légèrement (webkit2gtk4.1-devel sur Fedora, webkit2gtk-4.1 sur Arch), mais la logique reste identique : il vous faut WebKitGTK, les outils de compilation et les bibliothèques système de base.

Étape 3 : installer Node.js, un gestionnaire de paquets et le CLI Tauri

Tauri ne dépend pas de Node.js pour fonctionner en production, mais l’outillage de développement (le CLI, les scripts de build frontend) s’appuie sur l’écosystème JavaScript. Installez Node.js 20 LTS ou supérieur, puis choisissez un gestionnaire de paquets. pnpm est recommandé par la documentation officielle pour sa rapidité et sa gestion plus stricte des dépendances.

npm install -g pnpm
pnpm --version

# Vérifier Node.js
node --version   # 20.x ou plus récent recommandé

Le CLI Tauri (version 2.12.2 au moment de la rédaction) sera installé automatiquement comme dépendance de projet à l’étape suivante, mais vous pouvez aussi l’installer globalement si vous préférez enchaîner plusieurs projets Tauri sans réinstaller le CLI chaque fois.

Étape 4 : générer votre premier projet avec create-tauri-app

L’outil officiel create-tauri-app propose un assistant interactif qui génère la structure complète du projet : backend Rust, configuration Tauri, et scaffold frontend selon le framework choisi (React, Vue, Svelte, SolidJS ou vanilla JS).

pnpm create tauri-app@latest

# L'assistant va demander :
# - Nom du projet : mon-app-tauri
# - Identifiant du bundle : com.exemple.monapptauri
# - Langage frontend : TypeScript / JavaScript
# - Framework : React
# - Gestionnaire de paquets : pnpm

cd mon-app-tauri
pnpm install
pnpm tauri dev

La commande pnpm tauri dev compile le backend Rust en mode debug, lance le serveur de développement du frontend, puis ouvre une fenêtre native avec le rendu de votre application. La première compilation Rust peut prendre deux à quatre minutes selon votre machine, les suivantes sont incrémentales et beaucoup plus rapides grâce au cache de cargo.

Étape 5 : comprendre la structure du projet généré

Un projet Tauri 2.12 généré avec React et TypeScript suit une organisation en deux parties bien séparées, ce qui facilite la collaboration entre développeurs frontend et développeurs Rust sur une même base de code.

/src : le code frontend React/TypeScript classique, avec composants, hooks et styles.
/src-tauri/src/main.rs : le point d’entrée Rust de l’application desktop.
/src-tauri/src/lib.rs : où l’on déclare généralement les commandes Rust exposées au frontend.
/src-tauri/Cargo.toml : les dépendances Rust du projet, y compris les plugins Tauri.
/src-tauri/tauri.conf.json : la configuration centrale (fenêtres, bundle, sécurité, updater).
/src-tauri/capabilities : les fichiers JSON qui définissent les permissions accordées à chaque fenêtre.

Cette séparation nette entre /src et /src-tauri est précieuse quand une équipe grandit : les développeurs web n’ont pas besoin de toucher au dossier Rust pour la majorité des fonctionnalités, et inversement un développeur Rust peut travailler sur les commandes système sans connaître React en détail.

Étape 6 : configurer tauri.conf.json et les capabilities de sécurité

Depuis Tauri 2, le modèle de sécurité repose sur des capabilities explicites : chaque fenêtre de l’application ne peut appeler que les commandes et plugins pour lesquels elle a reçu une permission. C’est une différence majeure avec Electron, où le processus de rendu a souvent un accès large au système si la configuration n’est pas durcie manuellement.

{
  "productName": "mon-app-tauri",
  "identifier": "com.exemple.monapptauri",
  "build": {
    "frontendDist": "../dist",
    "devUrl": "http://localhost:1420"
  },
  "app": {
    "windows": [
      {
        "title": "Mon App Tauri",
        "width": 1024,
        "height": 720
      }
    ],
    "security": {
      "csp": "default-src 'self'; img-src 'self' data:"
    }
  },
  "bundle": {
    "active": true,
    "targets": "all"
  }
}

Le fichier capabilities/default.json accompagne cette configuration et liste explicitement les permissions accordées, par exemple core:default pour les fonctionnalités de base, ou fs:allow-read-text-file si votre app a besoin de lire des fichiers. Ne jamais accorder une permission par défaut plus large que nécessaire juste pour gagner du temps : c’est exactement le type de raccourci qui transforme une faille mineure en accès système complet.

Étape 7 : écrire vos premières commandes Rust

Les commandes Rust sont le pont entre votre frontend et le système. Elles se déclarent avec la macro #[tauri::command] et doivent être enregistrées explicitement dans le builder Tauri pour devenir appelables depuis le frontend.

// src-tauri/src/lib.rs
#[tauri::command]
fn sauvegarder_note(titre: String, contenu: String) -> Result<String, String> {
    if titre.trim().is_empty() {
        return Err("Le titre ne peut pas être vide".into());
    }
    // logique de sauvegarde réelle ici (fichier, base de données, etc.)
    Ok(format!("Note '{}' sauvegardée ({} caractères)", titre, contenu.len()))
}

#[cfg_attr(mobile, tauri::mobile_entry_point)]
pub fn run() {
    tauri::Builder::default()
        .invoke_handler(tauri::generate_handler![sauvegarder_note])
        .run(tauri::generate_context!())
        .expect("erreur lors du lancement de l'application Tauri");
}

Chaque commande doit être ajoutée à la macro generate_handler!, sans quoi elle reste invisible côté frontend même si le code Rust compile sans erreur. C’est l’oubli le plus fréquent chez les débutants : la commande existe, compile, mais l’appel depuis React échoue avec une erreur « command not found ».

Étape 8 : appeler les commandes Rust depuis React et TypeScript

Côté frontend, le package @tauri-apps/api (en version 2.12.3 actuellement) expose une fonction invoke qui sérialise les arguments, appelle la commande Rust correspondante et retourne une Promise typée.

import { invoke } from "@tauri-apps/api/core";
import { useState } from "react";

function EditeurNote() {
  const [titre, setTitre] = useState("");
  const [contenu, setContenu] = useState("");
  const [message, setMessage] = useState("");

  async function sauvegarder() {
    try {
      const resultat = await invoke<string>("sauvegarder_note", { titre, contenu });
      setMessage(resultat);
    } catch (erreur) {
      setMessage(`Erreur : ${erreur}`);
    }
  }

  return (
    <div>
      <input value={titre} onChange={(e) => setTitre(e.target.value)} placeholder="Titre" />
      <textarea value={contenu} onChange={(e) => setContenu(e.target.value)} />
      <button onClick={sauvegarder}>Sauvegarder</button>
      <p>{message}</p>
    </div>
  );
}

export default EditeurNote;

Notez que les noms de fonctions Rust en snake_case (sauvegarder_note) restent en snake_case côté JavaScript dans l’appel à invoke, Tauri ne fait pas de conversion automatique vers le camelCase. C’est une source d’erreurs silencieuses fréquente si vous renommez une commande d’un seul côté.

Étape 9 : ajouter des plugins officiels à votre application

L’écosystème de plugins Tauri couvre la majorité des besoins courants d’une application desktop : accès au système de fichiers, notifications natives, stockage persistant, presse-papiers, et bien d’autres. Chaque plugin s’installe à la fois côté Rust (Cargo.toml) et côté JavaScript (npm).

Plugin	Usage principal	Installation Rust
plugin-fs	Lecture/écriture de fichiers avec permissions scoped	cargo add tauri-plugin-fs
plugin-notification	Notifications système natives	cargo add tauri-plugin-notification
plugin-store	Stockage clé-valeur persistant type JSON	cargo add tauri-plugin-store
plugin-updater	Mises à jour automatiques en production	cargo add tauri-plugin-updater
plugin-shell	Exécution contrôlée de commandes système	cargo add tauri-plugin-shell

cd src-tauri
cargo add tauri-plugin-notification
cd ..
pnpm add @tauri-apps/plugin-notification

Après l’ajout, chaque plugin doit être enregistré dans lib.rs via .plugin(tauri_plugin_notification::init()) et ses permissions doivent apparaître dans le fichier de capabilities correspondant à la fenêtre qui en a besoin, sinon l’appel échouera silencieusement avec une erreur de permission refusée au runtime.

Gardez à l’esprit que la version du crate Rust d’un plugin et la version du package npm correspondant doivent rester synchronisées. Installer tauri-plugin-notification en version récente côté Cargo tout en gardant une vieille version de @tauri-apps/plugin-notification côté npm provoque des erreurs d’appel difficiles à diagnostiquer, car les deux moitiés du plugin négocient un contrat d’API qui peut changer entre versions majeures. La commande cargo tree côté Rust et pnpm why côté npm aident à repérer rapidement ce genre de désynchronisation avant qu’elle ne provoque un bug en production.

Étape 10 : mettre en place les mises à jour automatiques

Le plugin updater permet à votre application de vérifier, télécharger et installer ses propres mises à jour en production, sans passer par un store tiers. Tauri 2.12 a modifié ce comportement : l’option allowDowngrades, auparavant passée directement à la commande de vérification, est désormais lue depuis la configuration du plugin, ce qui change légèrement la façon d’écrire ce code si vous migrez un projet existant.

import { check } from "@tauri-apps/plugin-updater";
import { relaunch } from "@tauri-apps/plugin-process";

async function verifierMiseAJour() {
  const mise_a_jour = await check();
  if (mise_a_jour) {
    console.log(`Nouvelle version disponible : ${mise_a_jour.version}`);
    await mise_a_jour.downloadAndInstall();
    await relaunch();
  }
}

Pour que l’updater fonctionne en production, vous devez générer une paire de clés de signature avec le CLI Tauri, publier vos builds signés sur un serveur (ou via GitHub Releases) et référencer l’URL du manifeste de version dans tauri.conf.json. Sans signature valide, Tauri refusera d’installer la mise à jour téléchargée, ce qui est une protection volontaire contre les mises à jour corrompues ou malveillantes.

Étape 11 : compiler et empaqueter pour Windows, macOS et Linux

La commande de build génère à la fois l’exécutable optimisé et les installateurs natifs de chaque plateforme : MSI et NSIS sur Windows, DMG et .app sur macOS, AppImage et .deb sur Linux.

pnpm tauri build

# Les artefacts se trouvent dans :
# src-tauri/target/release/bundle/

Un point souvent sous-estimé : Tauri ne fait pas de compilation croisée complète par défaut. Pour obtenir un installateur Windows, vous devez généralement compiler sur une machine Windows (ou une VM/CI Windows), et de même pour macOS. La solution la plus fiable en production reste une pipeline CI avec trois runners séparés (un par OS), par exemple via GitHub Actions avec une matrice windows-latest, macos-latest et ubuntu-latest.

Étape 12 : tester votre application avec tauri-driver

tauri-driver, disponible en version 2.1.0, fournit un pont WebDriver qui permet de piloter votre application Tauri comme on piloterait un navigateur avec Selenium ou WebdriverIO. C’est l’outil à utiliser pour des tests de bout en bout automatisés sur l’interface réelle, plutôt que de se limiter à des tests unitaires Rust ou des tests de composants React isolés.

cargo install tauri-driver --locked

# Lancer le driver avant d'exécuter votre suite WebdriverIO
tauri-driver --port 4444

Mettre en place ces tests dès le début du projet évite de découvrir, juste avant une release, qu’un changement de permission dans les capabilities a cassé silencieusement une fonctionnalité qui dépendait d’un plugin, un scénario bien plus coûteux à corriger une fois le build déjà signé et distribué aux utilisateurs finaux.

Les 5 pièges les plus courants avec Tauri et Rust

Oublier d’enregistrer une commande dans generate_handler! : le code Rust compile sans erreur, mais l’appel frontend échoue avec « command not found », car Tauri ne découvre pas automatiquement les fonctions marquées #[tauri::command].
Accorder des permissions trop larges par facilité : copier-coller une capability « core:default » plus large que nécessaire juste pour faire disparaître une erreur de permission, au lieu d’ajouter la permission précise requise par le plugin utilisé.
Ignorer la MSRV lors d’une mise à jour : mettre à jour les dépendances Cargo sans vérifier la version de Rust installée localement ou en CI, ce qui casse le build dès que Tauri relève sa MSRV, comme avec Rust 1.90 pour la 2.12.
Confondre devUrl et frontendDist : laisser la configuration de développement (serveur local sur le port 1420) active dans un build de production, ce qui produit une application qui tente de charger localhost au lieu des fichiers statiques empaquetés.
Négliger la compilation croisée réelle : croire qu’une seule machine Linux suffit pour produire des installateurs Windows et macOS, alors qu’une pipeline CI multi-OS est nécessaire pour un packaging fiable sur les trois plateformes.

Dépannage : 8 problèmes fréquents et leurs solutions

« error: package requires rustc 1.90 or newer » : exécutez rustup update stable puis rustup default stable, et vérifiez avec rustc --version avant de relancer le build.
Fenêtre blanche au lancement : vérifiez dans tauri.conf.json que frontendDist pointe vers le bon dossier de build (souvent « ../dist ») et que la commande de build frontend a bien été exécutée avant tauri build.
« failed to bundle project: error running linuxdeploy » : installez les paquets manquants (souvent libfuse2 ou patchelf) nécessaires à la génération d’AppImage sur Linux.
invoke() rejette avec « Command not allowed » : la commande ou le plugin appelé n’a pas la permission correspondante dans le fichier capabilities associé à la fenêtre active.
Icônes manquantes dans le build final : régénérez le jeu d’icônes avec pnpm tauri icon chemin/vers/icone.png, qui produit automatiquement toutes les tailles requises par chaque OS.
Temps de compilation très longs en développement : activez le profil de développement rapide de Cargo et évitez de recompiler l’intégralité des dépendances à chaque changement mineur de code Rust.
L’updater ne détecte jamais de nouvelle version : vérifiez que le numéro de version dans tauri.conf.json a bien été incrémenté et que le manifeste de version distant est accessible publiquement avec le bon format JSON.
Erreur de signature lors de l’installation de la mise à jour : régénérez la paire de clés avec le CLI Tauri et vérifiez que la clé publique utilisée côté client correspond exactement à la clé privée utilisée pour signer le build publié.

Conseils avancés : sécurité, taille et performance

Une fois le projet de base fonctionnel, plusieurs réglages permettent d’aller plus loin. Activez systématiquement la Content Security Policy dans tauri.conf.json plutôt que de la laisser vide, même pour une application interne, car la CSP reste la première ligne de défense contre l’injection de code dans la webview. Segmentez vos capabilities par fenêtre plutôt que d’appliquer un seul fichier de permissions global : une fenêtre de configuration n’a pas besoin des mêmes accès qu’une fenêtre principale qui manipule des fichiers utilisateur.

Côté taille de build, activez le profil release avec optimisation de taille (opt-level = "z" et lto = true dans Cargo.toml) si votre priorité est un installateur minimal plutôt qu’un temps de compilation court. Pour la performance au runtime, préférez des commandes Rust asynchrones (async fn avec le runtime Tokio) dès qu’une opération implique de l’IO, afin de ne pas bloquer le thread principal de l’application et de garder une interface réactive même pendant des opérations longues comme la lecture d’un gros fichier.

Enfin, surveillez les notes de version officielles à chaque mise à jour mineure de Tauri. Le changement du comportement d’allowDowngrades entre versions 2.12 illustre bien que des ruptures de compatibilité peuvent survenir même sur des versions mineures, en particulier sur les plugins liés aux mises à jour et à la sécurité, comme le montre le changelog complet du crate tauri-runtime.

Checklist de publication : ce qu’il faut vérifier avant de livrer

Avant de pousser un build Tauri en production, mieux vaut passer par une liste de vérification fixe plutôt que de se fier à la mémoire, surtout quand plusieurs personnes publient des versions à tour de rôle. Voici les points qui reviennent le plus souvent dans les retours d’expérience d’équipes ayant migré vers Tauri 2.

Le numéro de version dans tauri.conf.json a été incrémenté, et correspond au tag Git de la release.
Le fichier capabilities a été relu en entier : aucune permission « core:default » large n’a été laissée par commodité pendant le développement.
La CSP (Content Security Policy) est définie et ne contient pas de wildcard non justifié comme « default-src * ».
Les trois builds (Windows, macOS, Linux) ont été produits par la pipeline CI, pas seulement sur la machine du développeur qui publie.
La signature de code (certificat Windows, notarisation Apple) est valide et n’expire pas dans les semaines qui suivent la release.
Le manifeste de l’updater pointe vers l’URL finale de distribution, pas vers un environnement de test ou de staging.
Les logs Rust en mode debug (println!, dbg!) ont été retirés ou passés derrière un flag, pour ne pas polluer la console en production.

Cette checklist prend cinq minutes à parcourir, mais elle évite l’essentiel des incidents de publication observés sur des projets Tauri en production, qui viennent presque toujours d’un oubli de configuration plutôt que d’un bug dans le framework lui-même.

Projet complet : une application de prise de notes multiplateforme

Pour consolider l’ensemble des étapes précédentes, voici l’architecture complète d’une petite application de prise de notes, suffisante pour servir de base à un vrai projet. Elle combine tout ce qui a été vu : commandes Rust, plugin de stockage, notifications et updater.

Frontend React/TypeScript avec une liste de notes et un éditeur, appelant trois commandes Rust : lister_notes, sauvegarder_note, supprimer_note.
Backend Rust utilisant tauri-plugin-store pour persister les notes en JSON dans le dossier de données de l’application, sans base de données externe à gérer.
tauri-plugin-notification pour confirmer visuellement chaque sauvegarde réussie avec une notification système native.
tauri-plugin-updater configuré avec un manifeste hébergé sur GitHub Releases, vérifié automatiquement au démarrage de l’application.
Capabilities restreintes à une seule fenêtre principale, avec uniquement les permissions store et notification accordées, rien d’autre.
Pipeline GitHub Actions avec une matrice à trois OS pour produire les trois installateurs à chaque tag de version.

Ce socle couvre la quasi-totalité des besoins d’une application desktop interne ou d’un petit produit grand public : stockage local, retour utilisateur natif, et cycle de mise à jour autonome sans dépendre d’un store tiers. À partir de là, ajouter des fonctionnalités supplémentaires revient surtout à écrire de nouvelles commandes Rust ciblées et à leur attribuer les permissions correspondantes, sans toucher au reste de l’architecture.

Pour faire évoluer ce projet vers un outil plus ambitieux, les pistes naturelles sont une recherche plein texte sur les notes avec une petite bibliothèque Rust d’indexation, une synchronisation chiffrée entre appareils via un serveur léger, ou encore un mode hors-ligne avec file d’attente de synchronisation différée. Dans tous les cas, la même règle s’applique : chaque nouvelle capacité système passe par une commande Rust dédiée et une permission explicite, jamais par un accès large accordé une fois pour toutes.

FAQ : les questions les plus posées sur Tauri et Rust

Faut-il bien connaître Rust pour utiliser Tauri ?
Non. La majorité de l’interface se construit en React, Vue ou JavaScript classique. Rust n’intervient que pour les commandes système, souvent quelques dizaines de lignes au total même sur une application de taille moyenne.

Quelle version de Rust dois-je installer pour Tauri 2.12 ?
Rust 1.90 minimum, puisque c’est la MSRV imposée par cette version de Tauri. Une version plus ancienne provoquera une erreur de compilation explicite dès le premier build.

Tauri fonctionne-t-il sur mobile, pas seulement sur desktop ?
Oui, Tauri 2 inclut un support Android et iOS, avec le même modèle de commandes Rust et la même base de code frontend que la version desktop, moyennant quelques ajustements de configuration propres au mobile.

Peut-on migrer une application Electron existante vers Tauri ?
La couche frontend (React, Vue, etc.) se réutilise en grande partie. La partie qui demande le plus de travail est la réécriture des appels Node.js (fs, child_process, IPC) en commandes Rust équivalentes et la définition des capabilities de sécurité.

Comment signer une application Tauri pour la distribution ?
Windows nécessite un certificat de signature de code, macOS nécessite un compte développeur Apple pour la notarisation, et les mises à jour automatiques nécessitent en plus une paire de clés de signature générée par le CLI Tauri, indépendante de la signature de code de l’OS.

Pourquoi mon installateur Tauri est-il si petit comparé à Electron ?
Parce que Tauri réutilise le moteur de rendu déjà présent sur le système (WebView2, WebKit) au lieu d’embarquer son propre Chromium complet dans chaque application, ce qui élimine l’essentiel du poids habituel d’un installateur Electron.

Tauri est-il adapté à des applications d’entreprise critiques ?
Le modèle de permissions granulaire par capabilities et l’absence d’un Node.js exposé côté frontend en font un choix pertinent pour des applications internes manipulant des données sensibles, à condition de configurer les capabilities de façon stricte dès le départ.

Où suivre les prochaines mises à jour de Tauri ?
Le blog officiel et la page de releases GitHub de l’organisation tauri-apps restent les sources les plus fiables, en particulier pour repérer les changements de MSRV ou de comportement des plugins avant de mettre à jour un projet en production.

Quelle est la différence entre le CLI Tauri et le crate tauri lui-même ?
Le crate tauri (en version 2.12.3) est la bibliothèque Rust qui compose le runtime de l’application, tandis que le CLI (en version 2.12.2) est l’outil en ligne de commande utilisé pour lancer le mode développement, générer les icônes et produire les bundles finaux. Les deux évoluent en parallèle mais restent versionnés séparément.

Tauri 2.12 et Rust 1.90 : App Desktop en 12 Étapes [2026]