Derniers messages
Dernier message par Zatalyz - Hier à 11:02:29
Cliquez pour afficher le message
Merci Pulkomandy pour ces infos 
Ho, ça, c'est tout simple et génial. Aucun risque qu'un "légitime" suive, et c'est trop tentant pour un bot néfaste par contre, donc une chance de le chopper tout de suite. Je bloque déjà sur des mot-clés d'url régulièrement recherché, mais parfois le comportement des bots est étrange et ces mots-clés arrivent tard. Là, on leur ajoute un appât.
CitationDans mon robots.txt j'ai mis un Disallow /url-interdite.
L'URL en question est également présente dans les en-têtes ou en bas de page de mon site, avec un texte disant "si vous êtes un humain, ne cliquez pas ici vous allez vous faire bannir". Le lien est également en nofollow.
Ho, ça, c'est tout simple et génial. Aucun risque qu'un "légitime" suive, et c'est trop tentant pour un bot néfaste par contre, donc une chance de le chopper tout de suite. Je bloque déjà sur des mot-clés d'url régulièrement recherché, mais parfois le comportement des bots est étrange et ces mots-clés arrivent tard. Là, on leur ajoute un appât.
CitationLe seul moyen de leur rendre la vie impossible, c'est que chaque site web aie ses propres règles.Pas faux... Il y a certains trucs qui peuvent se partager, mais d'autres où en effet, ça se fait dépasser. C'est toujours une course de toute façon. On peut se partager des trucs en privés aussi, mais... dans le fond, les grandes lignes sont là, et reste surtout à appliquer.
Dernier message par pulkomandy - Hier à 09:52:35
Cliquez pour afficher le message
Salut!
Je peux donner quelques infos sur ce que je fais chez moi.
0. Les bases
- Pour Google, Bing et les moteurs de recherche classique: j'ai configuré un "Crawl-Delay" dans le fichier robots.txt. Cela leur demande de ne pas faire plus d'une requête toutes les quelques secondes (on choisit combien) et réduit leur traffic de façon acceptable. C'est bien respecté par les crawlers des moteurs de recherche.
- Pour les scrappers "honnêtes" (bot SEO par exemple, mais certains trucs de LLM aussi): blocage par une liste d'identifiants de bots dans le robots.txt avec une règle "Disallow /"
Là on a les bases pour les trucs implémentés correctement. Ensuite il faut lutter contre les trucs malveillants et/ou mal fichus.
1. Blocage des bots ne respectant pas le robots.txt
Dans mon robots.txt j'ai mis un Disallow /url-interdite.
L'URL en question est également présente dans les en-têtes ou en bas de page de mon site, avec un texte disant "si vous êtes un humain, ne cliquez pas ici vous allez vous faire bannir". Le lien est également en nofollow.
Si un bot accède à cette URL, c'est blocage direct.
Pour implémenter le blocage: règle spécifique dans le serveur web, qui retourne une erreur spécifique (j'ai choisi le code HTTP 429). J'ai ensuite une règle fail2ban qui scanne les logs de mon serveur HTTP pour trouver ces erreurs 429 et bloquer les IP correspondantes au niveau du pare-feu. Le même principe est utilisé dans les sections suivantes.
On peut aussi faire la même chose pour plein d'URLs "classiques" utilisés par des scanners de vulérabilités qui cherchent des wordpress, phpmyadmin, et autres nids à failles connus.
2. Filtrage par user agent
Pour certains bots ne respectant pas le robots.txt (typiquement, ne respectant pas le crawl-delay), mais qui s'identifient avec un user agent unique, filtrage des user agents "interdits" au niveau du serveur web.
3. Les bots "cachés"
Comme je ne suis pas le seul à mettre en place ce genre de mesures, il y a maintenant des bots qui se déclarent avec un user agent "classique" (typiquement une version de Chrome, mais il commence à y avoir aussi du Firefox). On peut tenter de bloquer les IPs "non résidentielles" quand on repère une plage d'IP (il y a eu Tencent et Alibaba il me semble, mais il y en a de nouvelles régulièrement).
Là, on peut au choix bannir ces IPs "préventivement" de façon statique dans le pare-feu, ou bien attendre la première requête sur le serveur web pour réagir.
4. Les proxys résidentiels
C'est la dernière nouveauté. Comme les IPs de datacenters sont de plus en plus mal vues par les sites internets, les robots utilisent maintenant des relais déployés via des applications sur des téléphones ou des télés connectées chez plein de gens.
J'ai lu un blog de quelqu'un indiquant que son site avait reçu des requêtes venant de un quart de l'espace d'addresage IP. En gros, quasiment toutes les IP possibles vont être utilisées, et ça devient très difficile de faire un blocage par IP (même les pare-feus ne suivent plus: il y a tellement d'IPs qu'il faut plusieurs Go de mémoire juste pour stocker la liste des IP bloquées...). Et chaque IP ne va typiquement faire qu'une seule requête, donc le blocage est peu efficace si on attend d'avoir plusieurs requêtes avant de bloquer.
Le blocage géographique peut être une solution (si vous acceptez de restreindre l'accès pour certains pays, mais il risque d'y en avoir de plus en plus tant qu'il n'y aura pas de législation pour interdire ces pratiques).
Chez moi, j'ai fini par bloquer toutes les versions un peu anciennes de Chrome et Firefox pour Windows. Comme ces robots ont tendance à utiliser des user agents ne correspondant pas à la toute dernière version, ça limite assez les problèmes. Et les gens utilisant un autre OS ou un autre navigateur ne sont pas impactés.
5. Pourquoi ces attaques?
Ce que j'observe, c'est que les interfaces web de dépôts git comportent une quasi infinité de liens (historique des versions, puis affichage de chaque fichier dans chaque version, etc). C'est le "tarpit" parfait pour un robot scrapper d'entraînement LLM, tout plein de contenu à lire!
Je pense qu'avec un site comportant moins de liens, il y a moins de problèmes, le robot va rapidement en faire le tour et aller voir ailleurs.
Dans certains cas j'ai fini par mettre mon interface web de dépôt Git accessible uniquement après login.
6. Conclusion
Je vous donne volontairement peu de détails spécifiques sur ma configuration.
Le déploiement de solutions "universelles" (Anubis, iocaine, ou de façon générale une config standardisée avec une liste de user agent connue) pousse les développeurs de bots à trouver un contournement spécifique pour la solution la plus populaire. Le seul moyen de leur rendre la vie impossible, c'est que chaque site web aie ses propres règles. Donc, adapter votre configuration à ce que vous observez est la bonne démarche. Et aussi choisir vos propres durées de ban, pour pas que tout le monde aie la même.
J'arrive à garder le traffic à un niveau acceptable chez moi (pour un serveur auto hébergé sur ma connexion fibre à la maison, sans que ça pénalise les autres utilisations du serveur et de la connexion internet), mais régulièrement (tous les quelques mois) je dois mettre à jour ma liste de bans suite à un nouvel user agent ou une nouvelle forme d'attaque. Donc il faut garder un oeuil sur les accès au serveur web, c'est pas vraiment un truc qu'on peut configurer une fois et laisser tourner tout seul
7. Bonus: le monitoring.
J'utilisais awstats pour surveiller le traffic sur mon site. ça marchait bien pour repérer les pics de traffic et autres trucs louches. Mais awstats sur mon serveur n'arrive plus à suivre quand il y a des millions de requêtes à scanner dans les logs.
Je l'ai remplacé par goaccess, il est moins bien, mais plus rapide.
Bon courage!
Je peux donner quelques infos sur ce que je fais chez moi.
0. Les bases
- Pour Google, Bing et les moteurs de recherche classique: j'ai configuré un "Crawl-Delay" dans le fichier robots.txt. Cela leur demande de ne pas faire plus d'une requête toutes les quelques secondes (on choisit combien) et réduit leur traffic de façon acceptable. C'est bien respecté par les crawlers des moteurs de recherche.
- Pour les scrappers "honnêtes" (bot SEO par exemple, mais certains trucs de LLM aussi): blocage par une liste d'identifiants de bots dans le robots.txt avec une règle "Disallow /"
Là on a les bases pour les trucs implémentés correctement. Ensuite il faut lutter contre les trucs malveillants et/ou mal fichus.
1. Blocage des bots ne respectant pas le robots.txt
Dans mon robots.txt j'ai mis un Disallow /url-interdite.
L'URL en question est également présente dans les en-têtes ou en bas de page de mon site, avec un texte disant "si vous êtes un humain, ne cliquez pas ici vous allez vous faire bannir". Le lien est également en nofollow.
Si un bot accède à cette URL, c'est blocage direct.
Pour implémenter le blocage: règle spécifique dans le serveur web, qui retourne une erreur spécifique (j'ai choisi le code HTTP 429). J'ai ensuite une règle fail2ban qui scanne les logs de mon serveur HTTP pour trouver ces erreurs 429 et bloquer les IP correspondantes au niveau du pare-feu. Le même principe est utilisé dans les sections suivantes.
On peut aussi faire la même chose pour plein d'URLs "classiques" utilisés par des scanners de vulérabilités qui cherchent des wordpress, phpmyadmin, et autres nids à failles connus.
2. Filtrage par user agent
Pour certains bots ne respectant pas le robots.txt (typiquement, ne respectant pas le crawl-delay), mais qui s'identifient avec un user agent unique, filtrage des user agents "interdits" au niveau du serveur web.
3. Les bots "cachés"
Comme je ne suis pas le seul à mettre en place ce genre de mesures, il y a maintenant des bots qui se déclarent avec un user agent "classique" (typiquement une version de Chrome, mais il commence à y avoir aussi du Firefox). On peut tenter de bloquer les IPs "non résidentielles" quand on repère une plage d'IP (il y a eu Tencent et Alibaba il me semble, mais il y en a de nouvelles régulièrement).
Là, on peut au choix bannir ces IPs "préventivement" de façon statique dans le pare-feu, ou bien attendre la première requête sur le serveur web pour réagir.
4. Les proxys résidentiels
C'est la dernière nouveauté. Comme les IPs de datacenters sont de plus en plus mal vues par les sites internets, les robots utilisent maintenant des relais déployés via des applications sur des téléphones ou des télés connectées chez plein de gens.
J'ai lu un blog de quelqu'un indiquant que son site avait reçu des requêtes venant de un quart de l'espace d'addresage IP. En gros, quasiment toutes les IP possibles vont être utilisées, et ça devient très difficile de faire un blocage par IP (même les pare-feus ne suivent plus: il y a tellement d'IPs qu'il faut plusieurs Go de mémoire juste pour stocker la liste des IP bloquées...). Et chaque IP ne va typiquement faire qu'une seule requête, donc le blocage est peu efficace si on attend d'avoir plusieurs requêtes avant de bloquer.
Le blocage géographique peut être une solution (si vous acceptez de restreindre l'accès pour certains pays, mais il risque d'y en avoir de plus en plus tant qu'il n'y aura pas de législation pour interdire ces pratiques).
Chez moi, j'ai fini par bloquer toutes les versions un peu anciennes de Chrome et Firefox pour Windows. Comme ces robots ont tendance à utiliser des user agents ne correspondant pas à la toute dernière version, ça limite assez les problèmes. Et les gens utilisant un autre OS ou un autre navigateur ne sont pas impactés.
5. Pourquoi ces attaques?
Ce que j'observe, c'est que les interfaces web de dépôts git comportent une quasi infinité de liens (historique des versions, puis affichage de chaque fichier dans chaque version, etc). C'est le "tarpit" parfait pour un robot scrapper d'entraînement LLM, tout plein de contenu à lire!
Je pense qu'avec un site comportant moins de liens, il y a moins de problèmes, le robot va rapidement en faire le tour et aller voir ailleurs.
Dans certains cas j'ai fini par mettre mon interface web de dépôt Git accessible uniquement après login.
6. Conclusion
Je vous donne volontairement peu de détails spécifiques sur ma configuration.
Le déploiement de solutions "universelles" (Anubis, iocaine, ou de façon générale une config standardisée avec une liste de user agent connue) pousse les développeurs de bots à trouver un contournement spécifique pour la solution la plus populaire. Le seul moyen de leur rendre la vie impossible, c'est que chaque site web aie ses propres règles. Donc, adapter votre configuration à ce que vous observez est la bonne démarche. Et aussi choisir vos propres durées de ban, pour pas que tout le monde aie la même.
J'arrive à garder le traffic à un niveau acceptable chez moi (pour un serveur auto hébergé sur ma connexion fibre à la maison, sans que ça pénalise les autres utilisations du serveur et de la connexion internet), mais régulièrement (tous les quelques mois) je dois mettre à jour ma liste de bans suite à un nouvel user agent ou une nouvelle forme d'attaque. Donc il faut garder un oeuil sur les accès au serveur web, c'est pas vraiment un truc qu'on peut configurer une fois et laisser tourner tout seul
7. Bonus: le monitoring.
J'utilisais awstats pour surveiller le traffic sur mon site. ça marchait bien pour repérer les pics de traffic et autres trucs louches. Mais awstats sur mon serveur n'arrive plus à suivre quand il y a des millions de requêtes à scanner dans les logs.
Je l'ai remplacé par goaccess, il est moins bien, mais plus rapide.
Bon courage!
Dernier message par Zatalyz - 29 Juin 2026 à 09:36:32
Cliquez pour afficher le message
C'est dense, et hyper intéressant. Mais dense ! Merci pour le lien, c'est de bonnes bases, par contre je trouve cela difficile à exploiter "tel quel" : je ne saurais pas trop comment utiliser et mettre en place certains morceaux, certaines règles me semblent un peu légères (= peu durables dans le temps, vite contournées, comme avec les ip Tencent). Cependant comme il explique la logique, ça devrait permettre d'affiner.
Et là pour le coup c'est à la fois intéressant et... j'en veux plus (mais je vais regarder le reste de ce qu'il a partagé) : bien comprendre les patterns qu'il détecte.
Je ne pense pas l'utiliser tel quel, mais l'intégrer dans notre logique.
Je pense de mon côté qu'il y a trois niveaux :
- Un set d'ip identifiées comme problématiques, qu'on va bannir sur des temps longs (1 à 6 mois sans souci) et très certainement par plage d'ip ; ce genre de set devrait juste être partagé sur nos reseaux et bloqué au niveau des proxy (via nftables). La détection de ces ip pourrait passer par du honeypot, avec potentiellement greylisting sur certains acteurs (genre si on veut être référencé par certains moteurs de recherche pour ce qui concerne le web), ainsi que par l'analyse des logs de Reaction.
- Des comportements tellement problématiques que ça sera géré direct avec Reaction et donc bloqué ensuite via le pare-feu.
- Des comportements qui sont ok... suivant le flux, et là c'est avec nginx/apache qu'on commence à les gérer.
Exemple qui ne pose pas question : le bot qui scanne "bêtement" si on a un "wp-login" => c'est du pur badbot, ça je bannis 1 mois sans souci.
Exemple qui me pose plus question : les bots d'indexeurs. Dans l'absolu, on n'est pas contre se faire trouver par les moteurs de recherche. Et j'inclue dans ces derniers même les IA, puisque la recherche par LLM est en train de remplacer l'ancienne. Mais ces bots posent soucis à cause de leur fréquence de visite. Une fois par jour, avec une navigation tranquille sur nos pages ça va ; par contre scanner tout notre site non stop c'est juste une charge trop lourde. Donc on doit leur balancer une erreur 429 : Too Many Requests. Ça, c'est géré par nginx/apache.
Là où ça devient complexe, c'est que le bot qui reçoit une 429 et se calme dans la foulée est OK, mais il y en a qui vont continuer à frapper à la porte non-stop (ouais, les bots, c'est aussi cons que leurs concepteurs) et ces requêtes continuent de peser sur nginx. Donc à un moment : trop de 429 sur une ip = ban par le firewall. Pour le bot ce sera comme si le serveur était tombé. Là dessus, je serais d'avis de bannir 24h. Faut pas pousser. Mais aussi d'analyser si on a certains qui abusent toutes les 24h => ils passent dans la liste à virer.
Maiiiiis ça veut aussi dire, très certainement, questionner ce qu'on fait de Google et Bing (entre autre). Et vu ce que dit blablalinux, sans doute des instances Searx. Est-ce qu'on souhaite les bannir définitivement si elles se comportent mal ? Est-ce qu'on les met dans un set spécial "vous êtes des chieuses, mais on vous autorise à l'être entre minuit et 2h du matin pour alimenter vos index et qu'on nous trouve" ?
Concernant le partage des IP bannies à long terme, mon idée est la suivante :
- Sur chaque serveur, quand Reaction banni une ip, cela alimente un fichier de log avec la raison (et la durée).
- Ces logs sont envoyés à un serveur central (une fois par jour ?)
- Ils sont analysés avec un script bash, histoire de voir les ips qui reviennent, encore et encore, ou bien celles dont les "raisons" justifient un ban à long terme. Les ips sont amalgamé, si cela concerne des plages, on se contente de la plage. On publie alors sur ce serveur central notre liste d'ip bannies (en mode API idéalement, mais ce sera ptet plus basique) et nos autres serveurs viennent se servir pour alimenter leur set "banni à long terme".
C'est assez basique. Très probablement, je pourrais utiliser la même logique dans les deux cas : les logs accessibles en lecture via le web (oui, *peut-être* derrière une api, ou pas), et des processus internes pour en faire un truc. Avec mes connaissances actuelles, ça serait wget+bash mais les devs auront ptet plus pertinent à proposer.
Et là pour le coup c'est à la fois intéressant et... j'en veux plus (mais je vais regarder le reste de ce qu'il a partagé) : bien comprendre les patterns qu'il détecte.
Je ne pense pas l'utiliser tel quel, mais l'intégrer dans notre logique.
Je pense de mon côté qu'il y a trois niveaux :
- Un set d'ip identifiées comme problématiques, qu'on va bannir sur des temps longs (1 à 6 mois sans souci) et très certainement par plage d'ip ; ce genre de set devrait juste être partagé sur nos reseaux et bloqué au niveau des proxy (via nftables). La détection de ces ip pourrait passer par du honeypot, avec potentiellement greylisting sur certains acteurs (genre si on veut être référencé par certains moteurs de recherche pour ce qui concerne le web), ainsi que par l'analyse des logs de Reaction.
- Des comportements tellement problématiques que ça sera géré direct avec Reaction et donc bloqué ensuite via le pare-feu.
- Des comportements qui sont ok... suivant le flux, et là c'est avec nginx/apache qu'on commence à les gérer.
Exemple qui ne pose pas question : le bot qui scanne "bêtement" si on a un "wp-login" => c'est du pur badbot, ça je bannis 1 mois sans souci.
Exemple qui me pose plus question : les bots d'indexeurs. Dans l'absolu, on n'est pas contre se faire trouver par les moteurs de recherche. Et j'inclue dans ces derniers même les IA, puisque la recherche par LLM est en train de remplacer l'ancienne. Mais ces bots posent soucis à cause de leur fréquence de visite. Une fois par jour, avec une navigation tranquille sur nos pages ça va ; par contre scanner tout notre site non stop c'est juste une charge trop lourde. Donc on doit leur balancer une erreur 429 : Too Many Requests. Ça, c'est géré par nginx/apache.
Là où ça devient complexe, c'est que le bot qui reçoit une 429 et se calme dans la foulée est OK, mais il y en a qui vont continuer à frapper à la porte non-stop (ouais, les bots, c'est aussi cons que leurs concepteurs) et ces requêtes continuent de peser sur nginx. Donc à un moment : trop de 429 sur une ip = ban par le firewall. Pour le bot ce sera comme si le serveur était tombé. Là dessus, je serais d'avis de bannir 24h. Faut pas pousser. Mais aussi d'analyser si on a certains qui abusent toutes les 24h => ils passent dans la liste à virer.
Maiiiiis ça veut aussi dire, très certainement, questionner ce qu'on fait de Google et Bing (entre autre). Et vu ce que dit blablalinux, sans doute des instances Searx. Est-ce qu'on souhaite les bannir définitivement si elles se comportent mal ? Est-ce qu'on les met dans un set spécial "vous êtes des chieuses, mais on vous autorise à l'être entre minuit et 2h du matin pour alimenter vos index et qu'on nous trouve" ?
Concernant le partage des IP bannies à long terme, mon idée est la suivante :
- Sur chaque serveur, quand Reaction banni une ip, cela alimente un fichier de log avec la raison (et la durée).
- Ces logs sont envoyés à un serveur central (une fois par jour ?)
- Ils sont analysés avec un script bash, histoire de voir les ips qui reviennent, encore et encore, ou bien celles dont les "raisons" justifient un ban à long terme. Les ips sont amalgamé, si cela concerne des plages, on se contente de la plage. On publie alors sur ce serveur central notre liste d'ip bannies (en mode API idéalement, mais ce sera ptet plus basique) et nos autres serveurs viennent se servir pour alimenter leur set "banni à long terme".
C'est assez basique. Très probablement, je pourrais utiliser la même logique dans les deux cas : les logs accessibles en lecture via le web (oui, *peut-être* derrière une api, ou pas), et des processus internes pour en faire un truc. Avec mes connaissances actuelles, ça serait wget+bash mais les devs auront ptet plus pertinent à proposer.
Dernier message par deed - 28 Juin 2026 à 20:07:07
Cliquez pour afficher le message
mise à jour du script
https://joplin.blablalinux.be/shares/SDdcZYIFiccbk7MSe807PE
si quelqu'un veut donner son avis ??
(c'est du home en vdsl)
https://joplin.blablalinux.be/shares/SDdcZYIFiccbk7MSe807PE
si quelqu'un veut donner son avis ??
(c'est du home en vdsl)
Dernier message par YannK - 28 Juin 2026 à 10:45:11
Cliquez pour afficher le message
Je propose donc, avec « caz » pour indiquer le fait qu'on parle d'un service du jeu et ensuite soit du français soit du latin, soit du lojban/khanatien :
- Le gestionnaire de comptes : caz_clef (Contrôleur de Liaison Externe par Fiche)
- Le gestionnaire d'un monde : caz_khanat (car ça gère un monde du khaganat)
- Le gestionnaire de joueuses : caz_joueuses (car c'est pour gérer les joueuses)
- Le gestionnaire de position : caz_locus (Localisation Organisée par Coordonnées Universelles et Supervisées)
- Le gestionnaire de communication : caz_kom (terme khanatien)
- Le gestionnaire de vue des logs pour les admins : caz_oeil (car terme khanatien)
- Le gestionnaire de comptes : caz_clef (Contrôleur de Liaison Externe par Fiche)
- Le gestionnaire d'un monde : caz_khanat (car ça gère un monde du khaganat)
- Le gestionnaire de joueuses : caz_joueuses (car c'est pour gérer les joueuses)
- Le gestionnaire de position : caz_locus (Localisation Organisée par Coordonnées Universelles et Supervisées)
- Le gestionnaire de communication : caz_kom (terme khanatien)
- Le gestionnaire de vue des logs pour les admins : caz_oeil (car terme khanatien)
Dernier message par Zatalyz - 27 Juin 2026 à 11:57:28
Cliquez pour afficher le message
Pourquoi pas, ce genre de nom est effectivement sympa, après pas grave si t'as pas les acronymes. Je préfère LOCUS à SITE.
Mais bon, je ne serais pas contre aussi être bien plus basique ; ces noms sont utilisés sans cesse et moins on a besoin de se référer à un "traducteur" plus ce sera simple non ?
Actuellement je serais plutôt en faveur de garder un préfixe pour dire "c'est un service" (et là, le mot lojban en vaut un autre), puis un terme en anglais, français voir latin. Je note "différencier service et sous-routine", ceci dit, c'est pas bête, donc je limite en anglais, tout en me disant qu'on peut varier les langues en mode "pas d'impérialisme". La nécessité des acronymes me laisse froide, je sais que c'est un jeu classique de français mais bon, y'a un moment, ça demande de bien trop se torturer la tête vu l'enjeu.
- Le gestionnaire de comptes : caz_clef (la clef ça m'a plu)
- Le gestionnaire d'un monde : caz_khanat (doit-je vous rappeler qu'un monde est *forcément* un khanat dans notre optique, et qu'on les agglomère dans le Khaganat ?
Ok, c'est mongol, pas français ni lojban, pas anglais non plus ceci dit). Atlas, bon, pourquoi pas, mais je sens la confusion avec la position.
- Le gestionnaire de joueuses : caz_player, honnêtement ça irait bien, c'est compréhensible. caz_prenu ("personne" en lojban) si je re-craque sur le lojban, ou une mention du fait de rêver mais j'ai pas en mode épicène-fr. C'est notre gestionnaire de rêveuse non ?
- Le gestionnaire de position : j'aime pas du tout "SITE", ça va confusionner avec le web. Locus, par contre, est assez sympa, et on a ainsi un peu de latin pour faire plaisir à tout le monde
. caz_locus ?
- Le gestionnaire de communication : caz_kom, si si (mais ok, Parole était mignon aussi).
- Le gestionnaire de vue des logs pour les admins : caz_Oeil , en référence au fait que justement en cas de souci, on peut activer dans le khanat une surveillance plus complète sur une zone, appelée "l'œil de la Reine Rouge" (je me rends d'ailleurs compte qu'on ne semble pas l'avoir vraiment détaillé sur le wiki)
Et Alea a raison, on ne va ptet pas y passer des années ; au final ce sera celui qui fait qui aura le dernier mot, quoi qu'il arrive ce sera utilisable
Mais bon, je ne serais pas contre aussi être bien plus basique ; ces noms sont utilisés sans cesse et moins on a besoin de se référer à un "traducteur" plus ce sera simple non ?
Actuellement je serais plutôt en faveur de garder un préfixe pour dire "c'est un service" (et là, le mot lojban en vaut un autre), puis un terme en anglais, français voir latin. Je note "différencier service et sous-routine", ceci dit, c'est pas bête, donc je limite en anglais, tout en me disant qu'on peut varier les langues en mode "pas d'impérialisme". La nécessité des acronymes me laisse froide, je sais que c'est un jeu classique de français mais bon, y'a un moment, ça demande de bien trop se torturer la tête vu l'enjeu.
- Le gestionnaire de comptes : caz_clef (la clef ça m'a plu)
- Le gestionnaire d'un monde : caz_khanat (doit-je vous rappeler qu'un monde est *forcément* un khanat dans notre optique, et qu'on les agglomère dans le Khaganat ?
Ok, c'est mongol, pas français ni lojban, pas anglais non plus ceci dit). Atlas, bon, pourquoi pas, mais je sens la confusion avec la position.- Le gestionnaire de joueuses : caz_player, honnêtement ça irait bien, c'est compréhensible. caz_prenu ("personne" en lojban) si je re-craque sur le lojban, ou une mention du fait de rêver mais j'ai pas en mode épicène-fr. C'est notre gestionnaire de rêveuse non ?
- Le gestionnaire de position : j'aime pas du tout "SITE", ça va confusionner avec le web. Locus, par contre, est assez sympa, et on a ainsi un peu de latin pour faire plaisir à tout le monde
. caz_locus ?- Le gestionnaire de communication : caz_kom, si si
(mais ok, Parole était mignon aussi).- Le gestionnaire de vue des logs pour les admins : caz_Oeil , en référence au fait que justement en cas de souci, on peut activer dans le khanat une surveillance plus complète sur une zone, appelée "l'œil de la Reine Rouge" (je me rends d'ailleurs compte qu'on ne semble pas l'avoir vraiment détaillé sur le wiki)
Et Alea a raison, on ne va ptet pas y passer des années ; au final ce sera celui qui fait qui aura le dernier mot, quoi qu'il arrive ce sera utilisable
Dernier message par YannK - 25 Juin 2026 à 20:45:36
Cliquez pour afficher le message
C'est vrai que la facilité de repérage et de prononciation seraient tout de même à prendre en compte, Alea a raison.
Et , à y repenser, j'aimerais bien continuer sur ce qu'avait esquissé Osquallo pour le client, alors je vous propose :
J'ai préféré des termes en français/latin pour les acronymes, car comme ça on identifiera bien le service d'éventuelle sous-routines qui, elles, auront des termes de code donc en anglais.
Et , à y repenser, j'aimerais bien continuer sur ce qu'avait esquissé Osquallo pour le client, alors je vous propose :
- Le gestionnaire de comptes : Contrôleur de Liaison Externe par Fiche -> CLEF
- Le gestionnaire d'un monde : Archictecture Territoriale des Lieux A... et des Systèmes -> ATLAS
- Le gestionnaire de joueuses : ... Entités ...
- Le gestionnaire de position : Système d'Indexation Topologique E... -> SITE ou Localisation Organisée par Coordonnées U... Supervisées -> LOCUS
- Le gestionnaire de communication : Protocole d'Acheminement, de Réception, d'Orientation Linguistique E... -> PAROLE
- Le gestionnaire de vue des logs pour les admins : Logiciel d'Observation, d'Unification, de Persistance et d'Exploration -> LOUPE
J'ai préféré des termes en français/latin pour les acronymes, car comme ça on identifiera bien le service d'éventuelle sous-routines qui, elles, auront des termes de code donc en anglais.
Dernier message par aleajactaest - 18 Juin 2026 à 22:08:06
Cliquez pour afficher le message
Et voilà mon avis,
oui, j'ai un petit faible pour le latin.
Bon, il faudrait éviter des noms que l'on n'arrive pas à prononcer facilement en Français. En cas de problème, les échanges verbales risques d'être compliqué.
De plus il faut aussi éviter des mots qui se ressemble pour exactement le même problème de communication.
Exemple à ne pas reproduire :
* mumutimuti : pour le compte
* mutimumuti : pour la position
* mumutitimu : pour joueur
* timutimumu : pour le monde
* timumutimu : pour la communication
* timumumuti : pour la log
courrage ... quand on aura un problème ...
sinon, le latin n'étant plus parlé, il y a moins de blocage.
mais on pourait utiliser le nom des dieux anciens (égyptien : Ra, Grec : Athena, Romain : Zeus, "Nordique": Thor, ...).
on devrait ainsi éviter des grosses polémiques (enfin j'espère) qui peut polluer la raison réelle de l'objectif (à savoir avancer sur le jeux).
oui, j'ai un petit faible pour le latin.
Bon, il faudrait éviter des noms que l'on n'arrive pas à prononcer facilement en Français. En cas de problème, les échanges verbales risques d'être compliqué.
De plus il faut aussi éviter des mots qui se ressemble pour exactement le même problème de communication.
Exemple à ne pas reproduire :
* mumutimuti : pour le compte
* mutimumuti : pour la position
* mumutitimu : pour joueur
* timutimumu : pour le monde
* timumutimu : pour la communication
* timumumuti : pour la log
courrage ... quand on aura un problème ...
sinon, le latin n'étant plus parlé, il y a moins de blocage.
mais on pourait utiliser le nom des dieux anciens (égyptien : Ra, Grec : Athena, Romain : Zeus, "Nordique": Thor, ...).
on devrait ainsi éviter des grosses polémiques (enfin j'espère) qui peut polluer la raison réelle de l'objectif (à savoir avancer sur le jeux).
Dernier message par YannK - 14 Juin 2026 à 17:03:05
Cliquez pour afficher le message
Citation de: Zatalyz le 14 Juin 2026 à 13:09:01Pour quelle raison, ab, au fait ?Alea aime bien le latin je pense
J'aime bien l'idée du préfixe, ça permet de bien reconnaître les services. Avec le préfixe, ça ferait:
- compte = cazdatni
- position = cazstuzi
- joueurs = cazpilno
- monde = cazmunje
- communication = cazkom
- logs = cazvreji
Citation de: Zatalyz le 14 Juin 2026 à 13:09:01Après, c'est sans doute aussi bien de garder un nom en anglais qui sera plus compréhensible ?Je trouverais sympa d'avoir des noms pas anglais exprès. Déjà qu'on code en anglais, on pourrait ainsi limiter l'impérialisme linguistique
.
Dernier message par deed - 14 Juin 2026 à 14:10:06
Cliquez pour afficher le message
compte = kompte
position = kou
joueurs = konne
monde = komde
communication = kom
logs = kogs
Deed sort loin , très loin .... plus là ...
position = kou
joueurs = konne
monde = komde
communication = kom
logs = kogs
Deed sort loin , très loin .... plus là ...
