Derniers messages
Dernier message par Zatalyz - 05 Juin 2026 à 10:39:39
Cliquez pour afficher le message
Concernant la productivité, le coût des IA etc, j'ai eu une discussion assez intéressante avec Daeldir récement (notre premier sysadmin sur le projet, qui est un sacré huluberlu côté rapport à l'informatique et au monde, pour celles qui ne le connaissent pas).
Sa théorie (je résume comme je peux) est que le vibe coding est en réalité vraiment un truc de process industriel, absolument adaptée à cet univers. C'est à dire que l'industrie, depuis longtemps, se justifie en produisant, beaucoup, trop, tout le temps, même au niveau du code, ajoutant toujours plus de surcouches pour auto-justifier la-dite production (le célèbre code spaghetti). Jusqu'à il y a peu, on confiait le job à des devs incompétents ou désabusés (les quelques passionnés embauchés là-dedans essayant de survivre comme ils peuvent), qu'on remplace par des LLM qui font aussi "mal". Et... ben ça va très très bien dans les process industriels, ça répond à leur logique. Le KISS ? trop efficace, donc pas rentable. Il faut justifier la "valeur" par de la "masse", peu importe pour "quoi". Evidement c'est Daeldir, ça allait plus loin, je résume à très gros traits.
Voilà, ça n'apporte rien à la discussion directement, mais j'ai trouvé cette discussion assez parlante pour comprendre à la fois cette question de "productivité", et pourquoi il y a peu de chance que les LLM disparaissent du jour au lendemain si cette logique est en tant soit peu fondée. Ouais, clairement, on ne veux pas être productif
Sa théorie (je résume comme je peux) est que le vibe coding est en réalité vraiment un truc de process industriel, absolument adaptée à cet univers. C'est à dire que l'industrie, depuis longtemps, se justifie en produisant, beaucoup, trop, tout le temps, même au niveau du code, ajoutant toujours plus de surcouches pour auto-justifier la-dite production (le célèbre code spaghetti). Jusqu'à il y a peu, on confiait le job à des devs incompétents ou désabusés (les quelques passionnés embauchés là-dedans essayant de survivre comme ils peuvent), qu'on remplace par des LLM qui font aussi "mal". Et... ben ça va très très bien dans les process industriels, ça répond à leur logique. Le KISS ? trop efficace, donc pas rentable. Il faut justifier la "valeur" par de la "masse", peu importe pour "quoi". Evidement c'est Daeldir, ça allait plus loin, je résume à très gros traits.
Voilà, ça n'apporte rien à la discussion directement, mais j'ai trouvé cette discussion assez parlante pour comprendre à la fois cette question de "productivité", et pourquoi il y a peu de chance que les LLM disparaissent du jour au lendemain si cette logique est en tant soit peu fondée. Ouais, clairement, on ne veux pas être productif
Dernier message par deed - 05 Juin 2026 à 10:00:11
Cliquez pour afficher le message
Alors sur un point précis , ça produit de la basse qualité pour l'instant, ceux qui ont validé du code par LLM , ça passe pour un petite fonction de quelques lignes . Mais plus long, dans la plus part des cas, c'est buggé de folies ou/et très très lent ... Les mainteneurs passent leur temps à debbuger les contribution par LLM .
Ou alors je ne lis que ce qui se plaignent :p
Ou alors je ne lis que ce qui se plaignent :p
Dernier message par alcyone - 05 Juin 2026 à 09:14:42
Cliquez pour afficher le message
CitationCitationLes LLM favorisent la productivitéD'une part, la productivité ce n'est pas forcément un but. D'autre part, l'augmentation de la productivité effective par les LLMs, ça reste à prouver. Dans le développement de code, il semble pour l'instant que ça permet d'écrire et de modifier beaucoup plus de lignes de code beaucoup plus vite, mais finalement pas de créer plus rapidement des nouvelles fonctionnalités. Ce qu'on gagne en temps de développement initial, on le perd en relecture de code ou en debogage des problèmes qui surviennent par la suite.
Oui, c'est tout à fait mal dit, je voulais justement dire qu'ils favorisent le fait de produire : on peut produire très vite une masse de code, factuellement et aussi un état d'esprit dédié à la productivité comme fin en soi, c'est aussi pour cela qu'on les impose et c'est aussi un argument pour beaucoup (que l'on retrouve dans la notion d'être "dépassé"). Ce qui est orthogonal à l'efficience. Avec tous les problèmes pointés après ainsi que dans ton commentaire.
Une reformulation type "Les LLM favorisent la productivité comme fin en soi" est plus claire mais ne me satisfait pas trop trop... N'hésite pas à reformuler dans le pad
CitationJe suis OK sur le principe mais très embêté par l'affirmation non étayée qu'il n'y a pas d'alternative à Linux et à Blender. Je dirais qu'on peut simplement enlever cette parenthèse de la phrase, et qu'il faudra faire un document séparé pour l'analyse des alternatives existantes et de pourquoi elles ne sont pas satisfaisantes.
J'ai étayé au-dessus mais tu as raison, il faudrait le clarifier ainsi, j'ai viré les parenthèses.
Citationje pense que ces deux règles devraient avoir une contrainte de justification. C'est à dire, chaque fois qu'il y a utilisation d'un projet qui utilise des LLM, il faudrait une page de wiki expliquant pourquoi les alternatives ne sont pas adaptées (pour le 3.1) ou ont échoué (pour le 3.2). Ça force au moins à vraiment se poser la question.
Et du reste je suis entièrement de cet avis, aucun élément ne va de soi et cela demande à chaque fois d'expliquer pourquoi, c'est comme ça que je le voyais pour ma part mais je l'ai mal exprimé. Ce que je voulais dire par :
CitationDéjà, faire le point, lister nos dépendances et nos outils actuels, déterminer leur position vis-à-vis de l'usage d'LLM. Trouver des alternatives si elles existent, les créer si nous en trouvons l'énergie. Malheureusement, pour beaucoup ces alternatives n'existent pas vraiment, il nous faudra donc exprimer pourquoi nous déplorons leur positionnement éthique.
_____
CitationBon je vais essayer de faire court (euh... c'est raté...). Je ne participe pas beaucoup à Khaganat par ailleurs, donc ça m'embête un peu de prendre plus que ma part dans cette discussion. La décision à la fin reviendra aux gens qui font vraiment des trucs, et pas à moi qui ne suit que visiteur, en gros. Du coup, je suis OK si tout le monde n'a pas envie de prendre le temps de me lire.
Moi je suis heureux que tu prennes part à la discussion et c'est une contribution en soi
____
Merci Lyne pour ton apport
Citationdonc ça me paraît contre-productif de diaboliser, ostraciser, ou mépriser celles qui, pour tout un tas de raisons, n'iront pas lutter contre le courant. Le plus important me paraît être d'avoir conscience des cas où nous nous écarterons de l'objectif zéro IA, de pourquoi nous le faisons, et de quels efforts nous sommes prêtes (ou pas) à faire pour nous en rapprocher à nouveau.
Je suis d'accord, c'est ce que l'on retrouve dans la proposition de Zat' sur "Quelles que soient leurs motivations, nous souhaitons éviter toute dérive moralisatrice envers les usagères de ces outils dans de tels cas.".
Je tiens à préciser que c'est un compromis qui me convient pour ma part tant que l'on reste dans le cadre "non destiné à produire pour Khaganat directement.".
Dernier message par Lyne - 04 Juin 2026 à 22:56:18
Cliquez pour afficher le message
Compte-rendu du point hebdo du 04/06/2026
YannK
Au niveau du client IRIS, j'ai repris le système de gestion des préférences pour le rendre plus souple à l'avenir et que ça supervise aussi les chemins vers les assets pour éviter au maximum de hardcoder des choses. Maintenant je peux ajouter /effacer des préférences, voire des sections comme je veux, le système les gère proprement dans le fichier sauvegardé. Et j'ai testé par exemple de gérer le fichier d'Atlas des icônes pour l'affichage qui est donc ignorant de l'image qu'il appelle, mais seulement un preset. Une bonne partie de la documentation est faite, il me reste surtout des détails sur certaines méthodes
Je suis aussi pas mal avancé pour mettre en place un fichier qui contiendra des infos techniques (fichier .ini également) afin de faciliter la collecte d'informations pour le débogage (et ça servira aussi à afficher ces infos dans le client si on le souhaite, genre dans l'affichage debug). Je me fais la main avec les infos git, et on verra quoi mettre d'autre par la suite. Mon but n'est pas de tout implémenter tout de suite, mais de poser les bases de l'archi et de tester nos recommandations, nos implémentations envisagées...
À côté de ça, j'ai passé pas mal de temps à reprendre le dépôt de construction (https://port.numenaute.org/khaganat-tools/Docker-files-for-CI) de notre image Docker pour l'export des projets Godot hub.docker.com/r/khaganat/godot-export. Je l'ai repris pour qu'il soit plus facile d'avoir les bons tags sur le hub docker (en plus de latest que j'ai ajouté pour chaque nouvel ajout à venir). L'idée est qu'on ait à changer la version de Godot qu'on veut à un seul endroit et que ça récupère la bonne version de Godot et ses templates, que ça compile et pushe avec ce même tag, le tout tout seul. J'ai encore un peu de boulot pour documenter et nettoyer le dépôt des trucs obsolètes.
Tout ça c'était pour avoir une image docker pour compiler le client IRIS. Et je me suis pas mal battu avec la CI pour arriver à ça. Il y avait plein de soucis avec Git LFS (dont un bug ouvert très complexe à résoudre apparemment) et Godot qui n'aime pas le headless (et moi qui fait des typos, trop de typos
) mais j'ai réussi à trouver une façon de faire pour compiler pour Windows (pas testé) et Linux (testé), en version debug et/ou release. Le workflow est peut-être pas le plus optimisé du monde, mais on ne se sert pas du runner H24 donc je me suis dit OSEF J'ai mis les explications sur le wikhan : https://khaganat.net/wikhan/fr:mmorpg:depot:start#declenchement_de_l_integration_continue
Enfin, sans rapport avec le code, j'ai proposé des modifications pour la charte de non usage des IA sur https://carnets.numenaute.org/p/chartenonusageia
J'ai trouvé des articles assez simples mais très détaillée sur la synchronisation des jeux avec client et serveur autoritaire : https://www.gabrielgambetta.com/client-server-game-architecture.html Je me suis dit que ça allait nous servir avec aleajactaest,
Et la même personne a écrit un autre article sur le pathfinding, qui est plus pour Alea donc : https://www.gabrielgambetta.com/generic-search.html
Zatalyz
De mon côté, j'ai avancé sur la migration du serveur mail. J'ai oublié que j'avais dit que je transférais "comme ça", d'un autre côté c'est pas possible car la syntaxe a changé avec les mises à jour des logiciels, bref... J'avance, et je documente en même temps, je me fais des scripts, tout ça.
ça prends du temps et c'est difficile
je profite aussi du point hebdo pour rappeler : samedi à 21h aura lieu l'AG de Khaganat.
Pensez, en amont, à lire le bilan moral et financier : https://carnets.numenaute.org/p/Khaganat_AG_2026
Il y aura juste à voter si vous validez ou non (la réponse est oui, parce que vous avez encore le temps d'écrire dessus).
Puis élire les Membres du Collège pour 2026.
L'AG se déroulera simultanément sur Mumble (Perroquet, infos sur https://numenaute.org/doc:mumble ) et XMPP (ici).
Nous prévoyons environ 30 minutes, donc soyez à l'heure.
l'AG est ouverte aux non-membres curieuses, mais seules les membres peuvent voter
Alcyone
J'ai ouvert et un peu fourni le sujet de forum ci dessus relative à une charte LLM chez Khaganat (https://khaganat.net/forum/index.php/topic,821)
Je mettrais à jour le bilan moral dans la journée samedi avec les derniers "qui a fait quoi"
Pensez à tout lire en avance et à tester au moins le son sur le Mumble histoire de pouvoir suivre même si on fait le lien avec l'écrit ici :-)
Je note aussi que FrancoisA a fait pas mal de petites corrections de pages par-ci par-là
Lyne
J'ai mis ma bafouille sur les LLM
(Qui n'apporte rien de fondamentalement nouveau, mais au moins vous avez mon avis)
Et j'ai relu le pad (j'avoue, j'ai un peu survolé la partie technique. Désolée pour le boulot fait par Locynaeh)
Et je n'ai même pas besoin de rappeler que l'AG est après-demain, puisque ça a déjà été fait :-)
K'Deed
j'ai fait plein de mise à jour
YannK
Au niveau du client IRIS, j'ai repris le système de gestion des préférences pour le rendre plus souple à l'avenir et que ça supervise aussi les chemins vers les assets pour éviter au maximum de hardcoder des choses. Maintenant je peux ajouter /effacer des préférences, voire des sections comme je veux, le système les gère proprement dans le fichier sauvegardé. Et j'ai testé par exemple de gérer le fichier d'Atlas des icônes pour l'affichage qui est donc ignorant de l'image qu'il appelle, mais seulement un preset. Une bonne partie de la documentation est faite, il me reste surtout des détails sur certaines méthodes
Je suis aussi pas mal avancé pour mettre en place un fichier qui contiendra des infos techniques (fichier .ini également) afin de faciliter la collecte d'informations pour le débogage (et ça servira aussi à afficher ces infos dans le client si on le souhaite, genre dans l'affichage debug). Je me fais la main avec les infos git, et on verra quoi mettre d'autre par la suite. Mon but n'est pas de tout implémenter tout de suite, mais de poser les bases de l'archi et de tester nos recommandations, nos implémentations envisagées...
À côté de ça, j'ai passé pas mal de temps à reprendre le dépôt de construction (https://port.numenaute.org/khaganat-tools/Docker-files-for-CI) de notre image Docker pour l'export des projets Godot hub.docker.com/r/khaganat/godot-export. Je l'ai repris pour qu'il soit plus facile d'avoir les bons tags sur le hub docker (en plus de latest que j'ai ajouté pour chaque nouvel ajout à venir). L'idée est qu'on ait à changer la version de Godot qu'on veut à un seul endroit et que ça récupère la bonne version de Godot et ses templates, que ça compile et pushe avec ce même tag, le tout tout seul. J'ai encore un peu de boulot pour documenter et nettoyer le dépôt des trucs obsolètes.
Tout ça c'était pour avoir une image docker pour compiler le client IRIS. Et je me suis pas mal battu avec la CI pour arriver à ça. Il y avait plein de soucis avec Git LFS (dont un bug ouvert très complexe à résoudre apparemment) et Godot qui n'aime pas le headless (et moi qui fait des typos, trop de typos
) mais j'ai réussi à trouver une façon de faire pour compiler pour Windows (pas testé) et Linux (testé), en version debug et/ou release. Le workflow est peut-être pas le plus optimisé du monde, mais on ne se sert pas du runner H24 donc je me suis dit OSEF J'ai mis les explications sur le wikhan : https://khaganat.net/wikhan/fr:mmorpg:depot:start#declenchement_de_l_integration_continueEnfin, sans rapport avec le code, j'ai proposé des modifications pour la charte de non usage des IA sur https://carnets.numenaute.org/p/chartenonusageia
J'ai trouvé des articles assez simples mais très détaillée sur la synchronisation des jeux avec client et serveur autoritaire : https://www.gabrielgambetta.com/client-server-game-architecture.html Je me suis dit que ça allait nous servir avec aleajactaest,
Et la même personne a écrit un autre article sur le pathfinding, qui est plus pour Alea donc : https://www.gabrielgambetta.com/generic-search.html
Zatalyz
De mon côté, j'ai avancé sur la migration du serveur mail. J'ai oublié que j'avais dit que je transférais "comme ça", d'un autre côté c'est pas possible car la syntaxe a changé avec les mises à jour des logiciels, bref... J'avance, et je documente en même temps, je me fais des scripts, tout ça.
ça prends du temps et c'est difficile
je profite aussi du point hebdo pour rappeler : samedi à 21h aura lieu l'AG de Khaganat.
Pensez, en amont, à lire le bilan moral et financier : https://carnets.numenaute.org/p/Khaganat_AG_2026
Il y aura juste à voter si vous validez ou non (la réponse est oui, parce que vous avez encore le temps d'écrire dessus).
Puis élire les Membres du Collège pour 2026.
L'AG se déroulera simultanément sur Mumble (Perroquet, infos sur https://numenaute.org/doc:mumble ) et XMPP (ici).
Nous prévoyons environ 30 minutes, donc soyez à l'heure.
l'AG est ouverte aux non-membres curieuses, mais seules les membres peuvent voter
Alcyone
J'ai ouvert et un peu fourni le sujet de forum ci dessus relative à une charte LLM chez Khaganat (https://khaganat.net/forum/index.php/topic,821)
Je mettrais à jour le bilan moral dans la journée samedi avec les derniers "qui a fait quoi"
Pensez à tout lire en avance et à tester au moins le son sur le Mumble histoire de pouvoir suivre même si on fait le lien avec l'écrit ici :-)
Je note aussi que FrancoisA a fait pas mal de petites corrections de pages par-ci par-là
Lyne
J'ai mis ma bafouille sur les LLM
(Qui n'apporte rien de fondamentalement nouveau, mais au moins vous avez mon avis)
Et j'ai relu le pad (j'avoue, j'ai un peu survolé la partie technique. Désolée pour le boulot fait par Locynaeh)
Et je n'ai même pas besoin de rappeler que l'AG est après-demain, puisque ça a déjà été fait :-)
K'Deed
j'ai fait plein de mise à jour
Dernier message par pulkomandy - 04 Juin 2026 à 22:43:20
Cliquez pour afficher le message
Bon c'était pas assez long, j'en rajoute...
Je relis le pad.
Les trucs qui m'embêtent sont dans la première partie 'Charte "(non)-usage de l'IA"' dont je ne sais pas ce qu'elle va devenir (à jeter? article de blog explicatif pour la charte?). Dans la deuxième version "Rapport aux LLM et à l'IA au sein de Khaganat" je pense que ces remarques sont déjà prises en compte.
D'une part, la productivité ce n'est pas forcément un but. D'autre part, l'augmentation de la productivité effective par les LLMs, ça reste à prouver. Dans le développement de code, il semble pour l'instant que ça permet d'écrire et de modifier beaucoup plus de lignes de code beaucoup plus vite, mais finalement pas de créer plus rapidement des nouvelles fonctionnalités. Ce qu'on gagne en temps de développement initial, on le perd en relecture de code ou en debogage des problèmes qui surviennent par la suite.
Je suis OK sur le principe mais très embêté par l'affirmation non etayée qu'il n'y a pas d'alternative à Linux et à Blender. Je dirais qu'on peut simplement enlever cette parenthèse de la phrase, et qu'il faudra faire un document séparé pour l'analyse des alternatives existantes et de pourquoi elles ne sont pas satisfaisantes.
Je relis le pad.
Les trucs qui m'embêtent sont dans la première partie 'Charte "(non)-usage de l'IA"' dont je ne sais pas ce qu'elle va devenir (à jeter? article de blog explicatif pour la charte?). Dans la deuxième version "Rapport aux LLM et à l'IA au sein de Khaganat" je pense que ces remarques sont déjà prises en compte.
CitationLes LLM favorisent la productivité
D'une part, la productivité ce n'est pas forcément un but. D'autre part, l'augmentation de la productivité effective par les LLMs, ça reste à prouver. Dans le développement de code, il semble pour l'instant que ça permet d'écrire et de modifier beaucoup plus de lignes de code beaucoup plus vite, mais finalement pas de créer plus rapidement des nouvelles fonctionnalités. Ce qu'on gagne en temps de développement initial, on le perd en relecture de code ou en debogage des problèmes qui surviennent par la suite.
CitationMalheureusement, pour beaucoup ces alternatives n'existent pas vraiment (noyau Linux, Blender, etc.), il nous faudra donc exprimer pourquoi nous déplorons leur positionnement éthique.
Je suis OK sur le principe mais très embêté par l'affirmation non etayée qu'il n'y a pas d'alternative à Linux et à Blender. Je dirais qu'on peut simplement enlever cette parenthèse de la phrase, et qu'il faudra faire un document séparé pour l'analyse des alternatives existantes et de pourquoi elles ne sont pas satisfaisantes.
Dernier message par pulkomandy - 04 Juin 2026 à 22:28:59
Cliquez pour afficher le message
Bon je vais essayer de faire court (euh... c'est raté...). Je ne participe pas beaucoup à Khaganat par ailleurs, donc ça m'embête un peu de prendre plus que ma part dans cette discussion. La décision à la fin reviendra aux gens qui font vraiment des trucs, et pas à moi qui ne suit que visiteur, en gros. Du coup, je suis OK si tout le monde n'a pas envie de prendre le temps de me lire.
Je précise un peu les choses sur les chapitres 3.1 et 3.2. J'ai pris l'exemple de Haiku pour le 3.1 parce que ça me concerne un peu personellement. Mais c'était juste un exemple et effectivement Haiku n'est probablement pas prêt pour Khaganat (pas d'accélération 3D, drivers son pas tout à fait au point, et plein d'autres problèmes qui finissent par transformer n'importe qui qui essaie d'utiliser Haiku en développeur de système d'exploitation).
Le point était juste que Haiku (ou les systèmes BSD, ou d'autres) n'ont même pas été envisagés sérieusement, même si c'est pour les rejeter.
Vu tous les problèmes (principalement écologiques pour moi, mais chacune peut prendre les problèmes qui l'embêtent le plus) avec les LLM, je pense que ces deux règles devraient avoir une contrainte de justification. C'est à dire, chaque fois qu'il y a utilisation d'un projet qui utilise des LLM, il faudrait une page de wiki expliquant pourquoi les alternatives ne sont pas adaptées (pour le 3.1) ou ont échoué (pour le 3.2). Ça force au moins à vraiment se poser la question.
Bon, c'est du travail en plus. Mais ça permettrait au moins de savoir où on en est, et pour les gens qui tiennent absolument à rendre possible un monde sans LLM, de savoir à quels projets s'attaquer en priorité pour construire des alternatives acceptables.
Deuxième point, je vois deux choses un peu différentes: l'utilisation de LLM par les contributeurs du projet, et par des contributeurs externes (par exemple quelqu'un qui sortirait de nulle part avec une liste de failles de sécurité). Dans ce deuxième cas, il y a effectivement un risque de "flood" et d'être submergé par des propositions de mauvaise qualité.
Ça demande de mettre en place de quoi pouvoir dire non à ces contributions, même si c'est appliqué sélectivement (de ce point de vue là, ça n'empêcherait pas d'accepter les contributions de qualités mais faites avec l'aide d'un LLM).
Il y a en fait deux questions là dedans: mettre en place des protections pour ne pas se faire submerger, c'est la moindre des choses. Mais il y a l'autre question qui est de savoir si on veut rejeter en bloc les LLM, par principe, et même si les contributions sont de bonne qualité (pour des raisons écologiques, sociétales, et tout ce qui concerne surtout l'impact des LLMs en dehors du contenu qu'ils génèrent, plutôt que pour le contenu généré en lui-même). Là c'est un vrai choix qui est beaucoup plus sujet à débat. Surtout que on sait très bien que une telle interdiction serait essentiellement symbolique (c'est pas Khaganat qui va utiliser des milliards de tokens d'IA et justifier à lui tout seul la construction de nouveaux datacenters).
Dans ce cas je crois qu'on peut dire que l'utilisation de LLM n'est pas le problème, et qu'il y a un échec collectif qui remonte bien avant pour en arriver là.
Je connecte ça à autre chose d'un peu similaire: il y a des gens qui passent un temps conséquent sur les réseaux sociaux addictifs (TikTok, Instagram, Youtube, ou devant la télé). Cela empêche l'ennui, qui n'est pas un truc agréable, mais qui normalement pousse les gens à se bouger et à faire quelque chose de leur temps. Sans l'ennui, on resterait tous dans notre lit toute la journée à regarder le plafond.
Donc, l'utilisation de LLM contourne la solitude un peu comme les réseaux sociaux contournent l'ennui. Mais ça règle pas le problème et ça peut empirer les choses. Ça rejoint ce que je disais plus tôt sur mes craintes que les LLMs mettent un peu fin aux interactions entre les gens. Plus besoin pour un introverti comme moi d'aller parler aux gens si je peux avoir une réponse d'un LLM. Donc oui, individuellement, ça permet de fonctionner, mais clairement ça ne règle pas le problème... Cela dit, c'est vrai aussi que dans cette réflexion j'envisage aussi d'autres usages des LLMs qui n'ont rien à voir avec Khaganat (par exemple, Google qui prévoit de ne plus mettre de liens vers des sites web dans ses résultats de recherche).
Je lance aussi un autre sujet maintenant que je suis là. Sur le forum de Haiku nous avons fait le choix d'autoriser les gens faisant du "vibe coding" à parler de ce qu'ils font. Je recommande pas: ça donne des sujets de forum avec des avancées très rapides pour le développement d'applications, souvent pour des trucs qui existent déjà par ailleurs, et qui vont très probablement finir par être abandonnés. Faire les choses à la main, c'est plus long et plus difficile, mais ça encourage à suivre les projets sur la durée. Parfois ça me donne l'impression qu'on compare mon petit potager avec quelques légumes et un grand étal de supermarché avec énormément de choix de légumes sans goût et plein de pesticides. Et, forcément, d'un certain point de vue, je peux pas lutter. Dans ces conditions il faut vraiment être prêt à assumer la décroissance...
Je précise un peu les choses sur les chapitres 3.1 et 3.2. J'ai pris l'exemple de Haiku pour le 3.1 parce que ça me concerne un peu personellement. Mais c'était juste un exemple et effectivement Haiku n'est probablement pas prêt pour Khaganat (pas d'accélération 3D, drivers son pas tout à fait au point, et plein d'autres problèmes qui finissent par transformer n'importe qui qui essaie d'utiliser Haiku en développeur de système d'exploitation).
Le point était juste que Haiku (ou les systèmes BSD, ou d'autres) n'ont même pas été envisagés sérieusement, même si c'est pour les rejeter.
Vu tous les problèmes (principalement écologiques pour moi, mais chacune peut prendre les problèmes qui l'embêtent le plus) avec les LLM, je pense que ces deux règles devraient avoir une contrainte de justification. C'est à dire, chaque fois qu'il y a utilisation d'un projet qui utilise des LLM, il faudrait une page de wiki expliquant pourquoi les alternatives ne sont pas adaptées (pour le 3.1) ou ont échoué (pour le 3.2). Ça force au moins à vraiment se poser la question.
Bon, c'est du travail en plus. Mais ça permettrait au moins de savoir où on en est, et pour les gens qui tiennent absolument à rendre possible un monde sans LLM, de savoir à quels projets s'attaquer en priorité pour construire des alternatives acceptables.
Deuxième point, je vois deux choses un peu différentes: l'utilisation de LLM par les contributeurs du projet, et par des contributeurs externes (par exemple quelqu'un qui sortirait de nulle part avec une liste de failles de sécurité). Dans ce deuxième cas, il y a effectivement un risque de "flood" et d'être submergé par des propositions de mauvaise qualité.
Ça demande de mettre en place de quoi pouvoir dire non à ces contributions, même si c'est appliqué sélectivement (de ce point de vue là, ça n'empêcherait pas d'accepter les contributions de qualités mais faites avec l'aide d'un LLM).
Il y a en fait deux questions là dedans: mettre en place des protections pour ne pas se faire submerger, c'est la moindre des choses. Mais il y a l'autre question qui est de savoir si on veut rejeter en bloc les LLM, par principe, et même si les contributions sont de bonne qualité (pour des raisons écologiques, sociétales, et tout ce qui concerne surtout l'impact des LLMs en dehors du contenu qu'ils génèrent, plutôt que pour le contenu généré en lui-même). Là c'est un vrai choix qui est beaucoup plus sujet à débat. Surtout que on sait très bien que une telle interdiction serait essentiellement symbolique (c'est pas Khaganat qui va utiliser des milliards de tokens d'IA et justifier à lui tout seul la construction de nouveaux datacenters).
CitationCe serait aussi peut-être une solution pour briser l'isolement de certaines contributrices. Si je vous dit que j'utilise un LLM ces temps pour avancer sur ce foutu transfert de serveur mail, non pas tant pour les aspects techniques, mais pour juste me sentir moins seule face à la montagne, est-ce que vous allez me faire des pamjais sur krypte et me dire que la personnalisation du footer de postfixadmin est sans intérêt ? Parce que je trouverais ça tellement plus satisfaisant.
Dans ce cas je crois qu'on peut dire que l'utilisation de LLM n'est pas le problème, et qu'il y a un échec collectif qui remonte bien avant pour en arriver là.
Je connecte ça à autre chose d'un peu similaire: il y a des gens qui passent un temps conséquent sur les réseaux sociaux addictifs (TikTok, Instagram, Youtube, ou devant la télé). Cela empêche l'ennui, qui n'est pas un truc agréable, mais qui normalement pousse les gens à se bouger et à faire quelque chose de leur temps. Sans l'ennui, on resterait tous dans notre lit toute la journée à regarder le plafond.
Donc, l'utilisation de LLM contourne la solitude un peu comme les réseaux sociaux contournent l'ennui. Mais ça règle pas le problème et ça peut empirer les choses. Ça rejoint ce que je disais plus tôt sur mes craintes que les LLMs mettent un peu fin aux interactions entre les gens. Plus besoin pour un introverti comme moi d'aller parler aux gens si je peux avoir une réponse d'un LLM. Donc oui, individuellement, ça permet de fonctionner, mais clairement ça ne règle pas le problème... Cela dit, c'est vrai aussi que dans cette réflexion j'envisage aussi d'autres usages des LLMs qui n'ont rien à voir avec Khaganat (par exemple, Google qui prévoit de ne plus mettre de liens vers des sites web dans ses résultats de recherche).
Je lance aussi un autre sujet maintenant que je suis là. Sur le forum de Haiku nous avons fait le choix d'autoriser les gens faisant du "vibe coding" à parler de ce qu'ils font. Je recommande pas: ça donne des sujets de forum avec des avancées très rapides pour le développement d'applications, souvent pour des trucs qui existent déjà par ailleurs, et qui vont très probablement finir par être abandonnés. Faire les choses à la main, c'est plus long et plus difficile, mais ça encourage à suivre les projets sur la durée. Parfois ça me donne l'impression qu'on compare mon petit potager avec quelques légumes et un grand étal de supermarché avec énormément de choix de légumes sans goût et plein de pesticides. Et, forcément, d'un certain point de vue, je peux pas lutter. Dans ces conditions il faut vraiment être prêt à assumer la décroissance...
Dernier message par Lyne - 04 Juin 2026 à 22:06:33
Cliquez pour afficher le message
Je n'ai ni l'énergie ni le temps de faire un long pavé, alors je vais aller à ce qui me paraît essentiel.
La deuxième proposition sur le pad (https://carnets.numenaute.org/p/chartenonusageia) me convient globalement. Sachant qu'elle pourrait encore bouger marginalement, ou dans les formulations, et que je n'ai pas non plus la motivation de recopier sa version à date (04/06/2026). Mais c'est l'idée.
Je me retrouve complètement dans la partie "pas envie d'utiliser de l'IA alors qu'on est dans le projet pour apprendre et échanger entre humains".
Je me retrouve globalement dans la partie "et puis c'est pas ce qu'on a envie de promouvoir comme monde" (le "globalement", c'est sur des questions de formulation plus que sur le fond).
Et comme l'ont dit certaines (j'ai pas les noms en tête), il y a un principe de réalité et nous n'avons pas les moyens (et je ne crois pas que ce soit l'ambition de Khaganat) de changer frontalement le monde (le faire changer subtilement, par petites touches, par contre...) : donc ça me paraît contre-productif de diaboliser, ostraciser, ou mépriser celles qui, pour tout un tas de raisons, n'iront pas lutter contre le courant. Le plus important me paraît être d'avoir conscience des cas où nous nous écarterons de l'objectif zéro IA, de pourquoi nous le faisons, et de quels efforts nous sommes prêtes (ou pas) à faire pour nous en rapprocher à nouveau.
La deuxième proposition sur le pad (https://carnets.numenaute.org/p/chartenonusageia) me convient globalement. Sachant qu'elle pourrait encore bouger marginalement, ou dans les formulations, et que je n'ai pas non plus la motivation de recopier sa version à date (04/06/2026). Mais c'est l'idée.
Je me retrouve complètement dans la partie "pas envie d'utiliser de l'IA alors qu'on est dans le projet pour apprendre et échanger entre humains".
Je me retrouve globalement dans la partie "et puis c'est pas ce qu'on a envie de promouvoir comme monde" (le "globalement", c'est sur des questions de formulation plus que sur le fond).
Et comme l'ont dit certaines (j'ai pas les noms en tête), il y a un principe de réalité et nous n'avons pas les moyens (et je ne crois pas que ce soit l'ambition de Khaganat) de changer frontalement le monde (le faire changer subtilement, par petites touches, par contre...) : donc ça me paraît contre-productif de diaboliser, ostraciser, ou mépriser celles qui, pour tout un tas de raisons, n'iront pas lutter contre le courant. Le plus important me paraît être d'avoir conscience des cas où nous nous écarterons de l'objectif zéro IA, de pourquoi nous le faisons, et de quels efforts nous sommes prêtes (ou pas) à faire pour nous en rapprocher à nouveau.
Dernier message par alcyone - 04 Juin 2026 à 21:14:33
Cliquez pour afficher le message
CitationPour la réponse de Deed : c'est peut-être dommage qu'il n'aie pas tout lu, mais, ben, je préfère que quelqu'un s'exprime sur sa vision même s'il n'a pas tout lu : on a besoin de savoir l'avis des divers membres. Et cette honnêteté me va. Il faut reconnaitre que ça demande pas mal de jus de cerveau, et qu'on le priorise différement. Je rappelle que Deed passe pas mal de temps chaque semaine à la maintenance des serveurs ; qu'après ça il ne soit pas motivé à lire les tartines philosophiques, ça se comprends. Pour autant, vu que c'est un contributeur très actif, son avis sur les LLM est important, parce qu'in fine son approche aura un impact sur son travail (comme pour moi, d'ailleurs).
Le consensus, lui, va demander soit de tout lire, soit de déléguer l'avis aux autres... Par contre c'est clair que quand on en sera à dire "on valide ça ou non comme charte", je n'ai pas envie que quelqu'un se pointe comme une fleur et questionne un truc déjà traité dans les discussions. Mais ça n'a jamais été le problème jusque là.
In fine, c'est aussi ce que je souhaite éviter par ma réaction et l'absence d'échange me pose problème dans ce sens mais comme tu dis, à défaut d'échange, tu délègues à ceux qui le font et si c'est fait consciemment, ça ne me pose pas de problème. Je suis d'accord aussi sur le fait que je préfère avoir un point de vue que pas du tout, toujours dans ce cadre.
C'est bien entendu totalement orthogonal au travail fourni sur d'autres partis du projet bien entendu que je reconnais personnellement et le manifeste au moins de temps à autre dans l'un ou l'autre canal à défaut d'être versé dans le sujet pour y contribuer.
La façon de faire/formulation me rebute surtout mais je ne pense pas que ce soit intentionnel pour autant.
CitationÇa, ce sont des propositions concrètes qui me parlent. S'il y a usage d'IA (comme dans mes usages "palliatifs", et j'espère un meilleur nom), ce serait effectivement intéressant de s'assurer que ce soit clair et documenté. Cela ajoute du travail à qui utilise l'IA, aide potentiellement à une prise de conscience ; cela peut aussi permettre à la communauté de discuter des usages en question, d'essayer de trouver comment s'en passer.
CitationC'est une proposition concrète qui permet de filtrer du "flood IA" de basse qualité. On est typiquement sur un usage qui arrivera, car tous les projets y font face actuellement. Ajouter ces étapes obligatoire (et il peut y en avoir d'autres, à nous de les trouver) est une façon de réduire le "bruit" qui risque d'être généré. D'un autre côté, j'aimerais que ce ne soit pas une invitation à utiliser l'IA sur le code.
Comme je le disais plus haut pour le point 3.2, si l'on fixe que l'usage paliatif est "non destiné à produire pour Khaganat directement" alors ces points précis sous cette forme (commit de notre part) ne devraient pas être mis en place. Si l'on respecte ce point, on rejette le flood IA par défaut, la charte permettant de nous dispenser son analyse si l'on le souhaite (rien n'empêche de discuter pour implémenter une bonne idée autrement bien sûr).
Dans le cas contraire, les chartes accueillant l'IA indiquées dans mon 1er poste détaillent globalement toutes bien ce qu'il y a comme informations à recueillir (modèle, version, soft intermédiaire, historique des prompts, etc. j'avoue les lire tellement souvent (je dois en être à plus d'une centaine je pense...) que j'oublie que certaines n'en ont probablement jamais lu). Et quoiqu'on écrive dans la charte le cas échéant, si on peut mettre de l'IA, tu auras de toute façon du flood derrière si tant est que le projet est un minipeu connu (ce n'est pas notre cas pour le moment). Fixer une limite revient aussi à l'autoriser (on peut même l'automatiser d'ailleurs). Un non définitif n'étant de toute façon pas très bien compris quand ce n'est pas l'éthique qui en arrête l'usage de toute manière.
Si on le prend dans le cadre du point 3.2, alors dans ce cas je pense qu'on se retrouve là-dessus tel que tu le détailles à la fin de ton message :-)
Je m'aperçois que j'avais complètement oublié de te répondre Pulkomandy ! Mes excuses !
Citation de: PulkomandyJe mentionne pour ceux qui ne savent pas, que je contribue beaucoup à Haiku, qui pourrait se positionner comme un concurrent de Linux entre autres choses, et n'a pas recours aux LLM. Je comprend tout à fait que Haiku ne soit pas considéré suffisamment mûr pour les besoins de Khaganat pour la partie client où il serait éventuellement utilisable, mais ça me chagrine un peu que ce soit balayé de façon assez expéditive comme un "pas d'alternative" sans avoir creusé la question plus que ça. Mais là je fais du lobbying pour mes propres intérêts et je comprend tout à fait que ça n'emballe pas tout le monde de se lancer là dedans.
Pour moi, Haiku n'a jamais été sorti des systèmes cibles pour les différentes productions de Khaganat (pour ma part je vois les lores et productions tirées de ces lores par le projets, pas uniquement le MMO basé sur Khanat) et j'ose espérer qu'un maximum de choses pourront y être disponibles. Car on utilise des formats standard, c'est le cas des textes, de la musique ou des productions graphiques (encore que je ne sais pas l'état de la 3D sur Haiku ?).
Là où je pense à une limite au quotidien (qui vaut pour la plupart des concurrents du noyau Linux), c'est la disponibilité des drivers sur nos machines de travail au quotidien. Ça c'est pour toutes ici et honnêtement j'aimerais vraiment que le travail du noyau Linux soit réutilisable afin de faciliter ce point mais j'ai conscience que la quasi-totalité des autres noyaux ont une licence ne le permettant pas directement non plus.
Un autre point, essentiellement spécifique à moi, c'est que je fais aussi de la musique sur l'ordinateur (on dit M.A.O) et là, corrige moi si je ne suis pas à jour (je lis toutes les dépêches linuxfr avec intérêt!) mais il me semble que la partie audio sur Haiku n'est pas encore prête pour cette usage d'une part (priorité au temps réel, compatibilité avec l'existant sur Linux (alsa/jack), ...), d'autre part et de ce fait, il y a peu de portages disponibles de l'existant en logiciel M.A.O.
C'est un point sur lequel je souhaiterais bien que ça évolue mais sur lequel je ne suis pas du tout compétent (je travaille à être compétent sur la maintenance et le portage de certains logiciels/plugins mais c'est ma limite). Je peux apporter mon expérience et mes tests mais je ne peux rien faire de plus pour améliorer tout ça.
Dernier message par deed - 03 Juin 2026 à 22:43:20
Cliquez pour afficher le message
Context, il est auto-hébergé en vdsl avec des ordis de récup et en Belgique.
je suis pour nftables d'ailleurs il faut que je regarde si Proxmox à changer
je suis pour nftables d'ailleurs il faut que je regarde si Proxmox à changer
#10
Général / Re : Bloquer les Bots
Cliquez pour afficher le message
Ha oui, en effet, c'est intéressant.
La logique s'adapte assez facilement avec d'autres techno, docker n'a rien de vital.
Je ne suis pas forcément fan de geoip, mais quand j'avais fait les stats sur mes ip bloquées, on avait clairement quelques zones qui se détachait. Là par exemple, il ne bloque pas les USA, alors qu'ils sont aussi pénibles que la Russie, la Chine et le Brésil. Et par ailleurs tous les serveurs de ces pays ne sont pas à bloquer. Il bloque l'Irlande, sans doute pour AWS, mais du coup sur un serveur qui reçoit des mails des commandes d'Amazon, ça risque d'être un souci. Ok, c'est une façon d'empêcher ses utilisatrices d'utiliser Amazon
Idéalement, il faudrait en réalité repérer les plages d'adresses problématiques (généralement toutes d'un même datacenter), ça c'est plus utile à bloquer, et il y a moins de risque de bloquer un utilisateur légitime. Dans le cas du mail, je sais que j'ajoute en liste autorisé les ip des fournisseurs mails (dont amazon, aliexpress, etc, quand quelqu'un me dit que le mail n'arrive pas).
Mon idée (pas mise en place) était d'avoir un domaine "honeypot" : si une ip le visite (au delà du robots.txt qui dira "allez au diable), vu qu'il ne fournit pas de contenu, n'est pas référencé, etc, l'ip est ajouté à une liste de ban. Un petit cron une fois par jour pour analyser toutes ses ip, en sortir la plage quand ça semble utile, puis l'info est relayée aux autres serveuers : "bloquez la plage d'ip X.X.* pour un bon mois, c'est des fermes de bots !".
Note que le tuto utilise iptables et fail2ban, de mon côté je passe plutôt à nftables et reaction dans ce genre d'usage, la syntaxe est plus simple à gérer (pour reaction) et nftables est puissant.
La logique s'adapte assez facilement avec d'autres techno, docker n'a rien de vital.
Je ne suis pas forcément fan de geoip, mais quand j'avais fait les stats sur mes ip bloquées, on avait clairement quelques zones qui se détachait. Là par exemple, il ne bloque pas les USA, alors qu'ils sont aussi pénibles que la Russie, la Chine et le Brésil. Et par ailleurs tous les serveurs de ces pays ne sont pas à bloquer. Il bloque l'Irlande, sans doute pour AWS, mais du coup sur un serveur qui reçoit des mails des commandes d'Amazon, ça risque d'être un souci. Ok, c'est une façon d'empêcher ses utilisatrices d'utiliser Amazon
Idéalement, il faudrait en réalité repérer les plages d'adresses problématiques (généralement toutes d'un même datacenter), ça c'est plus utile à bloquer, et il y a moins de risque de bloquer un utilisateur légitime. Dans le cas du mail, je sais que j'ajoute en liste autorisé les ip des fournisseurs mails (dont amazon, aliexpress, etc, quand quelqu'un me dit que le mail n'arrive pas).
Mon idée (pas mise en place) était d'avoir un domaine "honeypot" : si une ip le visite (au delà du robots.txt qui dira "allez au diable), vu qu'il ne fournit pas de contenu, n'est pas référencé, etc, l'ip est ajouté à une liste de ban. Un petit cron une fois par jour pour analyser toutes ses ip, en sortir la plage quand ça semble utile, puis l'info est relayée aux autres serveuers : "bloquez la plage d'ip X.X.* pour un bon mois, c'est des fermes de bots !".
Note que le tuto utilise iptables et fail2ban, de mon côté je passe plutôt à nftables et reaction dans ce genre d'usage, la syntaxe est plus simple à gérer (pour reaction) et nftables est puissant.
