Je voulais désactiver toutes les intégrations d’IA sur mon site, et je suis vraiment ravi que cela ne nécessite qu’un seul paramètre. Une réponse à la question de l’OP pourrait être l’équivalent de discourse_ai_enabled, mais appliqué au niveau de chaque utilisateur. Ainsi, l’IA ne serait pas simplement activée ou désactivée pour l’ensemble du site. Même les fonctionnalités d’IA activées au niveau du site pourraient être supprimées au niveau de chaque utilisateur. La logique de discourse_ai_enabled serait alors : site-wide == true et per-user == true.
Bien qu’il soit généralement vrai que l’équipe réfléchisse à l’ajout de nouveaux paramètres de personnalisation pour éviter une complexité inutile, l’IA est la fonctionnalité disposant du plus grand nombre de paramètres configurables. En très peu de temps depuis son apparition, elle semble être devenue la fonctionnalité la plus personnalisable de Discourse.[1]
Voici une analyse rapide et approximative. Je suis relativement nouveau ici, je montre donc mes calculs au cas où j’aurais fait une erreur.
su discourse -c 'bundle exec rails runner "SiteSetting.defaults.all.keys.sort.each { |k| puts k }"' > keys.txt
wc -l keys.txt
1663 keys.txt
cut -d _ -f 1 keys.txt | sort | uniq -c | sort -rn > counts.txt
Si c’est la bonne méthode pour les compter, il existe 1663 paramètres de site possibles. Parmi ceux-ci, 104 commencent par ai_ et 3 paramètres d’IA ne le font pas (composer_ai_helper_allowed_groups, discourse_ai_enabled et post_ai_helper_allowed_groups). Ainsi, selon mon estimation, l’IA constitue le plus grand groupe de paramètres personnalisés de loin (107 sur 1663, soit 6,4 % de tous les paramètres de site). Voici le top 10 :
- 107 ai
- 84 discourse
- 83 chat
- 71 max
- 65 enable
- 48 default
- 30 dfp
- 28 oauth2
- 28 amazon
- 28 allow
D’un côté, la suppression des fonctionnalités d’IA au niveau de chaque utilisateur n’est qu’une option supplémentaire parmi 1663. De l’autre, il pourrait être difficile de vérifier ce paramètre au niveau de chaque utilisateur alors que de nombreux chemins de code le vérifient au niveau du site. C’est un compromis sur lequel je ne suis pas qualifié pour émettre des hypothèses.
C’est également une fonctionnalité assez bien définie et autonome, et relativement récente, ce qui rend son nommage cohérent avec le préfixe
ai_et facilite le comptage de ses paramètres par rapport à d’autres composants. C’est pourquoi je qualifie cette analyse de rapide et approximative. ↩︎