Merci pour l’analyse 
Dans ce cas là l’intégration externe ne devrait pas fonctionner même quand il sont sur le même réseau ?
Ah moins que quand tu es sur le même réseau il envoie des requêtes unicast et l’explication pourrait se tenir
C’est étrange lors du second scan j’ai 1 appareil en moins trouvé quand j’ai débranché mon Apple TV
[2026-08-16T18:35:13.529Z] [INFO] [apple-tv] Gladys captured 5 AirPlay announcement(s)
[2026-08-16T18:35:13.529Z] [INFO] [apple-tv] Verifying 5 candidate address(es) with pyatv
[2026-08-16T18:35:21.531Z] [INFO] [apple-tv] Found 0 Apple TV(s)
[2026-08-16T18:35:55.134Z] [INFO] [apple-tv] Scan requested
[2026-08-16T18:36:03.139Z] [INFO] [apple-tv] Gladys captured 4 AirPlay announcement(s)
[2026-08-16T18:36:03.139Z] [INFO] [apple-tv] Verifying 4 candidate address(es) with pyatv
[2026-08-16T18:36:11.141Z] [INFO] [apple-tv] Found 0 Apple TV(s)
Est-ce qu’il y a moyen d’avoir un mode debug pour voir quel appareil il voit et potentiellement trouver pourquoi il les ajoutent pas dans la découverte 
Merci, ce test est très utile : le passage de 5 à 4 après avoir débranché l’Apple TV confirme que Gladys voit bien son annonce AirPlay et récupère son IP (du moins je pense). Le blocage intervient ensuite, lorsque pyatv tente de compléter les informations par une requête mDNS directe, ignorée entre sous-réseaux.
La version `1.1.0` de l’intégration est en cours de build, elle détaille désormais dans les logs le nom, l’hôte, l’IP et le port de chaque annonce/candidate. Cela confirmera clairement quelle adresse correspond à l’Apple TV, même si le correctif réseau reste nécessaire pour récupérer les autres services requis.
Merci
Voici le resultat :
[2026-08-17T18:15:52.654Z] [INFO] [apple-tv] AirPlay announcement 3/5: {"name":"Chambre._airplay._tcp.local","host":"Chambre.local","addresses":["fe80::7:3db5:2499:xxx","fdfd:9ce7:d5fe:4961:c02:da41:da37:xxxx","192.168.xx.10","fdfd:9ce7:d5fe:4961:6:fda9:17a6:xxxx"],"ipv4":["192.168.xx.10"],"port":7000}
[2026-08-17T18:15:52.655Z] [INFO] [apple-tv] Candidate address 3/5: {"address":"192.168.xx.10","sources":["AirPlay announcement","manual configuration"]}
[2026-08-17T18:15:52.655Z] [INFO] [apple-tv] Verifying 5 candidate address(es) with pyatv
[2026-08-17T18:16:00.657Z] [WARN] [apple-tv] No candidate answered pyatv's direct mDNS query: 192.168.xx.12, 192.168.xx.9, 192.168.xx.10, 192.168.xx.7, 192.168.xx.8. On routed networks or separate VLANs, Apple devices normally ignore direct mDNS queries whose source is outside their local subnet.
[2026-08-17T18:16:00.658Z] [INFO] [apple-tv] Found 0 Apple TV(s)
Etrange que l’on voit uniquement Chambre._airplay._tcp.local
Et pas Chambre._companion-link._tcp
Merci pour le retour, les logs confirment bien le diagnostic : Gladys reçoit l’annonce AirPlay et la bonne IP, mais la vérification directe de pyatv n’obtient aucune réponse entre les VLAN.
L’absence de _companion-link._tcp est actuellement normale : seul _airplay._tcp est déclaré, et Gladys parcourt jusqu’ici que le premier service mDNS d’une intégration.
@pierre-gilles J’ai proposé un correctif côté Gladys : PR #2951 qui permet de récupérer et fusionner tous les services mDNS déclarés.
@prohand En principe, si cette évolution est intégrée dans Gladys, on pourra prévoir une nouvelle version de l’intégration Apple TV qui exploitera directement ces annonces au lieu de refaire une requête mDNS depuis son conteneur. La 1.1.0 améliore donc le diagnostic, mais le support inter-VLAN nécessitera cette prochaine version.
Parfait merci
Merci j’ai mis mes retours
Merci, j’ai fait tourné claude dessus 