Claude

Le contexte Une petite ou moyenne installation accumule vite toute une série de composants qui parlent HTTP : un NAS, deux ou trois caméras PoE, un répéteur Wi-Fi, une box, une imprimante réseau, un ou plusieurs Raspberry Pi, quelques conteneurs Docker qui exposent une interface web. Presque tous s’annoncent en Bonjour / mDNS sous la forme _http._tcp. En pratique, cela se traduit par des adresses IP à retenir, la table DHCP du routeur à fouiller, ou des .local tapés de mémoire pour ouvrir la bonne interface. D’où une question toute simple : ...

Le contexte Dans le précédent article, le site SAR France a été migré de WordPress vers Hugo. Le site tourne, le contenu est en Markdown, le déploiement est automatisé. L’infrastructure est en place. Mais un problème subsistait : qui met à jour l’agenda ? Le site publie un agenda d’événements — conférences, commémorations, visites, assemblées. Le circuit en place ressemblait à ceci : Un membre du bureau envoie un mail au webmaster Le webmaster saisit manuellement l’événement dans un fichier technique Il recherche les coordonnées GPS du lieu sur Google Maps Il publie et vérifie que rien n’est cassé Quatre étapes, une seule personne. Un couplage fort entre le contributeur et le webmaster, et surtout un single point of failure classique : si le webmaster est en vacances, en déplacement ou simplement débordé, l’agenda ne bouge pas. Les événements s’accumulent dans une boîte mail en attendant. ...

Pourquoi migrer ? SAR France — la section française des Sons of the American Revolution — dispose d’un site institutionnel qui existe depuis de nombreuses années sous WordPress. WordPress est une plateforme adaptée pour démarrer rapidement, mais au fil du temps, les contraintes s’accumulent : mises à jour de plugins à gérer, base de données MySQL à maintenir, hébergement dynamique coûteux, et une inertie éditoriale qui ralentit toute contribution ponctuelle. ...