La réalité multi-plateforme
Aujourd’hui presque chaque PME a une flotte d’appareils mixte :
- 80 % Windows (postes standard, quelques serveurs)
- 15 % macOS (marketing, design, ingénierie, parfois la direction)
- 5 % Linux (CI builders, NAS, quelques serveurs, devices Pi IoT)
Un outil doit tout couvrir — et pas « Windows est la plateforme principale et Mac est en bêta ». Cela passait peut-être jusqu’en 2020 ; plus aujourd’hui.
Ce qui doit fonctionner sur chaque plateforme
- Transmission d’écran à ≥30 FPS sur connexions modernes
- Souris + clavier dans les deux sens
- Détection multi-écran
- Transfert de fichiers
- AES-256 bout-en-bout
- Jetons d’appareil liés au matériel
Pièges spécifiques par plateforme
Windows
Ce qui marche : tout. Windows est la plateforme principale depuis 30 ans.
Ce qui coince :
- Prompts UAC à l’hôte : la connexion doit-elle « ouvrir quand même » ? Sur Windows 11 rare, sur les anciens fréquent.
- TPM 1.2 vs 2.0 : appareils anciens (avant 2018) ont souvent seulement TPM 1.2 — liaison de jeton plus limitée.
macOS Apple Silicon
Ce qui marche :
- ScreenCaptureKit (au lieu du Legacy CoreGraphics) : capture image accélérée matériellement + audio système dans le même flux
- Secure Enclave pour la liaison du jeton : résistant au vol
- Notarisation : pas de drame Gatekeeper au premier démarrage
Ce qui coince :
- Assistant de permissions au premier connect : l’utilisateur doit basculer 2 toggles dans Réglages Système (Enregistrement d’écran + Accessibilité). Les outils avec auto-ouverture des réglages + reprise transparente après changement de permission rendent cela indolore.
- Macs Intel (avant 2020) : build osx-x64 souvent pas officiel, à compiler manuellement.
- Mises à jour Sequoia : l’API ScreenCaptureKit a changé 2-3 fois depuis introduction. Les outils non maintenus activement cassent.
Linux
Ce qui marche :
- Paquets .deb / .rpm, script postinst pour la règle udev /dev/uinput
- TPM 2.0 + tpm2-tools pour la liaison de jeton (sur matériel moderne)
- Wayland et X11 comme serveurs d’affichage équivalents
Ce qui coince :
- Capture d’écran Wayland : nécessite xdg-portal avec
org.freedesktop.portal.ScreenCast. Les distros anciennes (avant Ubuntu 22.04) souvent buggy. - Permissions /dev/uinput : le postinst doit configurer proprement la règle udev + le groupe. Les mauvais outils nécessitent sudo à l’exécution.
- Disponibilité TPM : pas chaque box Linux a un TPM. Pi 4/5 n’en a pas → repli libsecret-keyring.
Raspberry Pi 4/5
Ce qui marche :
- arm64 .deb pour Pi OS Bookworm 64-bit
- Stockage du jeton libsecret (pas de TPM, mais équivalent GNOME-Keyring)
- Setups headless pour makers, IoT, labos d’enseignement
Ce qui coince :
- Pi 4 avec 1 Go RAM est trop petit → minimum 2 Go recommandé
- Sur distros maker (DietPi, custom Buildroot) : libsecret souvent absent, le stockage du jeton doit être configuré manuellement
Comment WinDesk se positionne
En 0.5.0 (mai 2026), les quatre plateformes sont production :
| Plateforme | Statut | Build |
|---|---|---|
| Windows 10/11 x64 | ✅ Plateforme principale | Setup NSIS signé EV |
| macOS Apple Silicon (arm64) | ✅ Notarisé | Apple Developer ID + notarisation |
| Ubuntu/Debian x64 | ✅ Production | .deb (signé) |
| Fedora/RHEL x64 | ✅ Production | .rpm (signé) |
| Raspberry Pi 4/5 (arm64) | ✅ Production | .deb arm64 |
| Mac Intel (x64) | 🔧 Sur demande | Build osx-x64 sur demande |
Cohérence multi-plateforme : même UX, mêmes audit logs, un compte.
Recommandation pratique
Si vous avez une flotte mixte :
- Tester avec le plan Free sur chaque plateforme. 2 heures suffisent pour vérifier que la capture image + entrée fonctionnent.
- Documenter les setups spéciaux. Pi headless ? Centraliser comment c’est configuré.
- Plan Pro dès que l’unattended devient pertinent. Free suffit pour l’aide spontanée, Pro pour la maintenance régulière.
- Tester chaque build avant déploiement. Surtout les mises à jour Mac (Apple aime changer l’API ScreenCaptureKit).