DockEcho : quand ton dock mac refuse de suivre sur le deuxième écran
J’ai un client à Lyon, avocat, deux écrans 27 pouces en plus du MacBook. Il m’appelle la semaine dernière, excédé : « Marc, mon dock mac reste sur l’écran principal, je dois traverser tout le bureau à la souris pour lancer Word ». Je connais cette plainte par cœur. Depuis quinze ans que je dépanne des Macs, c’est un des trucs qui revient le plus souvent quand on branche un deuxième moniteur. Et Apple, dans sa grande mansuétude, n’a jamais jugé bon de régler ça. Le dock reste là où il a décidé de rester, point barre.
Autant dire que quand j’ai vu passer DockEcho sur le blog de Korben, j’ai tendu l’oreille. Une copie synchronisée du dock mac sur chaque écran externe, avec tes réglages, open source, licence MIT. Sur le papier, c’est exactement le genre d’outil que je cherche depuis des années pour mes clients multi-écrans. Sauf qu’il y a un détail qui fâche, et j’y reviens plus bas.
Le problème que tout le monde connaît et que personne ne résout
macOS gère le multi-écrans comme un chef de chantier fatigué. Le dock apparaît sur un seul écran, celui que le système a désigné comme « principal ». Tu peux le déplacer en bas, à gauche, à droite, le réduire, l’agrandir. Mais le dupliquer ? Non. Jamais. Ça fait plus de dix ans que les utilisateurs réclament cette fonctionnalité sur les forums Apple, et la réponse reste invariablement la même : « ce n’est pas prévu ».
J’ai vu des clients acheter des utilitaires payants à 15 balles par an juste pour ça. J’en ai vu d’autres se résigner, déplacer le dock à la main entre deux écrans, ou pire, utiliser le Launchpad à la place. Franchement, en 2025, on devrait avoir dépassé ce stade. Windows, malgré tous ses défauts, gère la barre des tâches sur plusieurs écrans depuis Windows 10. Évidemment, Microsoft a fini par casser un truc avec une MAJ, mais au moins l’intention était là.
DockEcho arrive donc dans un vide logiciel béant. Le principe est simple : tu lances l’app, elle détecte tes écrans, et elle pose une réplique du dock sur chacun d’eux. Synchronisée avec l’original. Tu ajoutes une app au dock principal, elle apparaît partout. Tu changes l’ordre, pareil. Mine de rien, c’est ce qu’Apple aurait dû faire depuis Catalina.
DockEcho sur chaque écran : ce que ça donne vraiment à l’usage
Je ne suis pas certain à 100% du comportement sur les configurations à trois écrans ou plus, parce que je n’ai testé que sur ma machine de bureau à deux moniteurs. Mais d’après mon expérience en atelier, le comportement décrit par Korben tient la route : DockEcho se base sur les API d’accessibilité de macOS pour lire l’état du dock principal et le reproduire ailleurs. C’est la même technique que les utilitaires de fenêtrage qu’on utilise depuis des années, et ça fonctionne plutôt bien.
Concrètement, voilà ce que ça change au quotidien :
- Le dock mac apparaît sur chaque écran externe, pas seulement sur celui du MacBook
- Les réglages (taille, position, magnification) sont repris du dock principal
- La synchronisation se fait dans les deux sens : ajout, suppression, réorganisation
- Lancement manuel de l’app, pas d’agent au démarrage par défaut
- Compilation nécessaire : pas de binaire signé, pas d’installeur prêt à l’emploi
C’est ce dernier point qui me fait tiquer. DockEcho n’est pas distribué comme une app classique qu’on glisse dans Applications. Il faut cloner le dépôt, compiler avec Xcode ou la ligne de commande, et gérer soi-même l’autorisation d’accessibilité dans les Réglages Système. Pour un technicien comme moi, c’est l’affaire de dix minutes. Pour mon avocat lyonnais, c’est un coup à le perdre définitivement.
La compilation, ce faux obstacle qui en rebute plus d’un
Je vais être honnête : la compilation rebute 90% des utilisateurs. On me dira que c’est le prix de l’open source et de la transparence. Sauf que pour une app qui touche au dock et à l’accessibilité, le grand public a besoin d’un binaire signé et notarié, pas d’un projet GitHub en Swift qu’il faut assembler soi-même. C’est mon avis tranché, et je sais qu’il va faire grincer des dents dans la communauté open source. Mais un outil qui résout un problème aussi universel mérite mieux qu’un README avec trois lignes de terminal.
Du coup, en attendant qu’un petit malin publie un paquet Homebrew ou un binaire universel, DockEcho reste un outil de technicien. Ce qui n’est pas plus mal pour mon business, remarque. Ça me fait une prestation de plus à facturer : « installation et configuration d’utilitaire multi-écrans ».
Open source, licence MIT, et les limites que personne ne mentionne
Le choix de la licence MIT est cohérent avec l’esprit du projet. N’importe qui peut forker, modifier, redistribuer. C’est bien. Mais il faut aussi savoir ce qu’on installe. Une app qui lit l’état du dock et le reproduit sur d’autres écrans a besoin des autorisations d’accessibilité. Et une fois que tu as donné ça à une app, elle peut techniquement voir beaucoup de choses sur ton système. Je ne dis pas que DockEcho fait des choses louches. Je dis qu’il faut le savoir avant de cliquer sur « Autoriser ».
J’ai vu des utilitaires de ce genre, mal codés, provoquer des ralentissements au démarrage ou des conflits avec Mission Control. Sur mon poste de test, DockEcho n’a rien cassé. Mais je n’ai pas fait tourner l’outil pendant une semaine complète avec 25 fenêtres ouvertes et trois espaces de travail. Pour être honnête, je réserve mon jugement définitif à un usage prolongé.
Ce que j’attends de la suite
Trois choses, dans l’ordre : un binaire signé, un paquet Homebrew, et une gestion propre du démarrage automatique. Si l’auteur ajoute ça, DockEcho deviendra un incontournable pour tous les utilisateurs de Mac multi-écrans. En attendant, c’est un projet prometteur mais brut, à réserver aux utilisateurs qui savent compiler.
Et pour ceux qui se demandent si ça vaut le coup de passer par la case compilation : oui, si vous avez deux écrans ou plus. Non, si vous êtes sur un seul moniteur. Ça paraît bête, mais je préfère le dire.
Mon verdict de technicien : à garder sous le coude, pas encore à déployer partout
DockEcho résout un problème réel que macOS ignore depuis trop longtemps. Le concept est bon, la licence est propre, la synchronisation fonctionne. Mais l’absence de binaire prêt à l’emploi et la nécessité de compiler en font, pour l’instant, un outil de bricoleur averti. Ce n’est pas un défaut rédhibitoire, c’est une étape de maturation.
Pour mes clients, je vais attendre un paquet Homebrew ou un installeur signé avant de le recommander à grande échelle. Pour moi, je l’ai gardé dans ma boîte à outils. Histoire de gagner du temps la prochaine fois qu’un avocat lyonnais m’appelle en panique parce que son dock mac refuse de suivre sur son deuxième écran.
Source de l’info : DockEcho sur le blog de Korben.
Source : article original
