English version

Symptoms : notification mails are not sent (but subscription notifications are).
Diagnosis : There are multiple causes that can be explained here : blogs.technet.com/b/steve_chen. But in my case, it was different.
Solution : Here I’m talking about a very specific case. Consider a farm consisting of 4 servers: 1 SQL Server, 1 admin server, one intranet front-end server and one front-end server in the DMZ for extranet.
What you should know is that shipments of alerts are managed by a single server (as opposed to what we see in « Central Administration> Operations> Timer Job Status »).
To find out which server handles alerts’ shipments, launch this SQL request on any content database :

select * from TimerLock

This query will return a server name : this is the one who sends the alerts.
NB: Unlike subscription mails that – I think – are sent by the administration server.
So for some unknown reason, the Intranet server that manages the sending of these messages has stopped doing it, and suddenly it’s the front DMZ that has taken over. But since he was not at all set up for it (firewall, etc.)., alerts were not sent anymore.
Thus, to assign new shipments alert to the other front, you must disable the service timer on the current one:

NET STOP "Windows SharePoint Services Timer"

And finally, the front intranet will resume over.

Article en français

Symptômes : Les mails d’alerte ne sont plus envoyés (mais les notifications d’abonnement elles, sont bien envoyées).
Diagnostique : Les causes sont multiples. Cet article en parle très bien.
Solution : Ici je vais parler d’un cas bien spécifique. Prenons une ferme composée de 4 serveurs : 1 SQL Server, 1 serveur d’administration, 1 serveur frontal intranet et 1 serveur frontal en DMZ pour l’extranet.
Ce qu’il faut savoir, c’est que les envois d’alertes sont gérés par un seul serveur (contrairement à ce qu’on peut voir dans « Administration centrale > Opérations > Etat du travail du minuteur »). Ceci est bien expliqué ici.
Pour savoir quel serveur gère les envois d’alertes, il faut consulter le verrou actif sur le minuteur :

select * from timerlock

(à lancer sur n’importe quelle BDD de contenu, ou du moins celle dont le site refuse d’envoyer les alertes).
Cette requête va renvoyer un nom de serveur : c’est celui-ci qui s’occupe d’envoyer les alertes.
NB : Contrairement au mail de notification d’abonnement qui – je pense – est envoyé par le serveur d’administration.
Donc pour une raison inconnue, le serveur Intranet qui gérait l’envoi de ces mails a cessé de le faire, et du coup c’est le frontal en DMZ qui a pris le relais. Mais vu qu’il n’était pas du tout configuré pour cela (pare-feu, etc.), les alertes n’étaient plus envoyées.
Ainsi, pour confier de nouveau les envois d’alertes à un l’autre frontal, il faut désactiver le service timer sur celui en cours :

NET STOP "Windows SharePoint Services Timer"

Et finalement, le frontal intranet reprendra le relais.