Tester des centaines d’apps Mac pour Mole

Pour améliorer la désinstallation et la recherche de fichiers résiduels dans Mole, je répète une tâche assez monotone. J’ai rassemblé plus de 300 applications Mac, chinoises et internationales, soit plus de 100 Go de téléchargements. Par groupes de dix, 30 groupes au départ, j’ai fait utiliser l’ordinateur par une IA pour télécharger les applications sur leurs sites officiels et les installer sur mon Mac. Puis viennent les dossiers, les bundles de mise à jour, les éléments au démarrage, la désinstallation et la recherche de fichiers restants pour compléter les règles.

De 100 à 300, puis 549

Je comptais commencer et finir avec 100 applications courantes. Puis je me suis dit : encore cent. Et encore cent. La collection a ensuite atteint 549 applications, avec des versions App Store et des extensions. Moi qui essaie habituellement de limiter mon Mac à une trentaine d’applications, voici à quoi ressemblait mon bureau pendant les tests.

Les installations réservent des interruptions : autorisations, écrans d’achat, mot de passe administrateur. L’agent se débrouille pour l’essentiel, et je l’aide pour le reste. Il m’a même surpris en écrivant des scripts d’installation, de désinstallation et de vérification des résidus pour faciliter son propre travail. Par moments, c’était moi l’assistant.

L’installation n’est que le début

Ce qui prend du temps, c’est de suivre une application du premier lancement à sa suppression, en passant par les autorisations, les mises à jour et le démarrage automatique. L’installateur ne montre pas les dossiers créés lors de l’utilisation. Supprimer le bundle ne dit pas non plus ce que deviennent les fichiers déposés ailleurs.

Pour chaque groupe, je cherche qui a créé le dossier, à quelle application appartient le helper de mise à jour et ce qui reste au démarrage après la suppression. Il faut connaître le chemin réel et son propriétaire avant d’en faire une règle. Un nom ressemblant ne suffit pas. Les versions App Store et celles téléchargées directement sont vérifiées séparément : un même nom ne garantit pas les mêmes emplacements.

L’IA peut répéter les vérifications et écrire des scripts pour les étapes comprises, mais les permissions, les mots de passe administrateur et les fichiers d’origine incertaine demandent encore une intervention. Tout faire à la main m’aurait pris, à mon avis, dix fois plus de temps.

Ce qu’il faut installer pour comprendre

Je pensais qu’après 100 applications, les conventions du génie logiciel permettraient de prévoir le reste. En pratique, beaucoup de chemins échappent aux règles générales. Certains identifiants de bundle ne suivent même pas la notation de domaine inversé. Une convention apparemment rigoureuse peut cacher une valeur saisie un jour sans grande réflexion. Il faut installer et examiner chaque application.

Ces vérifications m’ont aussi fait corriger des suppressions envisagées à tort. Un cache, les fichiers d’une personne et les données partagées entre applications ne deviennent pas tous des déchets parce qu’ils se trouvent dans le même dossier. Tester davantage, c’est aussi trouver davantage de choses à conserver.

Trouver aussi ce qui doit rester

La première série de plus de 300 applications a permis d’ajouter 13 catégories de règles réutilisables et plus de 90 chemins précis. J’ai aussi corrigé plus de 30 endroits où je pensais devoir nettoyer alors qu’il ne fallait rien toucher, complété les contrôles des mises à jour et du démarrage, et ajouté plus de 100 tests unitaires. Ce sont les chiffres de cette série, pas un total figé pour la liste actuelle.

Ces corrections comptent autant que les nouveaux résidus trouvés. Un cache peut être recréé ; un fichier écrit par une personne ne le peut pas. Des données partagées ne doivent pas disparaître parce qu’une seule application est supprimée. Un fichier apparemment abandonné peut encore servir ailleurs : si son appartenance est incertaine, mieux vaut le conserver.

Chercher uniquement à augmenter la quantité nettoyée ferait perdre de vue le travail de vérification. Les règles générales couvrent les cas répétitifs, les chemins particuliers sont confirmés individuellement, et les tests conservent les cas à ne pas supprimer pour éviter de réintroduire les erreurs lors des changements suivants.

Un retour inattendu de l’accessibilité

Dès ses premières versions, Mole a ajouté des attributs d’accessibilité pour les personnes ayant une déficience visuelle. Ils ont aussi aidé l’IA à repérer les bons éléments et boutons pendant ces tests. Un travail destiné aux utilisateurs m’a donc aidé à mon tour.

Les attributs d’accessibilité peuvent donner le nom d’un bouton, son type et son état, pas seulement sa position. Un script dispose ainsi de repères quand la disposition change. Avec une image et des coordonnées fixes, déplacer une fenêtre ou changer une boîte de dialogue peut suffire à provoquer un mauvais clic.

Cela reste d’abord un travail pour les personnes. Qu’une IA trouve un bouton ne prouve pas qu’une personne utilisant VoiceOver puisse terminer l’action. Les libellés, l’ordre du focus et l’annonce des résultats restent à vérifier. Cette expérience m’a fait mieux apprécier la prise en charge de différentes façons d’utiliser un ordinateur.

Je pensais qu’après cent applications, il ne resterait que des répétitions. À 300, puis à 549, de nouveaux détails apparaissaient encore. Je veux continuer à installer et examiner les applications courantes, puis intégrer ce que j’apprends dans Mole. Ces vérifications ordinaires peuvent compter au moment où quelqu’un désinstalle réellement une application.

Si vous créez des applications ou des sites, votre assistant de programmation peut vous aider à améliorer leur accessibilité. Cela peut faciliter leur utilisation par des personnes ayant une déficience visuelle et rendre vos tests automatisés plus fiables. Je poursuivrai ces vérifications. Les applications figurent dans la liste des logiciels testés, et vous pouvez en proposer d’autres.