Ce que vous voyez
Le message peut ne pas arriver; le service ne doit ni annoncer une livraison certaine ni révéler le lien.
État d’avancement:Dépend d’un fournisseur emailfiche de référencemise en service interdite pour l’instantÉtat réel:Adaptateur présent, livraison non prouvéepage d’autorité composantpromotion NO-GO
Choisissez votre lectureCommencez par la vue sans jargon si vous découvrez le sujet.
À qui s’adresse chaque lecture?
Je veux comprendre: direction, équipes métier, communication, achats et première visite. Exploitation: opérateur, support et astreinte. Vue architecte: architecte, ingénieur et sécurité. Tout afficher: revue complète de la fiche.
« Je veux comprendre » affiché. Ce choix sera repris sur les autres fiches. La décision de mise en service et les risques restent toujours visibles.
Comprendre cette fonction en 60 secondes
Le résumé donne le rôle, le trajet, le risque, le responsable et la limite de preuve en moins d’une minute. Les dépendances et exemples restent disponibles juste après, sans jargon imposé.
Résumé essentiel
Ce que c’est et à quoi cela sert
Envoyer les messages de compte.
Transmettre les invitations et liens de compte sans faire croire qu’une tentative garantit leur réception.
Une comparaison utile
Comme un contrôle d’accès: identité, droit et voie doivent correspondre.
Ce qui entre
Un utilisateur doit recevoir une invitation ou un lien de sécurité.
Qui en bénéficie et quel résultat attendre
Le message est confié au fournisseur et son résultat peut être suivi sans exposer le lien.
Les équipes autorisées et les personnes protégées.
État actuel
Dépend d’un fournisseur email. L’adaptateur Resend existe, mais le fournisseur, le domaine, la délivrabilité et le traitement des échecs ne sont pas qualifiés. Mise en service interdite pour l’instant.
Risque principal
Le message peut ne pas arriver; le service ne doit ni annoncer une livraison certaine ni révéler le lien.
Responsable
Responsable des communications de compte. Autorité de décision: Responsable sécurité et identité.
Décision suivante
Activer l’email après preuve du domaine, de la confidentialité des liens et du suivi honnête de la livraison.
Voir les dépendances, preuves et solutions de secours
Ce qui entre, en langage courant
Un utilisateur doit recevoir une invitation ou un lien de sécurité.
Ce dont il dépend
Des identités approuvées, des règles de sécurité et d’une personne autorisée pour les changements sensibles.
Comment le service continue
Ne jamais annoncer que le message est livré. Un administrateur utilise une procédure vérifiée qui ne révèle pas le lien dans l’interface ou les journaux.
Preuve attendue avant la prochaine étape
SPF, DKIM, DMARC, bounces, plaintes, redaction, retry idempotent, audit, contrat et suppression.
Statut expliqué
Le logiciel sait demander l’envoi d’un message. Il ne sait pas encore prouver que le destinataire l’a reçu, et le mode de développement peut afficher son contenu dans les journaux. Il faut sécuriser le domaine et les liens, qualifier le fournisseur, suivre les échecs et empêcher toute fuite dans les journaux.
Exemple concret
Un utilisateur doit recevoir une invitation ou un lien de sécurité. Le message est confié au fournisseur et son résultat peut être suivi sans exposer le lien.
Voir l’exemple technique précis
L’adaptateur transmet destinataire, sujet et corps à Resend quand une clé est configurée; sinon le mode de développement journalise le message.
Voir les questions et réponses selon votre rôle
Les six lectures ci-dessous reprennent les mêmes faits. Elles ne créent pas une seconde source de vérité.
- Direction
- Question: Peut-on compter sur cette fonction aujourd’hui?
Réponse: Le logiciel sait demander l’envoi d’un message. Il ne sait pas encore prouver que le destinataire l’a reçu, et le mode de développement peut afficher son contenu dans les journaux. Activer l’email après preuve du domaine, de la confidentialité des liens et du suivi honnête de la livraison. - Métier
- Question: Quel service rend-elle concrètement?
Réponse: Transmettre les invitations et liens de compte sans faire croire qu’une tentative garantit leur réception. Le message est confié au fournisseur et son résultat peut être suivi sans exposer le lien. - Achats et conformité
- Question: De quoi dépend l’engagement et qu’est-ce qui manque?
Réponse: Des identités approuvées, des règles de sécurité et d’une personne autorisée pour les changements sensibles. Il faut sécuriser le domaine et les liens, qualifier le fournisseur, suivre les échecs et empêcher toute fuite dans les journaux. Preuve attendue: SPF, DKIM, DMARC, bounces, plaintes, redaction, retry idempotent, audit, contrat et suppression. - Communication
- Question: Que peut-on annoncer sans faire de fausse promesse?
Réponse: Vous pouvez expliquer l’objectif suivant: Transmettre les invitations et liens de compte sans faire croire qu’une tentative garantit leur réception. Ne présentez pas cette fonction comme disponible en production: Le logiciel sait demander l’envoi d’un message. Il ne sait pas encore prouver que le destinataire l’a reçu, et le mode de développement peut afficher son contenu dans les journaux. - Exploitation
- Question: Qui agit et quel est le premier geste sans risque?
Réponse: Responsable des communications de compte. Autorité de décision: Responsable sécurité et identité. Marquer la livraison comme inconnue, protéger les liens, vérifier la réponse du fournisseur et traiter bounce ou retry sans doublon. - Technique
- Question: Où sont les contrats exacts?
Réponse: Utilisez la « Vue architecte ». Elle montre les entrées, les sorties, les interfaces, les données, la sécurité et les preuves provenant de la fiche d’autorité.
Trajet simple, de la situation au résultat
Le trajet montre ce qui déclenche cette fonction, le service qu’elle rend et le résultat obtenu. Il reste lisible sans fonction interactive.
Suivre le flux
Partie documentée: Envoyer les messages de compte.
Un utilisateur doit recevoir une invitation ou un lien de sécurité.
Transmettre les invitations et liens de compte sans faire croire qu’une tentative garantit leur réception.
Le message est confié au fournisseur et son résultat peut être suivi sans exposer le lien.
Comment lire ce trajet: avancez avec les flèches du clavier ou sélectionnez une étape. Les contrats exacts restent dans la « Vue architecte ».
Étape 1 sur 3: Un utilisateur doit recevoir une invitation ou un lien de sécurité.
Impact utile: Le message est confié au fournisseur et son résultat peut être suivi sans exposer le lien.
En cas de panne: Le message peut ne pas arriver; le service ne doit ni annoncer une livraison certaine ni révéler le lien.
Responsable: Responsable des communications de compte. Autorité de décision: Responsable sécurité et identité.
Premiers gestes en cas de problème
Reconnaître ce qui se passe, protéger le service et prévenir le bon responsable sans improviser.
Première action sans risque
Marquer la livraison comme inconnue, protéger les liens, vérifier la réponse du fournisseur et traiter bounce ou retry sans doublon.
Solution de secours
Ne jamais annoncer que le message est livré. Un administrateur utilise une procédure vérifiée qui ne révèle pas le lien dans l’interface ou les journaux.
Qui prévenir et où lire les preuves
Responsable des communications de compte. Autorité de décision: Responsable sécurité et identité. La procédure de production reste à créer et valider avant la mise en service. Ouvrir la fiche d’architecture et de preuve du domaine.
Besoin d’un terme technique? Ouvrir les définitions
- Email transactionnel
- message déclenché par une action
- SPF, DKIM et DMARC
- contrôles d’authenticité du domaine expéditeur
Décision actuelle: mise en service interdite pour l’instant. Le logiciel sait demander l’envoi d’un message. Il ne sait pas encore prouver que le destinataire l’a reçu, et le mode de développement peut afficher son contenu dans les journaux. Ce qui reste à faire: Il faut sécuriser le domaine et les liens, qualifier le fournisseur, suivre les échecs et empêcher toute fuite dans les journaux.Décision actuelle: promotion NO-GO, pas de mise en production. lib/mailer.ts appelle l’API Resend avec destinataire, sujet, texte et HTML lorsqu’une clé existe. Sans clé, le stub journalise le message complet; les erreurs du fournisseur sont journalisées puis absorbées. LOCAL_ONLY refuse la clé cloud. Aucun domaine expéditeur, SPF, DKIM, DMARC, webhook de livraison ou contrat n’est attesté. Blockers: Contrat et résidence, domaine validé, SPF/DKIM/DMARC, secrets rotatifs, redaction des liens, statut de livraison, retry/idempotence, bounce/complaint, audit, support et SLO restent NO-GO.
Opérer le composant
Responsabilité, séquence nominale, panne et niveau de service attendu.
| Owner et rôle | Séquence nominale | Mode dégradé | Observabilité et SLO |
|---|---|---|---|
| Envoie invitations, vérifications et liens de compte. Owner identité, sécurité et fournisseur Resend. Non-rôle: Ne garantit ni livraison, ni identité du domaine, ni protection contre le spam, ni secret des liens journalisés en développement. | L’adaptateur transmet destinataire, sujet et corps à Resend quand une clé est configurée; sinon le mode de développement journalise le message. | Une tentative ne prouve pas la livraison. Le produit ne doit pas annoncer le message reçu; retry, idempotence, bounce et complaint ne sont pas opérés. | Le niveau de preuve est Adaptateur présent, livraison non prouvée. Aucun SLO de production n’est acquis; l’owner doit mesurer disponibilité, erreurs, saturation et reprise avant promotion. |
Déplier ou replier les détails d’architecture
Contrat d’architecture
Entrées, sorties, protocoles, données, dépendances et configuration.
| Amont et entrées | Aval et sorties | Interfaces et trust boundary | État, données et déploiement |
|---|---|---|---|
| Invitations, vérification et réinitialisation de compte produites par des routes autorisées. | API HTTPS Resend, puis infrastructure email et boîte du destinataire. | HTTPS vers api.resend.com avec destinataire, sujet, texte et HTML. Cette donnée quitte Navy Phone; LOCAL_ONLY refuse la clé cloud. | L’adaptateur existe. Sans clé, le stub de développement journalise le message complet; les erreurs du tiers sont absorbées après journalisation. Déploiement: Code d’adaptation uniquement; le tiers, le domaine et la chaîne de livraison ne sont pas qualifiés. |
Déplier ou replier les détails de sécurité et de preuve
Sécurité, preuve et décision
Le statut de preuve reste visible quel que soit le profil choisi.
| Sécurité et identité | Preuve et sources | Blockers | Définitions |
|---|---|---|---|
HTTPS vers api.resend.com avec destinataire, sujet, texte et HTML. Cette donnée quitte Navy Phone; LOCAL_ONLY refuse la clé cloud. | Niveau de preuve: lib/mailer.ts appelle l’API Resend avec destinataire, sujet, texte et HTML lorsqu’une clé existe. Sans clé, le stub journalise le message complet; les erreurs du fournisseur sont journalisées puis absorbées. LOCAL_ONLY refuse la clé cloud. Aucun domaine expéditeur, SPF, DKIM, DMARC, webhook de livraison ou contrat n’est attesté. Domaine, SPF/DKIM/DMARC, contrat, résidence, redaction des liens, rotation, webhook et SLO restent NO-GO. Sources: lib/mailer.ts, lib/env.ts.Vue d’autorité du domaine · Entrée du catalogue | NO-GO: Contrat et résidence, domaine validé, SPF/DKIM/DMARC, secrets rotatifs, redaction des liens, statut de livraison, retry/idempotence, bounce/complaint, audit, support et SLO restent NO-GO. | Consulter les définitions de cette fiche |