Non. Une application générée ici n'envoie ni e-mail, ni SMS, ni notification push — c'est vérifiable dans son paquet livré : aucune des dépendances déclarées n'est un client de messagerie, et le mot de passe provisoire d'un compte créé est affiché UNE fois à l'écran plutôt qu'expédié. Ce qu'elle fait à la place est différent, et souvent suffisant : elle met ce qui est dû devant vous au moment où vous l'ouvrez — un bandeau « en retard » en tête des listes concernées, une cloche et une page de notifications, une vue agenda. Et pour le rappel qui sonne vraiment, elle passe le relais à votre propre calendrier : un bouton « Ajouter au calendrier » remet l'échéance à votre téléphone. Si l'envoi automatique vous est indispensable, le code de l'application est à vous, et un développeur peut l'y ajouter — cette page dit ce que ça implique.
Ce qu'elle n'envoie pas — et comment le vérifier vous-même
Une application produite ici est un projet Next.js et Prisma dont la liste de dépendances est figée et lisible : vingt-deux paquets, quatre outils de développement, et pas un seul client de messagerie, de SMS ou de notification push. Le rendu, la base de données, les cartes, les graphiques, le Markdown y sont ; l'envoi, non. Ce n'est pas une omission qu'on découvre à l'usage, c'est une ligne qui manque dans un fichier que vous pouvez ouvrir : le `package.json` voyage dans l'archive.
Le détail qui le confirme le mieux est ailleurs, et il est plus parlant qu'une liste : quand un administrateur crée un compte pour un collègue, l'application affiche le mot de passe provisoire à l'écran, une seule fois, et ne le renvoie jamais ensuite. Un produit qui savait envoyer un e-mail l'aurait expédié — c'est le premier réflexe de tout logiciel multi-utilisateurs. Ici la consigne est de le recopier et de le transmettre soi-même. La contrainte se voit dès le premier compte créé, elle ne se découvre pas six mois plus tard.
Pourquoi cette absence tient plutôt d'un choix que d'un oubli : envoyer un e-mail ne se résume pas à une ligne de code. Il faut un compte chez un expéditeur, un domaine autorisé à envoyer en votre nom, des enregistrements DNS qui l'attestent, et quelqu'un pour regarder ce qui rebondit. Une application livrée sans ça enverrait des messages qui finissent en indésirables — ce qui est pire que de ne rien envoyer, parce qu'on croit alors que le destinataire a été prévenu.
Ce qu'elle fait à la place : l'échéance vient à vous à l'ouverture
Le principe est inversé : au lieu d'aller chercher l'utilisateur, l'application met en tête ce qui est dû dès qu'il arrive. Quand une entité porte une date d'échéance — une intervention à faire, une facture à encaisser, un contrat qui expire, une tâche datée —, la liste concernée affiche en tête un bandeau qui compte ce qui est en retard, avant le tableau et avant les filtres. La question « qu'est-ce que je dois traiter aujourd'hui ? » trouve sa réponse sans qu'on ait à la chercher.
S'y ajoutent deux surfaces plus classiques. Une cloche dans l'en-tête et une page « Notifications » rassemblent les enregistrements à suivre avec leur statut courant — lus dans vos propres données, jamais dans un journal tenu à part. Et quand le métier s'y prête, une vue agenda affiche les événements à leur place — au jour, à la semaine ou au mois, le mois à l'ouverture — avec, sous la grille, une liste triée des échéances à venir. C'est la même question posée deux fois, pour ceux qui lisent mieux une liste qu'un calendrier.
La limite est réelle et vaut d'être dite : tout cela suppose que quelqu'un ouvre l'application. C'est le bon régime pour un outil qu'on consulte chaque matin — un planning d'atelier, un carnet d'interventions, un suivi de dossiers. C'est le mauvais régime pour une échéance rare et lointaine, du genre « relancer ce client dans onze mois », qu'on ne verra pas si on ne se connecte pas ce jour-là.
Le rappel qui sonne vraiment : passer par votre agenda
C'est exactement le cas que traite le bouton « Ajouter au calendrier ». Sur la fiche d'un enregistrement qui porte une date, l'application fabrique le fichier d'événement standard que tous les agendas savent lire — celui qu'on reçoit en pièce jointe d'une invitation — et votre appareil l'ouvre. L'événement rejoint alors votre calendrier habituel, celui de votre téléphone, d'Outlook ou de Google, et c'est lui qui sonnera, avec le rappel que vous lui avez configuré.
Le partage des rôles est net, et c'est ce qui le rend robuste : l'application tient la donnée métier, votre agenda tient le rappel. Elle n'a pas à savoir à quelle heure vous voulez être prévenu, ni sur quel appareil, ni si vous êtes en congé — tout cela, votre calendrier le sait déjà et le fait mieux. Le bouton n'apparaît d'ailleurs que là où il a du sens : uniquement sur les fiches dont la donnée porte réellement une date.
La contrepartie est honnête : c'est un geste, pas un abonnement. Vous envoyez UN événement à la fois, au moment où vous consultez la fiche ; l'application ne pousse rien d'elle-même et ne tient pas votre agenda à jour si la date change ensuite. Pour une poignée d'échéances qui comptent vraiment, c'est largement suffisant et ça ne dépend d'aucun service tiers. Pour un flux continu de dizaines de rendez-vous par semaine, ce n'est pas le bon outil, et mieux vaut le savoir avant.
Si l'envoi automatique vous est indispensable
Deux chemins existent, et ils ne demandent pas le même effort. Le premier ne touche pas au code : chaque liste porte un bouton d'export qui produit un fichier CSV des lignes affichées — donc filtrées comme vous venez de les filtrer, pas la table entière. Le fichier s'ouvre directement dans un tableur, séparateur et encodage compris, et alimente l'outil qui envoie déjà vos e-mails. Filtrer « en retard », exporter, publiposter : c'est une routine hebdomadaire de cinq minutes, et elle ne crée aucune dépendance nouvelle.
Le second chemin est le vôtre au sens propre : le code de l'application vous appartient, il est récupérable en archive ou sur un dépôt Git, et c'est un projet Next.js et Prisma ordinaire. Ajouter l'envoi d'e-mails y est un travail de développement balisé — brancher un expéditeur, écrire le message, déclencher la tâche. Ce qui coûte n'est pas le code : c'est le domaine d'envoi à configurer, le compte chez l'expéditeur, et quelqu'un qui surveille les messages qui rebondissent. Une agence ou un développeur indépendant fait ça couramment.
Le conseil qui vaut dans les deux cas : mesurez d'abord combien de rappels vous enverriez réellement par semaine. Beaucoup d'équipes découvrent que le bandeau « en retard » vu chaque matin traite quatre-vingt-dix pour cent du besoin, et que les rares échéances restantes tiennent dans un agenda partagé. L'envoi automatique est une infrastructure : elle se justifie quand le volume la justifie, pas par principe.