# A t’on vraiment besoin de découverte réseau?
**URL:** https://forum.duniter.org/t/a-t-on-vraiment-besoin-de-decouverte-reseau/14073
**Category:** Ğ1
**Created:** [7 October 2026 17:57 UTC](https://forum.duniter.org/t/a-t-on-vraiment-besoin-de-decouverte-reseau/14073 "2026-10-07T17:57:14Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [7 October 2026 17:57 UTC](https://forum.duniter.org/t/a-t-on-vraiment-besoin-de-decouverte-reseau/14073/1 "2026-10-07T17:57:14Z")
J’ai passé beaucoup de temps à optimiser la découverte réseau des nœuds RPC et indexers côté lib durt2 à ses débuts.
Je pense avoir trouvé, à l’époque, un bon compromis entre résilience en cas de perte significative du réseau et vitesse d’initialisation d’une connexion.
Mais avec le recul, je pense que tout ce mécanisme est sur-ingénieré, peu économe et inutilement complexe.
Même dans un réseau décentralisé, tant que ce réseau n’est pas distribué à 100 % dans chaque client, il me semble sain de pouvoir s’appuyer sur des nœuds de référence co-maintenus.
Les apps pourraient facilement faire confiance à ces nœuds et en ajouter d’autres en fallback.
De toute manière, même avec une découverte réseau, il est nécessaire d’avoir au moins un nœud bootstrap fonctionnel en cache pour débuter la découverte, quel que soit son format (p2p, rpc, etc.).
Les nœuds Duniter partagent déjà leurs endpoints connus via une requête RPC.
Avec ces simples éléments, je pense qu’on peut considérer une app comme robuste même si elle n’implémente pas de découverte réseau, avec fallback vers le noeud suivant si la chaine est bloqué ou inaccessible, ce qui correspondant alors a un mode dégradé relativement rare mais à considérer.
Je dis ça de manière générale, à destination des développeurs d’apps, afin de ne pas créer de freins à l’entrée inutiles.
Les mécanismes de découverte réseau restent intéressants, mais ils sont à mettre en balance avec le coût en complexité et en ressources côté apps que cela engendre, même si c’est optimisé et même si cela se passe en background.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [7 October 2026 18:25 UTC](https://forum.duniter.org/t/a-t-on-vraiment-besoin-de-decouverte-reseau/14073/2 "2026-10-07T18:25:31Z")
> [@poka](#):
>
> Même dans un réseau décentralisé, tant que ce réseau n’est pas distribué à 100 % dans chaque client, il me semble sain de pouvoir s’appuyer sur des nœuds de référence co-maintenus.
Qu’entends-tu par « distribué à 100 % dans chaque client » ? Et en quoi cela résoudrait-il le soi-disant problème de « sur-ingénierie » dont tu parles ?
Il me semble qu’en réalité, c’est l’inverse. Requêter plusieurs nœuds au hasard pour s’assurer d’avoir des réponses cohérentes me paraît beaucoup plus simple que d’avoir un client lourd qui devrait implémenter tout un protocole P2P pour répondre au besoin suivant :
Se couvrir contre un nœud dysfonctionnel ou malveillant.
De fait, toutes les applications devraient au moins avoir plusieurs nœuds bootstrap (et même le plus possible) dans leur code, et en choisir un ou plusieurs au hasard parmi ceux qui répondent suffisamment vite et correctement. Ce mécanisme n’est pas de la découverte réseau en soi.
Ce que j’entends par découverte réseau, c’est le fait de découvrir dynamiquement de nouveaux nœuds. C’est un plus, mais ce n’est pas une nécessité si l’application possède suffisamment de nœuds bootstrap dans son code et que cette liste de nœuds bootstrap est testée et actualisée à chaque mise à jour de l’application.