Pourquoi nous développons Time Evidence

Time Evidence est notre système de preuve continue de conformité temporelle. Cette page n'est pas une fiche produit : c'est un retour d'expérience, et l'endroit où nous racontons l'histoire du projet, ses évolutions et comment nous en sommes arrivés là.

Le problème : une photo, là où l'auditeur demande un film

Face à un auditeur sur la synchronisation temporelle, la plupart des équipes ne peuvent produire qu'un screenshot ntpq pris le jour de l'audit. C'est une photo instantanée. Elle ne dit rien de l'état du parc la semaine précédente, ni du trimestre écoulé.

Conséquence, trois angles morts reviennent systématiquement :

• Aucune preuve historique : l'auditeur doit croire l'auto-déclaration et échantillonner à la main.
• Aucune dérive documentée : rien ne montre qu'un décrochage a été détecté — ni quand, ni combien de temps.
• Aucune garantie d'intégrité : rien ne prouve que l'historique n'a pas été réécrit après coup.

Pourquoi un historique est explicitement demandé

Aucun référentiel sérieux ne se contente d'une horloge « à l'heure » un jour donné. Tous demandent une cohérence surveillée dans le temps :

• ISO/IEC 27001 — A.8.17 : source de temps approuvée, monitoring de dérive actif, logs corrélables.
• PCI-DSS 10.6 (v4.0, ex-10.4 en v3.2.1) : source UTC acceptée, cohérence et peering des sources de temps.
• NIS2, DORA : journalisation fiable et capacité de reconstitution des incidents — ce qui suppose des horodatages cohérents et traçables dans la durée.

Ce que l'auditeur veut, c'est la cohérence interne du parc — machines synchronisées entre elles, sur une source approuvée, dérive détectée, journaux corrélables. Nous détaillons ces obligations sur notre page audit & traçabilité du temps vers UTC et sur les fiches de référence ISO 27001 A.8.17 et PCI-DSS 10.6.

Les choix techniques (sans tout dévoiler)

Time Evidence ne « refait » pas du monitoring. Il produit une preuve indépendante, historisée et méthodiquement qualifiée de la cohérence d'une infrastructure temporelle. Quelques partis pris déjà arrêtés :

• Un mesureur indépendant, pas un juge. RDEM est l'instrument qui mesure, pas un tiers qui s'auto-certifie. Selon le mode de déploiement, la mesure vient de sondes RDEM externes, d'une appliance posée chez l'audité, ou d'un agent léger (voir les trois modes ci-dessous) — mais dans tous les cas elle ne repose pas sur le serveur qui se déclare lui-même à l'heure.
• Journal d'intégrité chaîné, rapports scellés. Chaque lot de mesures est écrit dans un journal append-only et signé (ed25519) par l'agent collecteur, chaque entrée chaînée à la précédente (prev_hash → chain_hash), avec l'empreinte du rapport généré. Une réécriture après coup devient détectable : c'est ce qui transforme un graphe en élément de preuve. Depuis le 17 juillet 2026, chaque rapport émis est en outre scellé : signature OpenPGP détachée, horodatage RFC 3161 par des autorités d'horodatage externes, et preuve OpenTimestamps ancrée dans la blockchain Bitcoin. Un tiers peut ainsi vérifier, sans nous croire sur parole, que le rapport n'a pas changé depuis son émission. Reste à venir : la signature PAdES intégrée au PDF lui-même (voir l'état du projet plus bas).
• Principe IP-only. Nous n'avons besoin ni de vos noms de machines, ni de votre inventaire. Nous observons des adresses et des comportements de synchronisation — pas votre topologie. RDEM ne connaît pas votre inventaire informatique.
• Des ancres hétérogènes, pas une source unique. La référence se construit par diversité et consensus : les ancres de mesure mêlent des opérateurs tiers (Cloudflare, Google, Netnod, Microsoft, Apple) et nos propres serveurs NTS authentifiés. RDEM opère aussi des serveurs NTP (visibles sur ntppool.org/a/rdem-systems) et ne le cache pas : aucune ancre, les nôtres comprises, ne fait foi seule.

Trois modes de mesure

Selon qui possède l'instrument et où il tourne, Time Evidence se décline en trois modes de déploiement. Techniquement, l'appliance et l'agent client partagent le même binaire collecteur : la différence est où il s'exécute et qui le détient.

• SaaS externe. Plusieurs sondes RDEM, indépendantes de l'audité, observent ses serveurs NTP depuis des points de mesure distincts.
• Appliance locale. Une appliance déployée chez l'audité mesure les serveurs NTP officiels, se vérifie contre ≥ 5 ancres publiques hétérogènes et peut compter les requêtes NTP réellement servies au parc.
• Agent client léger. Un binaire Go installé chez l'audité exécute des mesures périodiques (≈ 2 min), signe chaque lot (ed25519) et le transmet en TLS à l'API RDEM pour chaînage, conservation et génération de preuve. L'agent ne remplace pas le serveur NTP et ne s'auto-certifie pas : il est un point de collecte signé, identifié et versionné, dont les mesures sont qualifiées par la méthode RDEM-TEM.

Une méthode nommée et publiée : RDEM-TEM-001

C'est le changement le plus important de ces dernières semaines, et il raconte bien où va le projet. Time Evidence ne repose plus sur « notre façon de mesurer » : il s'appuie sur un référentiel méthodologique public, RDEM-TEM-001 (version en vigueur : v1.5). Chaque rapport référence la méthode et son empreinte SHA-256, le moteur de mesure (commit), l'agent collecteur et sa version scellée par lot, la politique de seuil appliquée (nommée et versionnée) et les annexes de preuve. C'est ce qui fait passer un graphe joli à un constat reproductible.

Pourquoi ne pas attendre le lancement ?

Parce qu'un produit destiné aux audits doit être transparent sur sa conception. Nous avons choisi de documenter publiquement les raisons qui nous ont conduits à développer Time Evidence, les choix techniques effectués, et les retours d'expérience issus de son utilisation sur notre propre infrastructure — avant son ouverture au public. Un outil qui prétend produire de la preuve se doit d'être lui-même vérifiable : cette page en est la première pièce.

Où nous en sommes aujourd'hui

Le moteur tourne déjà — en production, sur notre propre infrastructure, en monitoring de déviance de notre flotte NTP/NTS interne. L'API de collecte et de génération de rapports est en service :

La preuve vivante : l'état temps réel de nos serveurs et de leurs certificats NTS est déjà public sur notre page de status du pool NTS. Time Evidence ajoute, par dessus, l'historisation longue signée, la corrélation multi-sondes et la génération de rapports audit-ready.

Ce que le moteur mesure aujourd'hui

Ces capacités sont en production sur notre propre parc — c'est ce que nous exerçons avant d'ouvrir le service :

• Offset NTP en clair (UDP/123), la mesure classique.
• Offset NTP-over-NTS authentifié : le cycle complet Key Establishment (KE) → cookies → requête chiffrée et authentifiée (AEAD), pas seulement la poignée de main TLS. Validé en production sur des sources tierces — par exemple nts.netnod.se : offset sub-milliseconde, stratum 1.
• Deux séries d'offset distinctes par cible NTS (clair + authentifié) — deux mesures qui se contrôlent mutuellement.
• Serveurs NTS-only correctement pris en charge. Les serveurs qui refusent le NTP en clair sur le port 123 (comme Netnod) sont désormais monitorés proprement : statut NTP « n/a » plutôt que « en échec », offset obtenu via NTS authentifié.
• Santé de l'instrument. Chaque sonde remonte son propre état d'horloge (chronyc/ntpq : offset, skew, dispersion, leap, sources), et depuis août comment elle se source : NTS authentifié ou NTP en clair vers ses propres amonts (chronyc authdata), pas seulement auprès de qui. La crédibilité de la mesure fait partie de la preuve.

Ce que contient un rapport aujourd'hui

Le rapport a beaucoup évolué depuis la première version de juin. Ce n'est plus un simple bandeau « % conforme » : c'est une preuve technique, scellée et vérifiable par un tiers. Il s'organise aujourd'hui autour de trois axes tenus séparés :

• Qualité de l'heure : les mesures dans la tolérance, rapportées au niveau mesure (et non « par cible »), avec déviance signée (biais directionnel) et absolue (magnitude).
• Qualité de l'instrument : la sonde elle-même est qualifiée selon RDEM-TEM-001 (§7) — une mesure issue d'un instrument dégradé ne pèse pas comme une mesure issue d'un instrument sain.
• Couverture de preuve : mesures attendues vs reçues, ajustée des périodes excusées (maintenance déclarée), pour ne jamais confondre « pas de donnée » et « hors tolérance ».

À quoi s'ajoutent :

• un executive summary par cible : verdict de l'instrument (fiable / dégradé / inconnu), conformité, et seuil appliqué (seuil contractuel ou 99 % par défaut, avec sa source) ;
• un bloc méthode & traçabilité : référence RDEM-TEM-001 + son SHA-256, moteur de mesure, agent collecteur + version, politique appliquée, empreinte du rapport ;
• l'attribution des responsabilités : une panne RDEM, une coupure Internet, une VM à l'arrêt ou une dérive de la cible ne sont jamais mélangées — c'est ce qui distingue un incident subi d'un incident imputable à l'audité ;
• les incidents conservés et qualifiés : le fait brut est immuable, la qualification est une annotation append-only (« déclaré client, non vérifié »), avec quatre niveaux de confiance (donnée immuable / attribution / maintenance excusée / justifié client) ;
• le suivi du certificat NTS (empreinte, validité, rotations sur la période) ;
• la liste des écarts ≥ 25 ms et une annexe de définition des métriques ;
• une annexe parc au format CSV, hashée (SHA-256) : le parc des clients NTP servis par l'appliance, c'est-à-dire la consommation par adresse IP cliente, comme preuve d'usage (« vos équipements utilisent bien VOS serveurs NTP »), assortie de son disclaimer de périmètre.

Honnêteté de statut : depuis le 17 juillet 2026, chaque rapport est scellé (signature OpenPGP détachée, horodatage RFC 3161 externe, preuve OpenTimestamps ancrée dans Bitcoin) et vérifiable par un tiers. Nous ne prétendons pas pour autant qu'il soit juridiquement opposable. Restent à livrer : la signature PAdES intégrée au PDF et la table corrective immuable.

Avancement du projet

Cette page est mise à jour à mesure que le projet franchit des étapes réelles. Pas de feuille de route fictive : chaque entrée est ajoutée le jour où elle devient vraie. Cette page sera mise à jour régulièrement jusqu'au lancement afin de documenter les principales étapes du projet.

• 30 septembre 2026 Ouverture de la bêta publique : Cloud Evidence (serveurs NTP publics, sans installation), Appliance (sonde dans le réseau du client) et Appliance + serveur NTP (avec journal des clients NTP) se commandent sur la page Time Evidence, avec un rapport réel émis pendant la bêta, téléchargeable avec ses sceaux. Service offert jusqu'au 31 décembre 2026.
• 12 août 2026 La sonde dit désormais comment elle se source, pas seulement auprès de qui : relevé de l'authentification de ses propres amonts (chronyc authdata : NTS ou NTP en clair). La santé de l'instrument couvre maintenant la qualité de sa propre chaîne de temps.
• 5 août 2026 La bascule de certificat NTS est marquée, datée et bornée dans le rapport, et calculée par nœud : derrière un même nom (round-robin, anycast), chaque machine est suivie séparément. Le rapport relève aussi la version NTP annoncée par chaque réponse.
• 4 août 2026 Traçabilité de l'amont : depuis le 2 août, la sonde relève pour chaque cible l'indicateur leap, la distance à la racine et le refid (l'horloge de référence déclarée), en NTP clair comme en NTS. Depuis le 4 août, ces refid sont résolus en identité à partir de l'inventaire tenu sur ntp.rdem-systems.com. Une perte de référence annoncée par la cible entre au rapport comme un fait de traçabilité, pas comme une non-conformité.
• 17 juillet 2026 Les rapports sont scellés : signature OpenPGP détachée, horodatage RFC 3161 par des autorités d'horodatage externes, preuve OpenTimestamps ancrée dans Bitcoin. Le même jour, la méthode atteint RDEM-TEM-001 v1.5, au fil de versions successives publiées depuis le 5 juillet : défendabilité calculée sur les données brutes (§7bis), modèle de menaces et ce que le rapport n'établit pas. Les versions antérieures restent en ligne.
• 5 juillet 2026 Le rapport devient un véritable outil d'audit : publication du référentiel de méthode RDEM-TEM-001 v1.0 (référencé, avec son SHA-256, dans chaque rapport), attribution des responsabilités (RDEM / Internet / VM / cible jamais mélangées) et qualification d'incidents à quatre niveaux de confiance (annotations append-only, « déclaré client, non vérifié »), pilotables depuis le portail members. Le positionnement se précise : d'un monitoring de dérive vers un système de preuve continue de conformité temporelle.
• 3 juillet 2026 Ajout de l'annexe parc au format CSV, hashée (SHA-256) : le parc des clients NTP servis et leurs IP réelles, comme preuve d'usage en complément du PDF.
• 2 juillet 2026 L'API de collecte et de génération de rapports passe en production (time-evidence.rdem-systems.com, intégrée au portail members). Mise en service de la mesure d'offset NTP-over-NTS authentifié (cycle KE → cookies → AEAD), validée sur source tierce (Netnod, stratum 1, offset sub-ms). Prise en charge propre des serveurs NTS-only et première version du rapport audit-ready.
• 27 juin 2026 Pourquoi ce projet existe : publication de ce retour d'expérience et mise en service des premières sondes d'observation sur l'infrastructure RDEM.

Et ensuite ?

La prochaine phase n'est plus de construire la sonde cliente : l'agent auto-enrôlé (Docker, identité pubkey-first, gaté par licence) et la flotte de sondes SaaS existent déjà. Il s'agit de valider la chaîne de preuve de bout en bout chez un premier client, hors de notre propre parc : c'est en cours, en test dans un établissement d'enseignement supérieur. À terme, Time Evidence générera automatiquement des preuves historiques destinées aux audits PCI-DSS, ISO 27001, NIS2 ou DORA. La page de présentation est en ligne : Time Evidence.