# Comment j’ai construit Mole for Windows sur un Mac

Depuis la sortie de Mole for Mac, on me demandait régulièrement quand viendrait une version Windows, et je répondais chaque fois qu’il faudrait d’abord que l’app Mac soit bien en place. Mole for Windows est enfin sorti le 14 octobre. Avant cela, il est passé par plus de 20 versions auprès d’un petit groupe d’utilisateurs, puis par plusieurs jours de tests avec les premiers soutiens de Mole, qui ont envoyé énormément de suggestions. Merci à tous. Ce développement s’est révélé très amusant, alors voici comment j’ai construit une app Windows sur un Mac.

<figure class="blog-diagram">
  <img src="/img/windows/clean.webp" width="2584" height="1741" loading="lazy" alt="La page Nettoyer de Mole for Windows, avec la navigation entre les cinq pages en haut et la Terre au centre">
</figure>

## Repartir presque de zéro

Pour une meilleure expérience et de meilleures performances, cette version est écrite en C# avec WinUI 3, native sur Windows, sans passer par Electron. Windows et macOS diffèrent aussi dans leur fonctionnement et dans ce qu’il y a à nettoyer : en dehors du design et des textes, presque rien des plus de 100 000 lignes de Swift de l’app Mac n’a pu être réutilisé. Il a fallu environ un mois d’allers-retours, pour près de 78 000 lignes de code et plus de 4 000 tests.

## Un Mac, une machine virtuelle, un ThinkPad

Développer et déboguer a été bien plus difficile que sur le Mac que je connais, et une interface WinUI ne se compile pas sur Mac. J’ai donc gardé le code et tout le contexte de l’IA sur un seul Mac. Parallels Desktop y fait tourner une machine virtuelle Windows pour le débogage, et un ThinkPad X1 reste allumé jour et nuit pour montrer ce qu’une machine virtuelle ne montre pas. Voici mon bureau aujourd’hui : le Mac au milieu, le ThinkPad X1 à gauche, et Mole ouvert sur chaque écran.

<figure class="blog-diagram">
  <img src="/img/windows/workspace.webp" width="1600" height="1200" loading="lazy" alt="Le bureau de l’auteur : un Mac et un écran externe au centre, un ThinkPad X1 à gauche, Mole ouvert sur chaque écran">
</figure>

## Ce qui a bien fonctionné

Quelques habitudes prises pendant ce mois à développer un logiciel Windows sur Mac, au cas où vous auriez besoin de faire de même :

- Découper le code en couches. La logique centrale, comme le nettoyage et la désinstallation, ainsi que l’état de l’interface, vivent dans des projets .NET qui ne dépendent pas de Windows. La couche qui appelle les API du système active `EnableWindowsTargeting`, si bien qu’elle se compile aussi sur Mac. La plupart des plus de 4 000 tests tournent sur Mac, et seule la couche WinUI doit être compilée sous Windows.
- Monter le dépôt dans la machine virtuelle comme dossier partagé Parallels. On modifie sur le Mac, puis on compile et on lance tout de suite dans la VM, sans rien copier. Gardez la sortie de compilation de chaque côté dans son propre dossier, sinon les chemins absolus enregistrés dans `obj` s’écrasent mutuellement.
- Piloter la machine virtuelle par des scripts. `prlctl exec` y lance des commandes, et les boutons sont cliqués et les fenêtres capturées par leur nom d’accessibilité via UI Automation : l’IA vise le bon contrôle sans coordonnées, même quand la mise en page bouge un peu.
- Joindre le ThinkPad par UU Remote et ssh. Le vrai matériel x64, la mise à l’échelle en haute résolution, la batterie, SmartScreen et Defender se vérifient là, et chaque version y est installée et parcourue avant sa sortie.
- Là où aucune ligne de commande n’arrive, je fais appeler le computer use de Codex par Claude via lcu. Franchement, le computer use de Codex est très bon, mais il ne sait pas cliquer sur une invite UAC, alors cette partie me revient encore.

La plupart du temps, 7 à 10 onglets d’agents tournent en même temps dans Kaku.

## Les certificats de développeur Windows, quelle galère

Sous Windows, un installeur non signé est arrêté dès l’ouverture par « Windows a protégé votre ordinateur », et le Contrôle intelligent des applications de Windows 11 refuse carrément de l’exécuter. Avant de publier, j’ai donc dû acheter un certificat de signature de code. En me renseignant, j’ai découvert qu’un certificat EV n’apporte plus aucun avantage pour SmartScreen : un programme nouvellement signé reste « non reconnu » tant que peu de gens l’ont installé. Azure Artifact Signing, le service de Microsoft à moins de 10 dollars par mois, aurait été le plus simple, mais il n’est ouvert aux particuliers qu’aux États-Unis et au Canada, donc pas pour moi, et le certificat open source bon marché de Certum interdit l’usage commercial.

J’ai finalement acheté le certificat OV dans le cloud de Certum, pour cent à deux cents dollars par an. La clé est conservée dans son HSM en ligne, chaque signature demande un code à usage unique de l’app SimplySign sur mon téléphone, et le nom sur le certificat est le nom légal vérifié, celui sous lequel la réputation SmartScreen s’accumule. À l’usage, la session SimplySign s’est coupée plusieurs fois après quelques heures d’inactivité et la signature a échoué en plein empaquetage, alors je signe maintenant un fichier de test avant chaque build.

## Tester les apps a pris le plus de temps

Le pire pour un outil de nettoyage, c’est de supprimer ce qu’il ne fallait pas, et sous Windows chaque installeur et chaque désinstalleur a ses habitudes : il n’y a pas d’autre moyen que de les installer un par un. J’ai dressé une liste d’apps que les ingénieurs utilisent couramment, en Chine comme ailleurs : éditeurs, IDE, navigateurs, messageries, stockage en ligne, bases de données et outils d’IA. Chacune est installée et ouverte, puis je vérifie si la désinstallation, les mises à jour, le nettoyage des restes et la liste de démarrage de Mole la reconnaissent. À ce jour, 372 apps ont été testées, et 72 ont révélé un problème, chaque fois corrigé dans la même série, couvert par un test puis retesté. Certains problèmes venaient de ma propre configuration : lors de son premier test, VS Code s’est vu attribuer un raccourci du même nom que Parallels avait créé pour la copie Mac de VS Code, qui a bien failli être supprimé par erreur.

<figure class="blog-diagram">
  <img src="/img/windows/uninstall.webp" width="2584" height="1741" loading="lazy" alt="La page Apps de Mole for Windows, avec les apps installées et leur taille">
</figure>

Les fonctions correspondent pour l’essentiel à celles de l’app Mac : les cinq pages Nettoyer, Apps (désinstallation et mises à jour), Optimiser, Analyser et État, plus le panneau de la zone de notification, Écran allumé et Nettoyer l’écran. Elle prend en charge Windows 10 22H2 et Windows 11, avec des installeurs natifs pour x64 et ARM64.

## Il existe aussi une version en ligne de commande

En plus de l’app de bureau, la version Windows de la CLI Mole a commencé au début de l’année. La première demande est venue d’un développeur en Inde, qui m’a aussi envoyé une PR au passage, merci à lui. En neuf mois et demi, elle a connu neuf versions, et je l’ai beaucoup fait évoluer ce dernier mois, si bien que ses commandes et son confort d’usage rejoignent désormais ceux de la CLI Mac. Elle est gratuite et open source : si vous aimez la ligne de commande, vous pouvez l’utiliser directement depuis [GitHub](https://github.com/tw93/Mole/tree/windows). [Cet article](/fr/windows/blog/mole-cli-vs-windows-app) explique en quoi elle diffère de l’app de bureau.

<figure class="blog-diagram">
  <img src="/img/windows/cli-menu.webp" width="1814" height="741" loading="lazy" alt="Le menu principal de Mole CLI for Windows dans PowerShell, avec Nettoyer, Désinstaller, Optimiser, Analyser et État">
</figure>

Le téléchargement et le prix de l’app de bureau se trouvent sur [mole.fit/windows](/windows), et chaque fonction peut être utilisée deux fois gratuitement avant de décider. Si vous avez un PC Windows, essayez-la.


Canonical: https://mole.fit/fr/windows/blog/building-mole-for-windows-on-a-mac
