VirtualScreen : découper un écran ultra-large en vrais écrans sous Windows

Le problème : un grand écran reste un seul écran

Écrans ultra-larges, grands téléviseurs, portables branchés sur un moniteur : tous offrent plus de place qu'une application n'en demande. Pourtant, pour Windows, un écran reste un écran. Le plein écran d'un logiciel, d'une vidéo ou d'un jeu prend toute la surface.

Le besoin tient en une phrase, écrite dès la première spec : n'importe quelle application doit se comporter dans une zone exactement comme sur un écran séparé. Un logiciel de travail agrandi, une vidéo en plein écran, un jeu en plein écran exclusif.

Les solutions existantes ne couvrent pas ce cas pour tout le monde. Les fonctions de Windows qui s'en approchent sont réservées aux éditions Enterprise et Pro for Workstations. L'outil équivalent de NVIDIA n'est pas disponible sur les cartes GeForce.

VirtualScreen vise donc tout écran, de bureau ou de salon, seul ou à plusieurs.

Le cadrage : quatre chantiers avant la première ligne de code

Avant la première ligne de code, le produit a été découpé en quatre chantiers. Chacun a sa spec, son plan et sa recette :

1. le moteur, qui crée les écrans et recopie l'image ;
2. la configuration : réglages, surfaces flottantes, premier lancement ;
3. la compatibilité : vidéos protégées, cartes NVIDIA et HDR, plusieurs écrans ;
4. la publication : installateur, mises à jour, diffusion.

Le moteur avait un périmètre volontairement étroit : des colonnes de largeur libre, une découpe par défaut 60/40, un raccourci clavier et un gardien contre l'écran noir. L'interface, le HDR, les autres cartes graphiques et l'installateur étaient explicitement hors périmètre.

Trois décisions ont tenu tout le projet :

• Une machine de référence d'abord. Le moteur est validé sur une seule configuration, un écran 3440 × 1440 à 170 Hz. La compatibilité attend son chantier.
• Dire les limites dès la spec. Une image de latence, toutes les zones à la fréquence de l'écran physique, une à deux secondes de noir à chaque bascule : listées et assumées avant de coder.
• Gratuit d'abord. La publication se limite à ce qui ne coûte rien. Licences et paiement viendront plus tard.

Les critères de réussite étaient mesurables : une image de latence ajoutée au plus, aucune saccade visible, jamais plus de cinq secondes d'écran noir.

Direction artistique et maquettes Figma

Tout a été dessiné dans Figma avant d'être codé, en thème clair et en thème sombre. La direction artistique tient en quelques règles :

• un fond d'application neutre, la couleur réservée aux cartes ;
• un dégradé par zone (Aurore, Lagon, Améthyste, Néon…) pour reconnaître chaque écran d'un coup d'œil ;
• des étiquettes en verre posées sur les zones ;
• une seule police, Inter, et une courbe d'animation commune ;
• le respect du réglage « réduire les animations ».

Les variables de Figma sont exportées automatiquement en jetons CSS. L'interface codée reprend donc exactement les couleurs, espacements et rayons des maquettes.

Les écrans clés : les réglages (découpe, général, à propos), le menu de l'icône, le premier lancement en quatre étapes, l'éditeur plein écran et l'installateur.

Une animation a demandé plus de travail que les autres : la bascule. Windows met une à trois secondes à changer d'affichage, et l'écran passe au noir. L'animation masque ce moment : le logo devient l'écran, puis se fend en zones. Plusieurs versions ont été comparées dans Figma. La fente se joue avant le changement d'affichage : jouée après, elle tombait dans le noir.

Architecture : un pilote IddCx, du C++20 et WebView2

VirtualScreen repose sur quatre briques :

• un pilote d'écran virtuel (UMDF, IddCx), dérivé d'un projet open source sous licence MIT. Il crée les écrans virtuels à la fréquence exacte de l'écran physique ;
• l'application, en C++20, qui pilote la découpe et recopie chaque zone sur l'écran réel ;
• un gardien, un processus séparé qui restaure l'affichage si l'application ne répond plus ;
• l'interface, en React et TypeScript, affichée dans WebView2.

L'application et le pilote échangent des messages simples : ajouter un écran, le retirer, et un signal de vie toutes les 1,5 seconde. L'interface parle à l'application par un pont JSON versionné.

Pourquoi ces choix :

• Un cœur testable. La logique ne dépend d'aucune API graphique de Windows : elle se teste entièrement avec des doublures.
• La capture plutôt que le partage d'images. La spec prévoyait de partager les images entre le pilote et l'application. Une sonde a montré un risque d'échec. La capture native de Windows l'a remplacé : 170 images par seconde sans perte, moins d'une milliseconde de copie par zone.
• Une règle d'or contre l'écran noir. Trois filets successifs : le gardien en trois secondes, puis le pilote seul en cinq, puis la restauration au démarrage.
• WebView2 pour l'interface. Il réutilise React et les jetons issus de Figma, dans une fenêtre verrouillée, sans navigation externe.

Travailler avec Claude Code : spec, plan, code, recette

Le code a été écrit par Claude Code, sous ma direction. La méthode est la même pour chaque chantier : une spec, un plan, l'implémentation, puis une recette.

Au total : 11 specs, 16 plans et 5 recherches avec des sondes, ces petits programmes qui vérifient une hypothèse avant de construire dessus.

Les recettes se faisaient avec des fiches d'essai, une tâche à la fois. Je testais sur le vrai écran, je renvoyais « validé » ou « à corriger », et les correctifs arrivaient au fil des retours.

Quelques chiffres :

• 496 commits du 7 au 13 octobre 2026 ;
• 3 345 tests automatisés avant la version 1.0 (1 883 pour le moteur, 1 462 pour l'interface) ;
• une compilation qui refuse le moindre avertissement.

Le partage des rôles est resté net. Les décisions de produit et de design étaient les miennes : le rythme des animations, la découpe de plusieurs écrans à la fois, l'installateur sur mesure, la publication directe de la 1.0. La validation des maquettes et des recettes aussi. Claude Code produisait les specs, les plans, le code, les tests et les analyses de causes.

Même la publication garde une étape humaine : l'intégration continue ne prépare qu'un brouillon. La version n'est publiée qu'après une vérification en machine virtuelle.

Les décisions difficiles

Les vidéos protégées restaient noires. Windows noircit le contenu protégé dans toute copie de l'image : impossible de le recopier dans une zone. La solution ne copie rien. La fenêtre du lecteur est posée directement sur l'écran physique, et la couche de recopie est percée à cet endroit. La version 1.0.1 a ensuite corrigé des logiciels pris à tort pour des vidéos.

Un clic mettait la vidéo en pause. Dans le navigateur, en plein écran, un clic ne faisait que mettre en pause. La cause a été trouvée en lisant le code de Chromium : la fenêtre se repositionnait sur tout l'écran entre l'appui et le relâchement. Le correctif rejoue l'appui au bon endroit.

Le bureau sécurisé. Les écrans de verrouillage et de contrôle de compte ne peuvent pas être recopiés. Plutôt que de forcer, la découpe se suspend pendant ces écrans et revient seule.

Les droits administrateur. Les fenêtres lancées en administrateur échappaient à l'application. Deux pistes : un manifeste spécial, ou une tâche planifiée avec les droits élevés. Le choix s'est porté sur la tâche planifiée, sans demande d'autorisation à chaque lancement.

Les réglages NVIDIA. Certains réglages de la carte (RTX HDR, Vibrance, limiteurs d'images) s'appliquaient à la couche de recopie, que le pilote prenait pour un jeu. La solution : un profil dédié à VirtualScreen seul. Le profil global de l'utilisateur n'est jamais modifié.

Résultat et suite

La version 1.0.0 est sortie le 9 octobre 2026, suivie des versions 1.0.1 et 1.0.2 le 13. L'installateur est gratuit, à télécharger sur GitHub, en français et en anglais, pour Windows 11.

Les mises à jour sont proposées, jamais imposées. Elles sont signées et vérifiées, et l'application revient seule à la version précédente si la nouvelle ne démarre pas dans la minute.

Les limites sont écrites noir sur blanc :

• l'installateur n'est pas encore signé par une autorité reconnue, d'où l'avertissement de Windows au premier lancement ;
• pas de fréquence variable (G-Sync, VRR) dans les zones ;
• environ une image de latence en plus pendant la lecture d'une vidéo protégée.

La suite est déjà écrite : la signature du code, les licences et un mode dédié aux éditions professionnelles de Windows.