SELECT i.id, i.chépaquoi, ..., u.id, u.nom, u.service // u. et i. permettent de dire de quelle table provient le champ
FROM user u, incident i // on retrouve ici u et i comme alias des tables, mais tu peux mettre ce que tu veux comme nom, voire utiliser directement user. et incident. :)
WHERE u.service = '$service' // uniquement pour les utilisateurs du service que tu recherches
AND u.nom = i.signale_par // et uniquement les incidents signalés par ces utilisateurs

Pourquoi se compliquer la tache avec des sous requêtes et des jointures,

Dans la mesure du possible, utilisez toujours un opérateur de jointure normalisé Sql2 (mot clef JOIN).

En effet :
* Les jointures faites dans la clause WHERE (ancienne syntaxe de 1986 !) ne permettent pas de faire la distinction de prime abord entre ce qui relève du filtrage et ce qui relève de la jointure.
* Il est à priori absurde de vouloir filtrer dans le WHERE (ce qui restreint les données du résultat) et de voiloir "élargir" ce résultat par une jointure dans la même clause WHERE de filtrage.
* La lisibilité des requêtes est plus grande en utilisant la syntaxe à base de JOIN, en isolant ce qui est du filtrage et de la jointure, mais aussi en isolant avec clarté chaque condition de jointures entre chaque couples de table.
* L'optimisation d'exécution de la requête est souvent plus pointue du fait de l'utilisation du JOIN.
* Lorsque l'on utilise l'ancienne syntaxe et que l'on supprime la clause WHERE a des fins de tests, le moteur SQL réalise le produit cartésiens des tables ce qui revient la plupart du temps à mettre à genoux le serveur !

* L'optimisation d'exécution de la requête est souvent plus pointue du fait de l'utilisation du JOIN.

"déclaré par" correspond a un nom de user.