Mai, 2025

Critique de Horreur à Arkham, le jeu de rôle

Petite critique rapide de Horreur à Arkham, le jeu de rôle, tiré du jeu de société du même nom, lui-même inspiré du jeu de rôle L’Appel de Cthulhu, lui-même écrit d’après les nouvelles de notre cher H.P. Lovecraft. Eeet la boucle est bouclée.
Je n’avais pas entendu parler de ce jeu, ou très peu, et c’est en regardant la boîte dans un magasin que j’ai été intrigué. Une très jolie boîte en carton épais, émanation d’un jeu de société que j’aime beaucoup malgré sa punitivité et sa complexité — j’ai évidemment craqué.


Unboxing

Alors, quoi qu’il y a là-dedans ?

Eh bien, plein de choses. La boîte est bien remplie, le matériel est de très bonne qualité. Notamment, les cartes sont imprimées sur un papier très épais, limite bristol. Il y a des pions sur un carton très épais aussi, cinq feuilles de personnages avec tout ce qu’il faut pour jouer. Elles se présentent sous la forme d’un A3 plié en deux (j’ai dit que le papier était TRÈS épais), et contiennent toutes les bonnes informations : les caracs, le matos d’origine, les règles importantes, les montées de niveau… tout y est.

Il y a deux sets de 12 D6 chacun, donc 24 D6, plutôt jolis, 12 noirs et 12 verts. Ça semble faire beaucoup, mais vu qu’il en faut au moins 6 par perso, en vrai ce n’est même pas suffisant. J’en parlerai après, mais à cause d’une astuce de jeu, c’est compliqué de se les prêter. Ensuite, on trouve les cartes de monstres, parfaites, épaisses, solides, avec illustrations, motivations, et infos techniques. Et enfin, les cartes de matériel : les armes, armures et autres trucs qui font boum. Je rêverais d’une telle qualité pour mes cartes YxY.

On termine par l’aventure elle-même, sous la forme d’un livret cousu, un peu chelou d’ailleurs. La couture n’est pas super, y’a un fil qui dépasse, c’est vraiment bizarre par rapport à la qualité globale du machin.

Il n’y a pas de bouquin de règles à part, celles-ci étant incluses dans l’aventure.

Les illustrations sont absolument magnifiques, la maquette lisible, et j’ai dû voir une seule typo dans l’immensité du texte, ce qui est une sorte d’exploit…

Il faut savoir que je suis fan de matériel de jeu, surtout pour du Cthulhu. Je me souviens de parties où le frisson venait plus de la découverte d’un vieux carnet coincé derrière un meuble ou d’un message codé que le MJ avait imprimé sur un papier vieilli, que de la description d’un monstre vu déjà 100 fois.

Là, c’est un peu pareil : on a plein de matériel de jeu, et toutes les aides de jeu, tous les indices sont matérialisés.

Les règles

Les règles sont présentées dans les deux premiers actes du scénario (qui en comporte trois).

Elles ne sont pas très compliquées en soi, mais parfois un peu rigides dans leur explication. Typiquement, il existe trois types de scènes :

  • les simples, où tu parles et fais des actions évidentes (ouvrir une porte, répondre au téléphone),
  • les complexes, qui nécessitent des jets de dés,
  • les structurées, principalement les combats. La structure vient du découpage en rounds, nécessaire pour les scènes de bagarre.

Chaque joueur possède une réserve de dés : 6 s’il est en bonne santé, et de moins en moins au fur et à mesure des dégâts physiques encaissés. C’est très élégant et très visuel. Un perso avec 3 dés restants n’est clairement pas bien.

Les dégâts psychiques, dits d’horreur, remplacent les dés normaux par des dés verts. Si ces dés font 1, le personnage chope des traumas. Ce qui peut l’inciter à ne pas agir, justement pour éviter de lancer des dés. Idem, c’est plutôt élégant : j’aime quand la technique produit des effets de jeu ou incite à un certain comportement.

En dehors de ça, pour réussir une action, le personnage choisit un nombre de dés à lancer (jusqu’à son max). Chaque dé qui égale ou dépasse sa caractéristique est une réussite. Plus y’en a, mieux c’est.

Exemple : Joe tire au fusil de chasse sur le Byakhee méchant. Il choisit de lancer 4 dés (il a été blessé d’un point précédemment et veut en garder un pour se défendre), fait trois réussites, ce qui entame la créature et lui occasionne une blessure directement.

On peut garder des dés pour se défendre lors du tour de l’adversaire. Et les dégâts sont fixes en fonction de l’arme.

Juste une petite précision manquante : il me semble qu’on ne peut faire qu’une action par tour. Pas question de faire six attaques à un dé chacune, par exemple.

Dans les scènes structurées, on récupère tous ses dés à chaque round. Tandis que dans les scènes complexes, on récupère tous ses dés en une fois, quand le MJ décide que la scène avance. C’est pas mal, parce que ça oblige tout le monde à jouer et à dépenser ses dés. (Si Michel a dépensé 5 dés et Marc 2, on voit bien qu’il reste du temps à Marc, qui devrait trouver des choses à faire avant que la scène n’avance ou se termine.)

La gestion du temps est donc matérialisée par les mêmes dés, et encore une fois, je trouve ça élégant.

Enfin, le système de combat prévoit des battlemaps (des plans avec des cases), des déplacements précis case par case, des portées d’arme, etc. Ce n’est pas du tout ma came, mais ça aide certains joueurs à mieux visualiser ce qu’il se passe et où ils se trouvent.

Les personnages

Les cinq personnages présentés sont pré-tirés. Les joueurs n’ont rien d’autre à faire que de choisir celui qui leur plaît et de démarrer immédiatement. Il n’y a pas de système de création de personnage, et les évolutions sont conditionnées par le scénario lui-même.

Toute la palette classique de Cthulhu s’y retrouve : une lanceuse de sorts, un détective, une combattante au contact, un fossoyeur et une psychologue. Tous les personnages sont expérimentés et connaissent le surnaturel ou sont prêts à l’affronter rapidement. Pas question de se lancer en débutant tout frais. Même les règles de santé mentale sont un peu plus permissives que d’habitude.

Les personnages sont intégrés dans le scénario, et à plusieurs reprises, il sera fait mention de contacts que l’un ou l’autre pourrait avoir, les aidant dans la situation en cours.

L’aventure

À mon humble avis, c’est là que cela pêche un peu.

C’est un scénario ultra-classique pour débutant complet. Il y a zéro originalité : une secte de méchants veut invoquer un Ancien, il faut leur péter la mouille et arrêter le rituel. Fin.

En lisant le scénario, on retrouve les mêmes idées et développements qu’on pouvait lire il y a 30 ans avec Star Wars D6 : des paragraphes et des scènes très découpés, des lignes à lire ou paraphraser aux joueurs, des explications réduisant au maximum les frictions. On sent bien que c’est fait pour accompagner un maître de jeu (et des joueurs) qui se lanceraient pour la première fois. Ce n’est absolument pas un mal, mais c’est à savoir.

Il n’y a d’ailleurs qu’un seul scénario. Même s’il est complet, avec du matos de partout, c’est un peu chiche. J’aurais bien aimé avoir des idées de suite, à la manière du jeu de société qui présente des campagnes absolument fantastiques.

Par contre, tout y est : des battlemaps pour chaque lieu décrit, des fiches de monstres pour tous les PNJ rencontrés, des pions/figurines à placer, etc.

Il y a même des puzzles à résoudre, physiquement !

Conclusion

J’ai beaucoup aimé le matériel, la prise en main pour les débutants, et la promesse implicite de continuer à proposer une telle qualité de fabrication.

Je ne suis pas convaincu par le scénario lui-même, ni finalement par les règles. Elles ne sont pas mauvaises, loin de là : elles ne sont pas trop compliquées, élégantes, et proposent des possibilités de prises de risque. Mais je ne vois pas l’intérêt par rapport aux systèmes existants.

Le jeu est à 35€, et promet sans doute une à deux belles séances de jeu, ce qui n’est pas cher par rapport à la qualité du matériel.

C’est bien sûr parfaitement traduit (merci Sandy Julien).

En attendant de voir la suite, je conseillerais cette boîte aux débutants ou semi-débutants qui veulent découvrir Cthulhu et/ou un jeu de rôle qui n’est pas D&D.

Accès à distance en cas de coupure : Tunnel SSH et Relais 5G

Lorsque la connexion Internet principale tombe et que la seule alternative est une liaison de secours limitée, comme un partage de connexion 5G, qui ne permet pas la redirection de ports entrants, comment maintenir l’accès aux services autohébergés ? Cet article détaille une méthode technique pour rétablir l’accès externe à l’infrastructure interne en utilisant un tunnel SSH inversé via un serveur intermédiaire (VPS) et en reconfigurant temporairement le réseau local pour utiliser la connexion de secours.


Le Problème : Perte de Redirection de Ports

Dans une configuration classique d’auto-hébergement, votre routeur principal redirige les requêtes entrantes (sur les ports 80, 443, etc.) depuis Internet vers les machines appropriées de votre réseau local. Lorsqu’une coupure survient et que vous basculez sur une connexion de secours via un téléphone (partage de connexion USB ou Wi-Fi), cette nouvelle connexion ne permet généralement pas de configurer ces redirections de ports. Votre réseau interne peut accéder à Internet, mais Internet ne peut plus initier de connexions vers votre réseau.

La Solution : Tunnel SSH Inversé via un VPS Relais

La méthode que nous allons décrire contourne cette limitation en inversant le flux de connexion. Au lieu que l’extérieur se connecte directement à votre réseau, une machine de votre réseau interne va initier une connexion sortante sécurisée (un tunnel SSH) vers un serveur externe (un VPS) disposant d’une IP publique statique. Ce VPS servira de point de relais : il écoutera les requêtes entrantes de l’extérieur sur les ports standard (80, 443) et les transmettra à votre réseau interne à travers le tunnel SSH déjà établi.

Chapitre 1 : Rétablir la Connectivité Internet Locale

La première étape est de s’assurer que votre réseau interne puisse accéder à Internet via la connexion de secours (le téléphone 5G).

  1. Brancher le téléphone et activer le partage de connexion : Connectez votre téléphone à une machine de votre réseau interne (dans cet exemple, ma machine proxmox avec l’IP 192.168.1.3) via USB et activez le partage de connexion. Un nouveau périphérique réseau (souvent nommé usb-tether ou similaire) devrait apparaître sur la machine interne.
  2. Activer l’interface réseau : Activez la nouvelle interface si elle ne l’est pas automatiquement.
    sudo ifup usb-tether

    Attention, le nom de l’interface réseau va changer à chaque connexion du téléphone. C’est super relou, et j’ai du batailler un peu pour avoir un nom fixe (usb-tether). Google est votre ami.

    Vérifiez que l’interface a obtenu une adresse IP du téléphone :
    ip a
  3. Activer le forwarding IP : Pour que la machine interne puisse router le trafic des autres machines du réseau, le forwarding IP doit être activé.
    sudo nano /etc/sysctl.conf

    Décommentez ou ajoutez la ligne suivante :
    net.ipv4.ip_forward=1

    Appliquez la modification sans redémarrer :
    sudo sysctl -p
  4. Configurer la traduction d’adresses réseau (NAT) : Les paquets provenant de votre réseau local (192.168.1.0/24) doivent être réécrits avec l’adresse IP de la machine interne sur l’interface usb-tether avant de sortir.
    sudo iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o usb-tether -j MASQUERADE
  • -t nat : Spécifie la table NAT.
  • -A POSTROUTING : Ajoute une règle à la chaîne POSTROUTING (appliquée juste avant que le paquet ne quitte la machine).
  • -s 192.168.1.0/24 : Source des paquets (votre réseau local).
  • -o usb-tether : Interface de sortie (celle du téléphone).
  • -j MASQUERADE : Action de masquerade (NAT dynamique utilisant l’IP de l’interface de sortie).

À ce stade, la machine interne peut accéder à Internet via le téléphone.

Chapitre 2 : Rerouter le Réseau Local

Maintenant que la machine interne a une connexion Internet fonctionnelle, il faut indiquer aux autres machines du réseau d’utiliser cette machine comme passerelle par défaut.

  1. Modifier la passerelle par défaut via DHCP : Votre serveur DHCP (chez moi, dnsmasq sur 192.168.1.1) attribue normalement la passerelle par défaut. Modifiez sa configuration pour qu’il distribue l’adresse IP de la machine interne (192.168.1.3) comme passerelle.
    Connectez-vous en SSH à votre serveur DNS/DHCP :
    ssh utilisateur@192.168.1.1

    Éditez le fichier de configuration de dnsmasq :
    sudo nano /etc/dnsmasq.conf

    Trouvez la ligne dhcp-option=3,… et modifiez-la :
    dhcp-option=3,192.168.1.3
  • dhcp-option=3 : Spécifie l’option DHCP pour la passerelle par défaut (router).
  • 192.168.1.3 : La nouvelle adresse IP de la passerelle.
  1. Appliquer la nouvelle passerelle sur les clients : Les machines clientes doivent renouveler leur bail DHCP pour obtenir la nouvelle adresse de passerelle.
  • Sur Linux : Redémarrez le service réseau ou utilisez sudo dhclient -r && sudo dhclient.
  • Sur Windows : Ouvrez une invite de commande et exécutez ipconfig /renew.
  • Sur macOS : Désactivez puis réactivez l’interface réseau dans les paramètres.
  1. Vérifier la nouvelle passerelle : Sur une machine cliente, vérifiez que la passerelle par défaut est bien 192.168.1.3.
  • Sur Windows : ipconfig /all
  • Sur Linux/macOS : ip r ou netstat -rn
  1. Tester la connectivité externe : Vérifiez que les machines du réseau peuvent accéder à Internet.
  • Tester un ping direct (sans résolution DNS) :
    ping 1.1.1.1
  • Tester un ping avec résolution DNS :
    ping www.google.fr

Si ces pings fonctionnent, tout le réseau utilise maintenant la connexion de secours pour sortir.

Chapitre 3 : Créer le Tunnel Inversé

Maintenant que le réseau interne peut communiquer vers l’extérieur, nous allons établir un tunnel SSH inversé depuis la machine interne vers votre VPS externe.

  1. Préparer le VPS pour le tunnelling SSH : Connectez-vous en SSH à votre VPS externe.
    ssh utilisateur_vps@adresse_ip_publique_vps

    Éditez le fichier de configuration du démon SSH :
    sudo nano /etc/ssh/sshd_config

    Assurez-vous que les lignes suivantes sont présentes et activées :
    AllowTcpForwarding yes
    GatewayPorts yes
  • AllowTcpForwarding yes : Autorise les redirections de ports.
  • GatewayPorts yes : Permet de lier le port redirigé à l’adresse IP publique du VPS, le rendant accessible depuis Internet (et pas seulement depuis le VPS lui-même).

Note sur les ports 80/443 et PermitRootLogin : Tenter de lier directement les ports 80 et 443 avec un tunnel SSH inversé peut échouer si un autre service (comme un serveur web) écoute déjà sur ces ports, ou si l’utilisateur SSH n’a pas les permissions suffisantes (ports < 1024 nécessitent root). Si vous recevez des messages d’erreur (Warning: remote port forwarding failed for listen port…), cela indique probablement un conflit de port ou un problème de permission.Si vous devez lier directement 80/443 et que vous êtes certain qu’aucun autre service ne les utilise, vous pourriez tenter d’établir la connexion SSH en tant que root sur le VPS. Cela nécessite d’autoriser la connexion root via SSH, ce qui est fortement déconseillé pour des raisons de sécurité. Si vous choisissez cette voie temporairement, modifiez sshd_config sur le VPS :PermitRootLogin yes
N’oubliez pas de désactiver PermitRootLogin yes et de redémarrer sshd une fois le dépannage terminé ou si vous optez pour la méthode du proxy inverse (recommandée). La méthode la plus propre est d’utiliser un port différent pour le tunnel et un proxy inverse sur le VPS.

  1. Redémarrer le service SSH sur le VPS :
    sudo systemctl restart sshd
  2. Établir le tunnel inversé depuis la machine interne : Connectez-vous depuis la machine interne vers le VPS en demandant la redirection des ports 80 et 443 du VPS vers l’IP et les ports de votre proxy inverse interne (ici, 192.168.1.2:80 et 192.168.1.2:443).
    ssh -i <chemin_vers_votre_cle_ssh>.pem -N -T -R 80:192.168.1.2:80 -R 443:192.168.1.2:443 utilisateur_vps@adresse_ip_publique_vps
  • -i <chemin_vers_votre_cle_ssh>.pem : Spécifie la clé privée SSH à utiliser (recommandé pour l’automatisation).
  • -N : Ne pas exécuter de commande distante.
  • -T : Désactiver l’allocation d’un pseudo-terminal.
  • -R <Port_Externe>:<IP_Interne>:<Port_Interne> : Configure la redirection inversée. Le trafic arrivant sur <Port_Externe> du VPS est redirigé vers <IP_Interne>:<Port_Interne> via le tunnel.
  • utilisateur_vps@adresse_ip_publique_vps : Les informations de connexion au VPS.

Si vous avez utilisé PermitRootLogin yes et que vous vous connectez en root :ssh -i <chemin_vers_votre_cle_ssh>.pem -N -T -R 80:192.168.1.2:80 -R 443:192.168.1.2:443 root@adresse_ip_publique_vps

La connexion en root n’est pas très sécurisée, mais c’est ce qui permet d’ouvrir les ports <1024 sans autre étapes techniques. En vrai, il faudrait plutôt passer par un reverse proxy sur le VPS. Mais je voulais aller vite.

  1. Maintenir le tunnel actif : La commande ssh seule se terminera si la connexion est interrompue. Utilisez autossh pour redémarrer automatiquement le tunnel.
    autossh -M 0 -N -T -R 80:192.168.1.2:80 -R 443:192.168.1.2:443 utilisateur_vps@adresse_ip_publique_vps

    Configurez autossh en tant que service systemd sur la machine interne pour qu’il démarre automatiquement au boot.

Chapitre 4 : Modifier le DNS Externe

Pour que vos noms de domaine pointent vers votre VPS qui sert de relais, vous devez modifier vos enregistrements DNS externes.

  1. Accéder à la gestion DNS : Connectez-vous à l’interface de gestion DNS chez votre registrar (là où vous avez acheté votre nom de domaine memoiresecondaire.fr).
  2. Modifier les enregistrements A/AAAA : Modifiez l’enregistrement A (pour IPv4) et éventuellement AAAA (pour IPv6) pour votre domaine principal (memoiresecondaire.fr) et pour les sous-domaines (l’enregistrement wildcard *.memoiresecondaire.fr est idéal ici) pour qu’ils pointent vers l’adresse IP publique de votre VPS.
  • Type : A
  • Nom : * (pour le wildcard, couvre tous les sous-domaines)
  • Valeur : <adresse_ip_publique_du_vps>
  • Type : A
  • Nom : @ (pour le domaine principal lui-même)
  • Valeur : <adresse_ip_publique_du_vps>

Les modifications DNS peuvent prendre un certain temps à se propager sur Internet (propagation DNS).

Chapitre 5 : Vérification

Une fois toutes les étapes précédentes effectuées, vous devriez pouvoir accéder à vos services depuis l’extérieur.

  1. Vider le cache DNS local : Sur la machine externe depuis laquelle vous testez l’accès, videz le cache DNS pour vous assurer qu’elle utilise les nouvelles informations DNS.
  • Sur Windows : Ouvrez une invite de commande et exécutez ipconfig /flushdns.
  • Sur Linux : sudo systemd-resolve –flush-caches ou redémarrez le service réseau.
  • Sur macOS : sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
  1. Tester l’accès via le navigateur : Ouvrez un navigateur et essayez d’accéder à un de vos services en utilisant son nom de domaine complet, par exemple jellyfin.memoiresecondaire.fr. La requête devrait maintenant passer par l’IP de votre VPS, traverser le tunnel SSH, atteindre votre proxy inverse interne, et finalement votre service.

Conclusion

Cette méthode, bien que nécessitant plusieurs étapes de configuration (rétablissement de la connexion de secours, reroutage du réseau local, mise en place du tunnel SSH inversé et mise à jour DNS), offre une solution efficace pour maintenir l’accès externe à votre infrastructure auto-hébergée même en cas de défaillance de votre connexion Internet principale et de l’impossibilité de rediriger les ports. Elle s’appuie sur des technologies standard (SSH, iptables, DNS) et un minimum de ressources externes (un petit VPS), vous donnant un contrôle total sur le processus. N’oubliez pas de revenir à votre configuration réseau et DNS d’origine une fois que votre connexion Internet principale est rétablie.