Pour l'histoire du "réseaux de neurones", c'est faisable en php.
Déjà, on peut sûrement adapter le systèmes des réseaux de neurones pour en faire quelque chose de plus simple.
Ensuite, même si on se "contente" d'appliquer le principe des réseaux de neurones, il n'est pas obligatoire de lui faire apprendre quoique ce soit à chaque passe. On peut se créer une base de donnée de réponses.
Les problèmes que je vois (sans avoir trop approfondi) :
Actuellement, tu as sûrement une série de if imbriqués, du genre "s'il a répondu ça et ça et ça ou ça et ça, alors répondre ça."
Le problème est qu'avec un tel système, même s'il (semble) fonctionne(r), tu risques tomber sur des cas où ça ne marche plus. Typiquement : il s'agit du cas que tu n'as pas prévu.
Deuxième problème, comme ton système n'apprend rien (= il n'évolue pas), il ne sera pas capable de suivre, automatiquement, les tendances, ni ne gèrera les nouveaux mmorpg, à moins que tu y appliques une maintenance relativement lourde pour toi (d'autant plus qu'il faudra que tu te renseignes sur plein de mmorpg avant de commencer à ajouter une nouvelle branche à ton système).
L'idée de la "base de donnée évolutive" :
En gros, tu ne bases plus tes conseils sur une série de réponses que tu auras fixé, mais tu bases tes conseils sur un ensemble de réponses données par chaque utilisateur de ton programme.
En définitive, tu as une base de donnée, qui peux ressembler à ceci (y'a besoin que d'une (ou deux, si tu veux) table(s) :
Table A (sauvegarde les réponses) :
id BIGINT autoincrement PRIMARYKEY
question_id TINYINT (commentaire : n° de la question répondue)
reponse_donnée TINYINT (ou ENUM, ou ce que tu veux, du moment que cette donnée reste valable pour toutes les questions)
Table B (sauvegarde les mmorpg appréciés ou non) :
mmorpg_id INT
reponse_id BIGINT
note INT (commentaire : égal à une note sur 20)
(mmorpg_id, reponses_id) PRIMARYKEY
(on peux mixer la table A et B : on vire "reponse_id" dans la table B et on met mmorpg_id et note dans la table A)
bon, on peut ajouter une 3e table, pour sauvegarder le nom des mmorpgs :
Table C :
id INT PRIMARYKEY
nom VARCHAR(80)
A partir de là, tu as une liste basée sur les réponses de tous les utilisateurs (donc, d'un point de vue statistique, on peut considérer cela comme étant assez précis = on peut se fier à l'information, à priori).
Pour le conseil que tu vas donner au final, en revanche....
Déjà, tes questions vont se compléter par un tableau à deux dimentions, mmorpg/note :
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
mmorpg 1 x
mmorpg 2 x
mmorpg 3....
qui servira à remplir la table B.
Enfin, j'en viens au conseil que tu donnes, il ne s'agit plus de répondre :
1 - mmorpg X
2 - mmorpg Y
3 - mmorpg Z
mais, il s'agit de répondre, pour chaque mmorpg : "il y a X% de chances que ce mmorpg vous convienne".
Tu bases en fait ta réponse sur le fait qu'il y a déjà eu N personnes ayant répondu à ce questionnaire que que parmis ces N personnes, M ont répondu quelque chose de similaire aux réponses que ton utilisateur vient d'apporter. Le X% étant en fait égal à une moyenne des notes donnée par chacun des M utilisateurs ayant déjà répondu de façon similaire à ce que ton utilisateur vient de répondre.
Voilà, on vient de se passer des réseaux neuromimétiques et on a le même résultat que si on ne s'en était pas passé.
edit: pendant que j'y pense, si on ajoute une 4e table (une table D, on leur donnera évidemment de vrais noms), tu peux même proposer à tes utilisateurs d'ajouter des questions (qui peuvent être sujettes à ta modération, c'est à dire avant d'apparaître dans le questionnaire, tu peux faire en sorte qu'elles doivent être acceptées par toi).
edit 2: pendant que j'y pense 2e édition, on peut aussi donner le choix à un utilisateur de ne pas répondre à certaines questions.
Dans ce cas, au lieu d'avoir des questions de ce genre :
Question 1 - ........ :
x - ....
x - ....
x - ....
x - ....
x - ....
On a quelque chose de ce type :
Question 1 - ........ :
o - Je souhaite répondre.
x - ....
x - ....
x - ....
x - ....
x - ....
o - Je ne souhaite pas répondre.
(avec x = des coches et o = des boutons radio)