La réalité multi-plateforme
Aujourd'hui presque chaque PME a une flotte d'appareils mixte :
- Windows constitue le plus souvent la majorité (postes standard, quelques serveurs)
- macOS au marketing, au design, en ingénierie, parfois à la direction
- Linux sur les CI builders, les NAS, quelques serveurs et des appareils 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 + audio système dans le même flux (audio système pas en mode service)
- Secure Enclave pour lier la connexion de l'hôte
- 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 : non pris en charge par les versions actuelles de WinDesk ; il faut Apple Silicon (M1 ou plus récent).
- 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.
Raspberry Pi 4/5
Ce qui marche :
- arm64 .deb pour Pi OS Bookworm 64-bit
- Setups pour makers, IoT, labos d'enseignement (session graphique requise sous Linux)
Ce qui coince :
- Pi 4 avec 1 Go RAM est trop petit → minimum 2 Go recommandé
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, somme SHA-256 |
| Fedora/RHEL x64 | ✅ Production | .rpm, somme SHA-256 |
| Raspberry Pi 4/5 (arm64) | ✅ Production | .deb arm64 |
| Mac Intel (x64) | Non pris en charge | Aucun paquet de version actuel |
Cohérence multi-plateforme : même UX, mêmes audit logs, un compte.
Recommandation pratique
Si tu as 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).