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 / 10.4 : 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é, signé par lot (ed25519). 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. Ce qui reste à livrer, c'est la couche opposable à un tiers : signature PAdES du PDF et horodatage RFC 3161 (voir l'état du projet plus bas). Nous préférons le dire que le sur-vendre.
• 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.
• Ancrage sur une infrastructure réelle. Le dispositif s'appuie sur nos références NTS authentifiées et notre Stratum 1 GNSS — pas sur une source de confiance improvisée.

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 observent les serveurs NTP de l'audité depuis des points de mesure indépendants.
• Appliance locale. Une appliance déployée chez l'audité mesure les serveurs NTP officiels, se vérifie contre ≥ 5 ancres publiques indépendantes 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 v1.0. 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 indépendantes 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) : 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 (un fait démontré, pas encore juridiquement opposable — celle-ci viendra avec la signature). 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) : la liste exhaustive des cibles avec leurs IP réelles, comme preuve d'usage (« vos équipements utilisent bien VOS serveurs NTP »), assortie de son disclaimer de périmètre.

Honnêteté de statut : cette version génère des PDF non signés — une preuve technique, pas encore juridiquement opposable. La signature PAdES du PDF et l'horodatage RFC 3161 (cible été 2026), avec la table corrective immuable, sont la brique qui la rendra vérifiable par un tiers.

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.

• 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) : la liste exhaustive des cibles et de 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 maintenant de valider la chaîne de preuve de bout en bout chez un premier client, hors de notre propre parc. À terme, Time Evidence générera automatiquement des preuves historiques destinées aux audits PCI-DSS, ISO 27001, NIS2 ou DORA. Une page de présentation complète sera publiée lors de son ouverture au public.