Le problème : le certificat, le domaine et le DNS changent sans qu'on le sache, et on l'apprend par la panne. Veille re-mesure chaque jour ce qui fait tenir un domaine, garde l'avant et l'après de tout ce qui bouge, et prévient — y compris quand le changement ne casse rien encore.

L'audit public sur /verifier est une photo. L'abonnement, c'est la même photo reprise chaque jour, comparée à celle de la veille. C'est le même code de sondes des deux côtés, ce qui évite d'avoir deux vérités sur l'état d'un domaine.

Démarrer en 30 secondes

1. Ajouter le domaine au projet (/projets). 2. Le prouver, par l'une des deux méthodes que l'écran affiche — un fichier à publier, ou un enregistrement TXT à poser. Le DNS l'emporte : c'est la preuve la plus forte, et la seule que le module Mail accepte. 3. Ouvrir /veille. Le premier audit part dans la minute ; ensuite, une fois par jour.

Rien à installer, rien à brancher. Chaque constat dit ce qui a été vu, pourquoi c'est un problème, et la ligne exacte à coller dans la zone DNS.

Ce qui est vérifié

Quinze constats, chacun sous une clé stable — c'est elle que le journal des changements et les alertes citent.

Chaque constat porte une gravité : ok, attention, serieux, ou indetermine.

La délégation pendante, et ce qu'on ne prétend pas dire

pendants est la vérification que les outils grand public ne font pas, et c'est la plus utile de la liste.

Un CNAME vers mon-appli.herokuapp.com survit à la suppression de l'application. Le nom cesse d'exister chez l'hébergeur, l'enregistrement reste dans la zone du client, et n'importe qui peut reprendre ce nom chez l'hébergeur et servir ce qu'il veut sous le domaine du client. C'est la « prise de contrôle de sous-domaine ». Même famille : un MX qui pointe vers un serveur disparu, et le courrier entrant tombe dans le vide sans rebond visible pendant des jours.

Ce qui est constaté est un fait vérifiable : cet enregistrement pointe vers un nom qui ne résout vers rien. Une liste d'hébergeurs où un nom libéré se reprend sans preuve de possession sert à hausser la gravité de attention à serieux — pas à affirmer que le sous-domaine est récupérable. Le savoir exigerait d'essayer de le récupérer, ce qui est précisément l'attaque.

Sont regardés : le CNAME de www, et les cibles des MX. Pas l'inventaire des sous-domaines oubliés : l'obtenir demanderait d'interroger les journaux de transparence des certificats, un service tiers qui limite ses appels et tombe. Un inventaire incomplet présenté comme complet est pire que pas d'inventaire.

delegation interroge directement chaque serveur de noms déclaré et lui demande le SOA de la zone. Un serveur délégué qui ne connaît pas la zone est une délégation boiteuse : invisible depuis un navigateur — les autres serveurs répondent — et payée en lenteur inexplicable, jusqu'au jour où un autre serveur tombe.

Un sous-domaine n'est pas un domaine cassé

Un sous-domaine d'expédition — mail.tonsite.fr, celui que Mail te fait déclarer — n'a ni adresse A, ni serveur de noms propre, ni MX, et ne sert aucune page. C'est normal, et la veille le sait :

• Les contrôles web sont sans objet quand un nom n'a ni A ni AAAA. Pas de HTTPS, pas de robots.txt, pas de sitemap.xml, pas de llms.txt à réclamer : il n'y a pas de site. La veille le dit et passe, au lieu de compter six échecs.
• L'absence de serveur de noms n'est pas une panne. Un NS marque un point de *délégation*, pas la capacité à résoudre. Un sous-domaine servi par la zone de son parent — c'est-à-dire presque tous — n'en a aucun et résout parfaitement.

Cette distinction a une raison très concrète : sans elle, l'outil pousse à poser des enregistrements inutiles pour le faire taire. Une veille qui incite à dégrader une configuration correcte est une veille qui nuit.

Quand tu viens de poser tes enregistrements

La veille audite chaque domaine une fois par jour. Si tu publies ton SPF ou ta clé DKIM juste après un audit, l'écran garde l'ancien verdict — « Aucun enregistrement SPF » — jusqu'au lendemain, alors que l'enregistrement est là.

Vérifier un domaine d'envoi sur la page Mail relance donc la veille sur ce domaine, et le verdict se corrige au tour suivant, dans la minute. C'est le module qui vient de prouver l'existence de l'enregistrement qui prévient l'autre : tu n'as rien à faire.

Le score

Un chiffre entre 0 et 100, noté une fois par jour et par domaine, avec sa courbe sur trente jours et la comparaison entre domaines du même projet.

Il n'a de sens que comparé à lui-même, hier et le mois dernier, sur le même domaine — ou entre domaines d'un même projet, où les quinze mêmes vérifications s'appliquent. Le comparer à celui d'un inconnu ne veut rien dire. Sa seule raison d'être : une équipe qui ne peut pas constater qu'elle avance cesse d'avancer, et « il te reste deux attentions » ne dit pas s'il y en avait six ou une.

Le calcul : un serieux coûte quatre fois un attention, un ok ne coûte rien, et un indetermine sort du calcul dans les deux sens. Le compter comme un défaut ferait chuter le score pendant une panne de résolveur ; le compter comme du vert rassurerait à tort. Un domaine dont tout est indéterminé vaut 100 faute de mieux, et l'écran montre le compte d'indéterminés à côté.

Deux audits le même jour ne font qu'un point : la courbe doit raconter l'état du domaine, pas la fréquence des audits.

Les routes

Veille n'expose pas d'API d'écriture : un domaine s'ajoute au projet, et tout le reste est mesuré. Deux routes publiques la servent.

GET /verifier

La page d'audit publique, sans compte. Limitée à 10 audits par minute et par appelant, et 20 par domaine cible, pour qu'elle ne devienne pas un balayage.

GET /api/v1/analyser?e=…&tz=…&n=…

Publique, sans clé. Appartient à Cron mais partage la même limite d'appel publique ; citée ici parce que les deux pages publiques la voisinent.

GET /veille/export

Session, pas clé d'API. CSV, point-virgule et BOM, une ligne par constat et par domaine — pas une par domaine : c'est le grain auquel la question se pose, et le seul qui se filtre dans un tableur. Le score et celui d'il y a trente jours sont répétés sur chaque ligne, pour qu'un tri par colonne ne casse pas le rapprochement. 5 000 lignes au plus. Fait pour être envoyé à qui tient le DNS ou l'hébergement, et qui n'a pas de compte.

Toute requête sortante — HTTP, TLS, DNS — passe par le garde anti-SSRF src/core/urlGuard.ts : les adresses privées sont refusées, la poignée de main TLS s'ouvre sur l'adresse vérifiée et non sur le nom, ce qui ferme au passage la fenêtre du « DNS rebinding ».

Les écrans

• /veille — les domaines du projet, leur score et son évolution, et les constats de chacun triés par gravité : serieux, puis attention, puis indetermine, puis ok. L'indéterminé passe avant le vert : on n'a pas pu conclure, et ça se lit en premier.
• /veille/changements — le journal : quoi, quand, la valeur d'avant et celle d'après. C'est ce qui répond à « pourquoi les mails n'arrivent plus depuis le 4 ».

Les quotas

• Poste `domaines` : le nombre de domaines déclarés, tous modules confondus.
• Poste `alertes` : un e-mail par alerte ouverte, par palier d'échéance et par retour au vert, plus un message groupé par jour et par domaine pour les changements.
• L'audit quotidien lui-même ne consomme aucun poste de volume : il est lié au nombre de domaines, déjà borné.
• Rétention : un an de changements, un an de courbe de score.

Les pièges

• « Invérifiable » n'est pas « absent ». Un indetermine n'alerte pas, ne clôt aucune alerte en cours, ne produit aucun changement et ne compte pas dans le score. Envoyer un e-mail là-dessus transformerait une panne de résolveur en fausse alerte ; clore l'alerte annoncerait une réparation qui n'a pas eu lieu.
• Le premier audit d'un domaine ne produit aucun changement. Tout y serait « nouveau », et quinze lignes d'historique le jour de l'inscription apprennent à ne plus regarder l'historique.
• Le journal compare la valeur canonique, pas le texte affiché. Reformuler un message ne produit pas de changement, et un enregistrement réordonné par le résolveur non plus.
• Une échéance relance à chaque palier — 30, 14 et 7 jours. Prévenir une seule fois, un mois avant, c'est prévenir au moment où personne n'agit.
• Les changements d'un même jour partent en un seul message. Trois enregistrements modifiés le même jour sont un seul événement — une migration — et trois e-mails le feraient passer pour trois incidents.
• Un audit par jour et par domaine, pas plus : c'est l'échelle à laquelle ces choses bougent. Pour une surveillance à la minute d'une expiration de certificat sur un hôte précis, c'est le contrôle ssl d'Uptime qu'il faut.
• `https` ne se plaint pas d'un port 80 muet. Un port fermé est une réponse légitime — meilleure, même, qu'une redirection.
• La preuve HTTP ne donne pas accès à tout. Elle suffit à Veille et à Stats ; Mail exige la preuve DNS, et les contrôles TCP et SSL d'Uptime exigent l'une des deux.

Ce qu'il faut poser dans le DNS

GET /api/v1/domaines/dns — lecture seule acceptée.

``bash curl -s https://letock.fr/api/v1/domaines/dns \ -H "Authorization: Bearer tock_…" ``

Rend, pour chaque domaine de l'équipe, tous les enregistrements que LeTock attend : la preuve de possession, DKIM, SPF, et DMARC en conseil. Chacun porte nom, valeur, etat (absent, pose, a_fusionner, different), actuel — ce qui est publié aujourd'hui — et pourquoi. Le champ zone donne les lignes au format de zone, à importer tel quel chez la plupart des hébergeurs DNS.

C'est la seule étape de la mise en route qu'un agent ne pouvait pas franchir : les enregistrements vivaient sur trois écrans, et aucune route ne les rendait. Si tu as la main sur le DNS du domaine, tu peux maintenant les poser toi-même.

La valeur SPF est fusionnée, pas de remplacement. C'est le point à ne pas manquer en automatisant : un domaine n'a qu'un seul enregistrement SPF. La valeur rendue contient déjà ce qui est publié, avec LeTock ajouté avant le all final, dont le qualificateur est conservé — un -all reste un -all. Écrire à la place une valeur qui ne contiendrait que LeTock ne nous ajouterait pas : elle retirerait l'expéditeur en place, et tout ce qui partait par lui serait refusé ou classé en indésirable — sans un seul rebond pour le dire, puisque l'expéditeur ne serait plus autorisé du tout.

C'est une panne de réputation qu'on ne rattrape pas en une semaine. Compare actuel avant d'écrire plutôt que de faire confiance, et n'écris que si etat vaut absent, a_fusionner ou different.