1. Rappel : qu’est‑ce qu’ITYLOS ?
ITYLOS est une plateforme web suisse de transmission éphémère de secrets sensibles, pensée pour tout ce qui ne devrait jamais traîner dans l’historique d’un chat ou d’un cloud : mot de passe, token API, accès serveur, lien confidentiel ou code à usage unique.
À chaque secret correspond une capsule chiffrée, associée à un lien unique : vous créez la capsule, vous partagez le lien, le destinataire ouvre, lit… et la capsule est physiquement détruite (burn‑on‑read), sans archivage ni sauvegarde côté serveur.
L'expérience utilisateur est radicale : pas de compte à créer, pas d’application à installer, pas de conversation persistante qui s’accumule dans un thread. ITYLOS n’est ni une messagerie ni un espace de stockage : c’est un canal dédié, minimaliste, pour transporter un secret d’un point A à un point B, une seule fois, dans des conditions de sécurité maîtrisées.
[ PHILOSOPHIE : SILENCE NUMÉRIQUE ]
La V1 a validé l’ergonomie du « lien éphémère » et l’intuition du silence numérique. La V2 va plus loin : elle en apporte la preuve technique, en rendant ce silence auditable, intégrable et strictement zero‑knowledge.
2. Un modèle de sécurité écrit noir sur blanc
La grande nouveauté d’ITYLOS v2, c’est que le modèle de sécurité n’est plus seulement dans la tête de l’architecte : il est posé, versionné et auditable. Ce qui était un « design mental » devient une spécification technique explicite, que l’on peut challenger, vérifier et intégrer dans un modèle de menace formel.
La clé de déchiffrement ne franchit jamais la frontière client → serveur. Elle réside dans le fragment d’URL (#key), qui par conception HTTP n’est jamais envoyé au backend. Le serveur ne voit donc jamais le secret en clair et se comporte comme un coffre aveugle : il stocke et détruit, mais ne lit pas.
Le secret est d’abord chiffré côté client en AES‑256‑GCM via la Web Crypto API, puis re‑chiffré côté serveur avec AES‑256‑GCM via openssl pour protéger le stockage physique. Même en cas de compromission de l’infrastructure, un attaquant affronte un empilement de couches cryptographiques conçu pour rendre l’accès au contenu vain.
Les métadonnées sensibles (TTL, version du protocole, algorithme) sont intégrées dans un bloc AAD (Associated Authenticated Data). Ce bloc est haché en SHA‑256 et vérifié côté serveur : toute tentative de manipulation est immédiatement détectée, rendant le protocole traçable et évolutif sans compromis.
[ AUDIT_READY ] : ITYLOS ne se contente plus de « chiffrer fort ». Il rend le protocole lisible et auditable pour les systèmes critiques.
3. De la promesse à la destruction prouvable
Dire « on détruit les données » est une chose, le prouver cryptographiquement en est une autre. ITYLOS v2 introduit une preuve de destruction signée (Ed25519 via libsodium) : chaque lecture ou expiration de capsule génère un artefact que l’on peut consulter et vérifier hors‑ligne, indépendamment du service.
Un journal d’audit chaîné par HMAC garantit la non‑répudiation de ces événements : chaque entrée dépend de la précédente, ce qui rend extrêmement difficile toute suppression ou altération discrète de l’historique.
ITYLOS passe ainsi d’un modèle de confiance implicite (« croyez‑nous, c’est détruit ») à un modèle de vérification systématique, où la disparition d’un secret devient un fait vérifiable plutôt qu’une simple promesse d'intention.
4. Une API v2 et un CLI pour le SI
ITYLOS v2 ne vit plus uniquement dans le navigateur : il s’intègre désormais directement dans le système d’information, au cœur de vos workflows DevOps, de vos bastions SSH et de vos outils internes.
- API v2 : pensée pour les pipelines. Des endpoints dédiés permettent de créer une capsule, la lire, déclencher un burn forcé, consulter le statut d’un secret et exporter le ledger d’audit. Vous pouvez automatiser la génération de secrets éphémères dans vos scripts de déploiement ou vos portails d’admin sans passer par l’interface web.
- CLI open source (Rust) : le pont avec l’infra. Écrit en Rust pour garantir performance et sécurité mémoire, ce client en ligne de commande permet de manipuler des capsules directement depuis un terminal. Il s’intègre naturellement dans Ansible, Terraform ou vos scripts de maintenance pour industrialiser la gestion des secrets.
- Outil MCP : pour l’IA et l’automatisation. ITYLOS peut être exposé comme outil MCP (Model Context Protocol). Cela permet à un agent d’orchestration ou à un copilote interne de créer et partager des secrets de manière contrôlée, tout en respectant scrupuleusement le modèle zero‑knowledge et le burn‑on‑read.
[ USE_CASE : DEVOPS_AUTOMATION ]
Imaginez un workflow où votre pipeline de CI/CD génère un accès temporaire à une base de données, crée une capsule ITYLOS via l'API, et transmet le lien unique au développeur concerné. Le secret s'auto-détruit après lecture. Zéro trace dans les logs de déploiement, zéro persistance inutile.
5. Souveraineté et minimalisme des traces
Le choix de la Suisse (hébergement chez Infomaniak, à Genève) n’est pas neutre : ITYLOS v2 s’inscrit sous la juridiction LPD/FADP, avec un alignement RGPD, et se prémunit contre le droit extraterritorial qui pèse sur une part majeure de l’industrie du Cloud.
Ce n’est pas seulement une localisation d’infrastructure, c’est un cadre juridique assumé pour tout ce qui touche à la vie privée et à la manipulation de secrets stratégiques.
[ PROTECTION DES MÉTADONNÉES ]
Les adresses IP ne sont jamais stockées en clair : elles sont dérivées via HMAC‑SHA256 avec un sel journalier rotatif. Ce traitement est utilisé exclusivement pour appliquer un rate‑limiting dynamique (par exemple, restreindre le nombre de créations de capsules par fenêtre de temps).
Aucun journal applicatif persistant n’est conservé sur les contenus sensibles. ITYLOS applique en pratique un principe de minimalisme des traces : collecter uniquement le vecteur nécessaire au fonctionnement et à la sécurité, puis purger le reste sans délai.
6. Transparence : architecture, menaces et engagements
ITYLOS v2 ne se limite pas à « faire les choses bien dans le code » : il s’engage à montrer comment il les fait. La transparence n’est plus un argument marketing, mais une surface de contrôle concrète pour les développeurs, les RSSI et les curieux exigeants.
[ DOCUMENTATION VIVANTE ]
Le projet s’accompagne de pages dédiées qui exposent les entrailles du système : manifeste, architecture technique, threat‑model, politique de sécurité, journal de transparence, warrant canary, documentation API et guide utilisateur.
Ces ressources décrivent la stack et les choix cryptographiques, mais aussi les hypothèses de menace et les limites assumées. Cela permet de challenger le service avec des critères d’ingénierie, loin du simple storytelling promotionnel.
[ CONTRAT EXPLICITE AVEC LES UTILISATEURS ]
En rendant publiques ces briques (modèle de menace, architecture, journal d’audit, canary), ITYLOS transforme ses promesses en contrat explicite : chacun peut vérifier si le service se comporte comme annoncé et détecter un changement de posture ou de contraintes juridiques.
Cette transparence est pensée comme une invite permanente à l’audit et au signalement, plutôt que comme une plaquette statique rangée dans un coin du site.
7. UX et front : minimalisme assumé, surface d’attaque réduite
ITYLOS v2 revendique une expérience minimale : aller du secret au lien éphémère sans friction inutile. Thème sombre, accent cyan, interface épurée tout est pensé pour que l’utilisateur fasse une seule chose : créer, partager ou lire une capsule sans être distrait par des fonctionnalités annexes ou du bruit visuel.
[ FRONT DURCI PAR CONCEPTION ]
Sous cette apparente simplicité, le front est traité comme une surface critique. La politique de sécurité des contenus (CSP) est très restrictive, les en‑têtes HTTP sont durcis (HSTS, X‑Frame‑Options, Referrer‑Policy stricte) et le cache est finement configuré : no‑store sur les routes sensibles, cache long sur les assets statiques.
Pour garantir l'intégrité du rendu, ITYLOS n'autorise aucune dépendance à des CDN externes pour les polices ou les scripts. Tout est auto-hébergé, audité et servi depuis l'infrastructure souveraine Infomaniak.
[ PWA SANS COMPROMIS SUR L’ÉPHÉMÈRE ]
ITYLOS fonctionne comme une Progressive Web App : chargements rapides et ressenti application sans installation. Cependant, aucun secret n’est stocké hors de propos côté client et aucun mode offline ne vient contredire le principe d’éphémérité. L’UX reste au service exclusif du modèle de sécurité.
8. Mettre ITYLOS en perspective
Cette V2 est l’aboutissement d’une trajectoire que j’ai déjà commencé à documenter ici‑même. Si vous avez manqué les premières étapes de cette réflexion sur le silence numérique, voici les deux jalons principaux qui ont servi de fondations techniques et philosophiques :
- Genèse : Présentation du concept et du modèle zero‑knowledge : la première itération du système et la validation du modèle de chiffrement côté client.
- Réflexion : Retour d’expérience après le passage chez Korben : une analyse sur l'importance du silence numérique face à l'exposition massive.
« Le sanctuaire de l’éphémère : un canal souverain, auditable et zero‑knowledge pour vos secrets. »
Avec ITYLOS v2, ce slogan devient un contrat technique et éthique explicite : minimisation des traces, souveraineté de l’infrastructure, preuve cryptographique de destruction et transparence totale sur le modèle de menace.
La suite consistera à faire évoluer l’outil, ses intégrations et son ergonomie sans jamais briser ce contrat, même si cela implique de renoncer à certaines facilités techniques ou fonctionnalités de « confort » qui entreraient en conflit avec les impératifs de l’éphémérité et du zero‑knowledge.
9. Conclusion
« Le sanctuaire de l’éphémère : un canal souverain, auditable et zero‑knowledge pour vos secrets. »
Avec ITYLOS v2, cette phrase n’est plus un simple slogan : elle devient un contrat technique et éthique assumé.
La minimisation des traces, la souveraineté d’infrastructure chez Infomaniak, les preuves cryptographiques de destruction et la transparence totale sur le modèle de menace constituent désormais la colonne vertébrale du projet.
La suite consistera à faire évoluer ITYLOS, ses intégrations et son ergonomie sans jamais briser ce contrat, quitte à renoncer à certaines facilités techniques ou fonctionnalités de « confort » qui entreraient en conflit avec les impératifs de l’éphémère, du zero‑knowledge ou de la souveraineté des secrets.