HISTOIRE / Histoire du produit

L’histoire de Scanapse

Scanapse évolue par petites décisions visibles : une formulation corrigée, une preuve mieux expliquée, un moteur plus prudent ou une interface plus lisible. Cette page conserve cette continuité pour que le produit actuel reste compréhensible dans le temps.

L’historique n’est pas une vitrine de numéros de version. Il documente les choix qui ont changé la manière d’observer un domaine, de conserver les preuves et de restituer une connaissance sans masquer les limites. Les phases anciennes sont conservées lorsqu’elles sont documentées, sans inventer de version ni de date.

NOM DE DOMAINE

L’histoire publique de scanapse.com

Cette chronologie documente l’usage public du nom scanapse.com dans le produit. Ce n’est pas un historique WHOIS, de propriété ou de titulaire du domaine.

Origine documentée de Scanapse

Le projet Scanapse possède un point de départ documenté au 11 décembre 2025. Cette date concerne le projet, pas l’enregistrement du domaine.

scanapse.com entre dans le périmètre de production

La release 2.0.1 place scanapse.com et www.scanapse.com dans le périmètre de production, avec almouatin.com encore utilisé temporairement.

Identité publique consolidée

Les configurations, contacts techniques et URLs canoniques convergent vers scanapse.com, tout en conservant la trace du déploiement temporaire.

Preuve publique signée

Le Canary public ajoute à scanapse.com une preuve cryptographique datée, avec historique et continuité vérifiables.

Évolutions documentées

Ce qui a changé, version après version

Les changements sont conservés avec leur contexte : expérience de lecture, méthode, sécurité, stockage, restitution et corrections. Le détail technique reste disponible lorsqu’il aide à comprendre une décision.

Version2.9.5-rc.1
Courante

Candidate de remise en service

Cette candidate reconnecte les formulaires au moteur existant, distingue les besoins du scan et de la reprise, et renouvelle la presentation sans retirer les contenus. La recette sur le serveur cible reste necessaire.

Parcours

  • Champs de saisie accessibles et execution directe par defaut.
  • Authentification independante des tables de reprise.
  • Assets nommes par leur empreinte et presentation claire/sombre responsive.
Version2.9.4.2
Archivée

Stabilisation du deploiement et disponibilite du scan

La 2.9.4.2 bloque proprement les nouvelles lectures tant que le schema 2.9.2 n est pas complet, renforce le contrat 64/64 vers 65/99/21 et aligne la livraison sur le contrat V4.

Disponibilite

  • Une lecture publique n est plus mise en file si le schema operationnel attendu n est pas pret
  • Le service de lecture reste en attente tant que son stockage operationnel n est pas pret
  • Le formulaire public affiche un etat temporairement indisponible sans exposer le schema, SQL ou les details internes

Schema 2.9.2

  • La baseline 2.9.1 reste 64/64 avec contact_messages.public_id et dependencies.provider_id
  • La cible complete reste 65 tables, 99 colonnes critiques et 21 index critiques
  • Preflight, migration et verification capturent la base applicative et refusent les bases systeme

Web et livraison

  • Le sitemap XML reference sa feuille XSL et les liens du rendu XSL sont directement navigables
  • Le polling du suivi de lecture est ralenti lorsque l onglet est masque
  • Les paquets FULL et PATCH suivent la separation V4 entre code, base, documentation et verifications
Version2.9.4.1
Stable

Correctif de deploiement du schema

La 2.9.4.1 corrige le contrat de baseline 2.9.1 et fiabilise les scripts de migration et de verification 2.9.2 sans modifier le moteur Phase Resume.

Schema

  • Le diagnostic utilise les colonnes reelles contact_messages.public_id et dependencies.provider_id
  • Le preflight reste a 64/64 et le schema 2.9.2 complet vise 99/99 colonnes critiques
  • Le verificateur qualifie explicitement scanapse_schema_meta avec la base applicative capturee
  • La migration exige la baseline exacte 2.9.1 avant toute creation des deux tables P2.3B
Version2.9.4
Stable

P2.3B Phase Resume

La 2.9.4 reprend un run interrompu depuis ses checkpoints durables sans recollecter les phases déjà acceptées.

Reprise déterministe

  • Les phases completed, partial et skipped restent immuables dans le run repris
  • Le même scan_run est conservé et la référence previous_scan_id reste figée pendant la reprise
  • La fenêtre de reprise est bornée à 30 minutes et le budget global reste limité à trois tentatives

Persistance et validation

  • Le rapport final et son enveloppe signée sont checkpointés exactement pour permettre une reprise de persistance sans nouvelle signature
  • Le schéma interne passe en 2.9.2 par une migration additive de deux tables après préflight 64/64 de la baseline 2.9.1
  • P2.3B reste en validation locale tant que les drills réels de recovery et de concurrence ne sont pas terminés
Version2.9.3
Stable

P2.3A Recovery Core

La 2.9.3 ajoute une récupération bornée des jobs interrompus sans rejouer une lecture lorsque des preuves durables rendent le replay ambigu.

Récupération

  • Les leases expirés avant démarrage peuvent être remis en file sans consommer de tentative
  • Les erreurs transitoires explicitement autorisées peuvent utiliser des retries bornés avant la création d un run durable
  • Un résultat final exact déjà enregistré peut être réconcilié sans rescanner le domaine

Administration et observabilité

  • Les actions manuelles de récupération sont protégées par rôle, CSRF, réauthentification et audit
  • L observabilité mesure les reprises, attentes, réconciliations et cas nécessitant une reprise par phase
  • P2.3B Phase Resume reste planifié ; P2.3 global et le Gate B de convergence restent partiels
  • Le schéma interne reste 2.9.1 et aucune migration SQL n est requise
Version2.9.2.1
Stable

Correctif de finalisation des lectures

La 2.9.2.1 corrige la finalisation technique qui pouvait laisser une lecture terminée affichée comme toujours en cours.

Parcours public

  • Une lecture finalisée publie correctement son état terminal puis ouvre automatiquement le dossier disponible
  • Le schéma interne reste en 2.9.1 et aucune migration de données n est nécessaire
Version2.9.2
Stable

Public Flow & Surface Cleanup

La 2.9.2 termine le parcours de lecture jusqu’au dossier public et retire des interfaces visibles les détails d’implémentation qui ne sont pas utiles au lecteur.

Parcours public

  • Une lecture terminée ouvre automatiquement son dossier complet ou partiel lorsque le résultat public est valide
  • La finalisation du job et de son résultat public est publiée de façon atomique

Surface produit

  • Les interfaces publiques et d’administration emploient un vocabulaire factuel sans exposer inutilement les noms d’implémentation
  • Version applicative 2.9.2, schéma interne 2.9.1 inchangé, aucune migration SQL
Version2.9.1
Stable

P2.2 Progressive Persistence

La 2.9.1 rend les phases du scan durables : chaque checkpoint valide est conservé avant la phase suivante, la progression publique ne reflète que des faits persistés et un dossier peut être explicitement partiel sans inventer les phases non exécutées.

Persistance progressive

  • Les phases terminées sont checkpointées en stockage interne avec statut canonique, résultat borné, hash SHA-256 et horodatage de persistance
  • Chaque tentative de job peut être reliée à son scan_run sans exposer les identifiants numériques au public
  • Le trigger refresh reste distinct de public dans la provenance du scan
  • Le vérificateur historique verify-scanapse-2.9.0.sql est durci pour phpMyAdmin : le schéma sélectionné est capturé avant les lectures information_schema et les tables applicatives sont qualifiées

Vérité des phases

  • Les états completed, partial, failed, skipped et untested restent distincts et l ordre de sequence reflète l exécution réelle
  • La progression publique est dérivée uniquement des checkpoints durables, sans faux pourcentage ni temps restant estimé

Frontière P2.3

  • Les jobs scan restent à max_attempts=1 ; aucun retry automatique, backoff, dead-letter ou replay n est introduit
Version2.9.0
Stable

P2.1 Asynchronous Scan Jobs

La 2.9.0 unifie les lectures publiques, administration, actualisations et watchlists dans une seule file interne de traitement : chaque scan devient un job exécuté par le scheduler existant, avec suivi public minimal et WebCron de reprise.

Every scan is a job

  • Les soumissions publiques, actualisations, scans administration et watchlists utilisent le même job générique scan
  • La soumission retourne rapidement un UUID et la page /scan/job/<uuid> suit uniquement des états réellement connus
  • Un worker opportuniste peut démarrer après la réponse HTTP ; le WebCron reste le mécanisme durable de reprise

Queue et confidentialité

  • La déduplication transactionnelle réutilise un job actif pour un même domaine, sauf lecture forcée par un super-admin
  • Les jobs ne stockent pas l IP brute ; seul le pseudonyme journalier déjà utilisé par Scanapse est transmis au worker
  • Le statut public n expose ni lease, ni worker, ni SQL, ni erreur interne brute

Contrat P2.1

  • Évolution additive du schéma interne de stockage 2.6.1 vers 2.9.0 avec target_id, trigger_type et index de déduplication des scans
  • Les jobs scan restent à max_attempts=1 ; le retry et la récupération restent réservés à P2.3
  • Aucune progression publique par phase n est inventée avant la persistance progressive P2.2
Version2.8.1
Stable

P1.10 Observability Metrics

La 2.8.1 ferme P1.10 avec une observabilité administration factuelle du moteur synchrone : médiane/P95, phases, runs partiels, Scheduler, changements, sécurité, erreurs de stockage et versions observées.

Performance et exécution

  • Nouvelle page administration Observabilité réservée au super-admin avec fenêtres 24 h, 7 jours et 30 jours
  • Médiane, P95, minimum, maximum et taille d’échantillon calculés uniquement sur les durées réellement mesurées
  • Les durées absentes restent non mesurées et ne deviennent jamais 0 ms

Qualité opérationnelle

  • Échecs et runs partiels sont rapprochés des phases, catégories d’erreur sûres, blocages sécurité et erreurs de stockage
  • Le Scheduler existant expose ses états et tentatives sans être présenté comme la future queue asynchrone P2
  • Le retry par scan reste explicitement non instrumenté jusqu’au modèle P2.3

Mémoire et confidentialité

  • Les changements temporels agrègent les résumés canoniques persistés et distinguent les enregistrements bruts
  • La matrice de versions distingue application courante, schéma attendu/observé, moteur, règle et rulepack privé
  • Toutes les métriques détaillées restent privées dans administration ; le /health public demeure minimal
  • Aucune migration SQL : le schéma interne de stockage attendu reste 2.6.1
Version2.8.0
Stable

Canary Trust Layer

La 2.8.0 transforme Canary en couche de confiance et de mémoire publique Scanapse : lecture stratégique, timeline KM issue des preuves signées, pont produit, alertes administration et journal opérationnel privé.

Trust Layer public

  • La page Canary explique désormais pourquoi la preuve existe, comment la lire et comment elle s’inscrit dans la méthode Scanapse
  • Une lecture stratégique expose état de confiance, fraîcheur, nombre de publications et historique visible sans score artificiel
  • Une timeline KM est dérivée uniquement des enveloppes signées et distingue origine, publication manuelle et renouvellement WebCron

administration et gouvernance

  • Le cockpit Canary ajoute des alertes actionnables sur expiration, continuité, renouvellement, WebCron et échecs de publication
  • Un journal opérationnel privé conserve les événements Canary bornés sans secret et les distingue explicitement des preuves signées publiques
  • Les erreurs du journal restent fail-open et ne transforment jamais une signature réussie en échec applicatif

Contrat technique

  • Le payload signé scanapse-canary/1 et la chaîne Ed25519 restent inchangés
  • Aucune migration SQL : le schéma interne de stockage attendu reste 2.6.1
Version2.7.9
Stable

Public Canary UI

La 2.7.9 rend la preuve Canary publique plus lisible et présentable : historique détaillé, états visuels, empreintes copiables, mise en page responsive et métadonnées historiques extraites des enveloppes signées.

Présentation publique

  • L’historique public affiche séquence, publication, expiration, origine, état et preuve dans une carte lisible
  • Les états temporels utilisent des badges explicites et les SHA-256 complets restent copiables
  • La mise en page passe en cartes empilées sur mobile sans perdre les informations de vérification

Métadonnées signées

  • Les dates et l’origine des publications historiques sont relues depuis le payload signé de chaque enveloppe
  • Une enveloppe historique illisible ne casse pas la page publique et conserve au minimum sa séquence et son SHA-256 de fichier
  • Aucune migration SQL et aucun changement du protocole Ed25519
Version2.7.8
Stable

administration Canary Operations

La 2.7.8 transforme Canary en circuit opérationnel complet : cockpit administration, première publication directe, renouvellement WebCron observable, test de préparation, historique immuable et page publique compacte.

Opérations administration

  • Le cockpit distingue état public, séquence, dernière publication, prochaine échéance, expiration et santé WebCron
  • La première publication enregistre, signe et publie les déclarations en une opération sérialisée
  • Les actions de vérification publique et de test d’automatisation ne modifient pas la séquence

WebCron et continuité

  • Chaque appel WebCron authentifié enregistre un heartbeat non secret avant la dépendance au stockage interne
  • Le renouvellement automatique publie uniquement lorsqu’il est dû et réutilise les déclarations déjà approuvées
  • La santé WebCron distingue jamais observé, actif et en retard avec un seuil par défaut de 45 minutes

Preuve publique

  • La page Canary publique est plus compacte avec statut, dates, continuité, déclarations, preuve repliable et historique borné
  • Les empreintes et SHA-256 complets restent accessibles et copiables sans exposer de matériel privé
  • Aucune migration SQL : le schéma interne de stockage attendu reste 2.6.1
Version2.7.7
Stable

P1.9 Discovery & Sharing

La 2.7.7 rend chaque dossier public découvrable et partageable avec sitemap dynamique, image OG locale, JSON-LD Report factuel et partage natif, tous soumis au même contrat de visibilité.

Découverte

  • Les dossiers publics persistés rejoignent dynamiquement les sitemaps XML et humain en FR/EN
  • Un dossier privé ou supprimé disparaît immédiatement des surfaces de découverte côté application
  • Les snapshots historiques ne sont pas indexés individuellement

Partage et données structurées

  • Chaque dossier public dispose d’une image OG 1200×630 générée localement avec ETag déterministe
  • Le JSON-LD ajoute un nœud schema.org Report fondé uniquement sur les données persistées
  • Le partage privilégie Web Share et conserve un fallback presse-papiers sans URL de tracking

Contrat de preuve

  • Aucun score global, rating ou jugement sûr/dangereux n’est ajouté aux surfaces de découverte
  • Le schéma interne de stockage attendu reste 2.6.1, sans migration SQL
Version2.7.6
Stable

Domain Guard & Cleanup

La 2.7.6 bloque la création de dossiers pour les domaines sans preuve DNS, ajoute la suppression contrôlée des domaines depuis administration et corrige l’état public du Canary avant sa première publication.

Domain Guard

  • Un préflight DNS A, AAAA, CNAME, NS, MX ou SOA est exécuté avant toute création durable de scan
  • Un domaine sans preuve DNS est refusé sans dossier, snapshot ou cible durable
  • Une panne du résolveur est distinguée d’un domaine inexistant et renvoie un état de mesure indisponible

Nettoyage administration

  • La liste administration des scans ajoute une colonne Actions avec suppression réservée au super-admin
  • La purge exige CSRF, mot de passe courant et confirmation exacte du domaine, puis masque avant suppression
  • Rapports, fichiers, cible, runs, watchlist/jobs liés et événements de scan sont purgés de manière contrôlée

Public Canary

  • Une chaîne de confiance initialisée sans publication est affichée comme première publication en attente, et non comme Canary non configuré
  • La page publique Canary est plus compacte avant la première preuve signée et Histoire conserve quatre jalons plus courts
  • Aucune migration du schéma interne de stockage : le schéma attendu reste 2.6.1
Version2.7.5
Stable

Public Canary Proof

La 2.7.5 transforme /canary en page de preuve publique : statut lisible, déclarations signées, empreintes complètes, continuité, historique immuable et accès direct aux JSON de vérification.

Preuve publique

  • Le statut distingue valide, renouvellement proche, expiré, rupture de continuité et non configuré
  • Payload, enveloppe, identifiants et empreintes sont affichés en entier et copiables
  • La page explique explicitement ce que la signature prouve et ce qu’elle ne permet pas de conclure

Continuité et histoire

  • Les dernières publications Canary sont reliées à leurs enveloppes JSON immuables
  • La vérification courante contrôle réellement le prédécesseur attendu lorsque la séquence est supérieure à 1
  • La page Histoire documente désormais l’usage public de scanapse.com sans prétendre fournir un historique WHOIS ou de propriété

Navigation publique

  • Canary rejoint le catalogue public et le sitemap
  • Le footer affiche l’accès Canary et la version courante à côté du lien Histoire
  • Aucune migration du schéma interne de stockage et aucun changement du protocole Ed25519 P1.8
Version2.7.4
Stable

Scanapse 2.7.4

La 2.7.4 simplifie l’activation du Canary dans administration : une clé personnelle initialise ou fait tourner la racine et la clé opérationnelle sans copie manuelle de clé publique ou de délégation.

Version2.7.3
Stable

Canary UI

La 2.7.3 harmonise la page Canary publique et le cockpit administration avec le design Scanapse, sans modifier le protocole cryptographique P1.8.

Interface publique

  • La page /canary reprend le hero éditorial, les cartes, états de vérification et blocs de preuve du site public
  • Les endpoints /canary.json et /canary.pub restent volontairement en JSON brut pour la vérification machine

administration

  • Tous les formulaires Canary utilisent les composants administration, avec champs lisibles, actions hiérarchisées et traitement destructif explicite
  • Le cockpit Canary expose des cartes d’état et un parcours racine, délégation, publication et rotation plus lisible
Version2.7.2
Stable

Scanapse 2.7.2

P1.8 introduit le Canary signé par délégation Ed25519, son automatisation administration/WebCron et finalise les exports professionnels vérifiables.

Version2.7.1
Stable

P1 Advanced Evidence

La 2.7.1 approfondit les preuves publiques sans transformer une mesure impossible en absence : Canary passif, TLS post-quantique selon capacité réelle, OpenPGP, DNSSEC, transport mail et Web moderne, CSP avancée et intégration au rapport V2.

Preuves avancées

  • Les états observed, not_observed et untested restent distincts dans les collecteurs P1
  • Le probe TLS post-quantique sépare capacité locale, résultat de négociation et panne de mesure
  • DNSSEC sépare présence DS/DNSKEY et validation cryptographique

Fiabilité 2.7

  • Le moteur temporel filtre le bruit volatil sans modifier la preuve brute
  • Le health public est minimal et le cockpit administration conserve le diagnostic détaillé
  • L observatoire public utilise des comptes factuels plutôt qu un pourcentage de connaissance
Version2.6.2
Stable

Config Source Unique + administration Left Cockpit

La 2.6.2 retire les versions du fichier local et refond administration avec une navigation principale à gauche, des états de service plus lisibles et un cockpit plus dense.

Configuration

  • La version applicative et la version de schéma attendue sont définies uniquement dans app/config.php
  • config.local.php ne peut plus surcharger app_version ni database.schema_version
  • Le schéma interne de stockage reste en 2.6.1 et aucune migration SQL n’est requise

administration

  • La navigation principale passe à gauche sur desktop et le drawer mobile s’ouvre depuis la gauche
  • Le tableau de bord renforce les états de service, KPI, activité récente et surveillance
Version2.6.1
Stable

Security + administration UI

La 2.6.1 sépare la sécurité administration du rate limiter public, ajoute des challenges serveur, un journal privé et des blocages administratifs, puis affine le cockpit mobile first.

Authentification

  • Bootstrap, login et récupération utilisent des challenges courts à usage unique et des compteurs dédiés
  • L IP reste un signal privé de sécurité, pas le compteur principal des tentatives

Cockpit

  • Une page Sécurité centralise événements, risques, signatures et blocages actifs
  • Le rail droit devient rétractable sur desktop et conserve un drawer accessible sur mobile

Base de données

  • Migration additive vers le schéma interne de stockage 2.6.1, sans reset destructif
Version2.6.0.1
Stable

Persistence Fix

La 2.6.0.1 sépare l’enregistrement du rapport des index de connaissance normalisés afin qu’une erreur secondaire ne puisse plus annuler un dossier signé déjà enregistré.

Persistance

  • Le domaine, le rapport, les dépendances et leur vérification sont commités avant la normalisation V2
  • Une panne des tables de connaissance devient une dégradation journalisée et ne bloque plus le dossier public
  • Le schéma interne de stockage reste en 2.6.0, sans migration SQL
Version2.6.0
Stable

Clean Baseline et persistance vérifiable

La 2.6.0 unifie application et schéma interne de stockage, reconstruit une baseline canonique de 60 tables et rend chaque étape de persistance vérifiable depuis administration sans exposer les secrets.

Baseline

  • Application et schéma utilisent désormais la version 2.6.0
  • Un install SQL canonique et un reset SQL destructif recréent directement les 60 tables attendues
  • Le vérificateur SQL contrôle la structure réelle au lieu de se fier uniquement au numéro de version

Persistance

  • Les écritures domaine, rapport, dépendances, connaissance, vérification et transaction exposent des étapes techniques sûres dans administration
  • Le test de persistance administration écrit un domaine et un rapport temporaires puis annule la transaction

administration mobile first

  • La navigation devient un rail droit sur desktop et un drawer accessible sur mobile
  • Les icônes SVG inline restent locales et compatibles avec la CSP
Version2.5.4.2
Stable

Cockpit administration et mail local Infomaniak

La 2.5.4.2 transforme l’administration en cockpit opérationnel, relie ses indicateurs aux rapports enregistrés, ajoute le scan depuis l’administration et utilise le transport mail local PHP sans identifiants mail.

Cockpit administration

  • Le tableau de bord distingue rapports enregistrés, activité opérationnelle, messages, domaines masqués et jobs à traiter
  • Les scans peuvent être lancés depuis l’administration et la page Scans retombe sur les observations enregistrées lorsque le journal opérationnel est incomplet
  • La navigation administration est regroupée en Pilotage, Surveillance, Expertise et Administration

Réconciliation

  • Un super-admin peut reconstruire les runs opérationnels manquants à partir de scanapse_reports sans modifier les rapports, preuves ou décisions de visibilité
  • Les runs historiques reconstruits n’inventent pas de version applicative inconnue

Mail local

  • Notifications, récupération administration et réponses utilisent le transport PHP mail local Infomaniak
  • Aucun identifiant ou mot de passe mail n’est requis dans config.local.php

Base de données

  • Le schéma interne de stockage reste en 2.3.3 : aucune migration SQL supplémentaire
Version2.5.4.1
Stable

Durcissement, traduction et diagnostic administration

La 2.5.4.1 durcit les formulaires publics, complète le français et l’anglais, compacte plusieurs surfaces éditoriales et rend le diagnostic stockage interne de administration explicite sans exposer de secrets.

Contact et sécurité

  • Contact ajoute honeypot, délai minimal signé, limitation dédiée et contrôle des URL dangereuses ou excessives
  • Les notifications SMTP restent limitées à une référence et un lien administration, sans corps de message

Langues et interface

  • Les surfaces FR/EN sont harmonisées, les apostrophes françaises corrigées et « dossier » devient « domain folder » en anglais
  • Méthodologie et comparaison utilisent des compositions plus compactes et des surfaces compatibles avec les deux thèmes

administration et stockage interne

  • administration distingue base désactivée, pilote absent, connexion refusée, schéma indisponible, version incorrecte, structure incomplète et état prêt
  • Le schéma reste en 2.3.3 et le vérificateur contrôle aussi les prérequis hérités de 2.3.2
Version2.5.4
Stable

Observatoire public et administration opérationnel

La 2.5.4 rend explicite le fonctionnement public par défaut de Scanapse, enrichit administration pour administrer domaines et messages, sécurise le bootstrap et la récupération et corrige le basculement clair/sombre en un clic.

Observatoire public

  • Tout scan lancé depuis l’interface publique reste public par défaut et enrichit la mémoire stockage interne du domaine
  • administration peut masquer le dossier ou son historique sans supprimer les observations conservées
  • Dossiers et constellation peuvent découvrir toutes les lectures publiques, les entrées curatées conservant leurs métadonnées éditoriales

Administration administration

  • Le schéma interne de stockage 2.3.3 ajoute email administrateur, récupération à double canal, réponses locales aux messages et suppression logique
  • Le premier super-admin peut être créé par bootstrap Web à token serveur, avec une voie CLI locale de secours
  • Les notifications SMTP ne contiennent jamais le corps des messages de contact

Interface

  • Le bouton de thème bascule directement entre clair et sombre, le système ne servant qu’au premier chargement sans préférence
  • L’historique propose une relance directe du domaine et renforce la lecture chronologique de l’observatoire
Version2.5.3
Stable

Mémoire permanente et historique explicatif

La 2.5.3 fait de stockage interne la mémoire permanente des lectures réussies, transforme l’historique en timeline explicative et ajoute un contrôle de visibilité sans compte.

Mémoire

  • Le schéma interne de stockage passe à 2.3.2 et les rapports historiques ne sont plus purgés selon leur âge
  • Le cache fichier reste borné et ne devient pas la source canonique de permanence

Historique

  • La page Historique devient une timeline paginée qui explique la trajectoire du domaine et les changements observés
  • Historique et Comparaison restent noindex et cessent d’exposer les snapshots lorsque la visibilité est privée

Contrôle du domaine

  • Un challenge DNS TXT ou HTTPS well-known permet de masquer ou republier l’historique sans compte
  • Le jeton brut n’est jamais stocké en stockage interne, seule son empreinte SHA-256 est conservée

Thèmes

  • Les fonds sombres résiduels du thème clair sont remplacés par des surfaces sémantiques compatibles clair, sombre et système
Version2.5.2
Stable

Compaction des blocs éditoriaux

La 2.5.2 compacte les blocs courts de la home et du dossier pour réduire les vides visuels, garder des cartes de dimensions plus régulières et éviter une page trop longue.

Home

  • La méthode et les dossiers publics sont rapprochés dans une grille simple à deux cartes de hauteur harmonisée sur desktop
  • Le flux mobile reste vertical et lisible, sans casser la logique éditoriale introduite en 2.5.1

Bas de dossier

  • Les preuves et la voie de correction ou clarification partagent désormais une même zone en deux colonnes quand l’espace le permet
  • Les blocs courts utilisent des dimensions plus régulières afin de réduire l’effet de page à rallonge

Continuité

  • Moteur, administration, patterns 2026.09.4 et schéma interne de stockage 2.3.1 inchangés ; aucune migration SQL
Version2.5.1
Stable

Stabilisation de la direction artistique

La 2.5.1 corrige les ruptures de direction artistique introduites par Core Domain Folder 2.5.0 sans modifier le moteur, les données ni le positionnement produit.

Hiérarchie éditoriale

  • Les introductions de section restent dans un flux vertical unique : repère, titre, explication, puis contenu
  • Les grands titres de section sont resserrés visuellement sans supprimer la hiérarchie sémantique H1 à H4

Cohérence des pages 2.5

  • Home, dossier, dossiers publics, angles, glossaire, historique et comparaison utilisent les composants visuels réellement définis
  • Les classes publiques 2.5 sans règles CSS correspondantes sont remplacées par le système éditorial existant

Continuité

  • Moteur, administration, patterns 2026.09.4 et schéma interne de stockage 2.3.1 inchangés ; aucune migration SQL
Version2.5.0
Stable

Core Dossier

La 2.5.0 repositionne Scanapse comme dossier public de domaine, place la temporalité et la preuve au premier plan et conserve le moteur de collecte comme couche interne.

Dossier

  • Résumé exécutif, vue courte en quatre blocs et six états de connaissance avant les douze angles détaillés
  • Historique et comparaison de snapshots avec changements apparus, modifiés, stables ou disparus

Preuve

  • Preuves, méthodes, limites et commandes de reproduction uniquement lorsque la vérification est réellement supportée
  • Exports JSON déterministes avec SHA-256, Markdown, partage par URL et impression

Dossiers publics

  • Constellation filtrée par catalogue curaté et cas publics affichés uniquement si une lecture réelle est stockée
  • Chemin de correction et de clarification rattaché aux dossiers publics

Acquisition

  • Nouvelle home centrée sur le bénéfice, les cas d’usage, la temporalité et les dossiers réels
  • Glossaire, pages publiques des douze angles et contexte LLM mis à jour

Continuité

  • Moteur, administration, patterns 2026.09.4 et schéma interne de stockage 2.3.1 inchangés ; aucune migration SQL
Version2.4.8
Stable

Index public et security.txt canonique

La 2.4.8 sépare le sitemap machine de sa lecture humaine, publie un index visuel FR/EN et normalise le point d’entrée security.txt sans toucher au moteur.

Plan du site

  • Nouvelle page /sitemap sombre et lisible, alimentée automatiquement par le même catalogue que sitemap.xml
  • Le sitemap XML reste strictement machine et conserve lastmod, hreflang et génération automatique

Sécurité

  • security.txt racine redirige vers /.well-known/security.txt, qui expose email, page Contact, expiration, langues, canonical et politique

Continuité

  • Moteur, administration, patterns 2026.09.4 et schéma interne de stockage 2.3.1 inchangés ; aucune migration SQL
Version2.4.7
Stable

Sitemap lisible et données structurées

La 2.4.7 remplace la présentation XSLT du sitemap par du CSS XML natif, ajoute des données structurées publiques et conserve le moteur, administration et stockage interne inchangés.

Sitemap

  • Le XML reste un sitemap standard mais devient lisible directement dans les navigateurs grâce à une feuille CSS locale sans XSLT
  • Le logo, les repères FR/EN, les dates, fréquences et priorités sont présentés sans JavaScript ni ressource tierce

SEO et IA

  • Les pages publiques indexables exposent un graphe JSON-LD WebSite, Organization et WebPage
  • Aucune activation automatique de HSTS preload : ce choix reste conditionné à la vérification préalable de tous les sous-domaines

Continuité

  • Moteur, administration, patterns 2026.09.4 et schéma interne de stockage 2.3.1 inchangés ; aucune migration SQL
Version2.4.6
Stable

Sitemap dynamique et catalogue public

La 2.4.6 centralise les pages publiques indexables et produit un sitemap FR/EN automatique, daté et lisible dans un navigateur sans modifier le moteur.

Plan du site

  • Le sitemap XML est généré depuis un catalogue unique de routes publiques et ne duplique plus une liste codée en dur
  • Chaque URL FR et EN conserve ses alternatives hreflang et reçoit un lastmod calculé depuis les fichiers source
  • Une feuille sitemap.xsl locale affiche le logo Scanapse et une vue lisible sans modifier la sémantique XML

Continuité

  • Routage FR/EN, fichiers LLM, moteur, administration, patterns 2026.09.4 et schéma interne de stockage 2.3.1 inchangés
  • Aucune migration SQL requise
Version2.4.5
Stable

Routage bilingue et découverte SEO/LLM

La 2.4.5 publie le français à la racine, l’anglais sous /en et aligne canonical, hreflang, sitemap, robots et fichiers de découverte LLM sans modifier le moteur.

Langues et SEO

  • Les routes publiques anglaises utilisent /en tandis que le français reste canonique à la racine
  • Les anciennes URLs ?lang= redirigent vers leur équivalent localisé sans dépendre de la langue du navigateur
  • Canonical, hreflang fr/en/x-default, Open Graph et sitemap utilisent la même topologie d’URL

Moteurs et LLM

  • Ajout de llms.txt, llms-full.txt, ai.txt et mise à jour de humans.txt
  • robots.txt autorise la découverte publique et exprime un refus d’entraînement lorsque des tokens dédiés existent
  • Aucun changement du moteur, des patterns 2026.09.4 ou du schéma interne de stockage 2.3.1
Version2.4.4
Stable

Pages éditoriales corrigées et mises en page isolées

La 2.4.4 corrige une collision CSS héritée qui comprimait certaines pages éditoriales et isole définitivement leur mise en page sans modifier la home, le rapport ni le moteur.

Mise en page

  • Les sections des huit pages éditoriales utilisent désormais un namespace dédié qui ne peut plus hériter de l’ancienne grille Editorial de main.css
  • Contact, Notre approche, Lire un domaine, Dossiers, Sécurité, Confidentialité, Mentions légales et Histoire retrouvent une largeur normale et des colonnes cohérentes
  • La feuille assets/css/editorial.css reste séparée de la home et du rapport pour sécuriser les prochaines itérations

Continuité

  • Home, rapport, moteur, patterns 2026.09.4 et schéma interne de stockage 2.3.1 inchangés
  • Aucune migration SQL requise
Version2.4.3
Stable

Lecture plus compacte et parcours public harmonisé

La 2.4.3 resserre le rapport, harmonise les pages publiques, simplifie les titres et remet l’histoire du produit dans le footer sans supprimer aucune route.

Rapport

  • Les blocs À regarder, contexte juridique, textes utiles et évolutions sont regroupés dans une grille compacte et responsive
  • Les relations visibles et les questions ouvertes sont rapprochées dans une lecture complémentaire plus courte
  • Le domaine et le titre principal utilisent davantage la largeur disponible pour éviter les titres hachés

Pages publiques

  • Titres, chapeaux et menus revus avec un vocabulaire plus simple et explicatif
  • La page Histoire reste sur /changelog et revient dans le footer, sans revenir dans le header
  • Accueil enrichi avec un mini exemple de dossier afin de transformer un ancien espace vide en explication utile
  • Moteur, patterns 2026.09.4 et schéma interne de stockage 2.3.1 inchangés

Refonte éditoriale

  • Lire un domaine, Dossiers, Notre approche, Contact, Sécurité, Confidentialité, Mentions légales et Histoire disposent désormais de compositions éditoriales propres
  • Une feuille de style éditoriale dédiée isole ces pages de la home et du rapport afin de faciliter les prochaines passes UX
  • Les mentions légales identifient Scanapse comme service porté par Koperateur Consulting, Mehdi Kachouri comme responsable du service et directeur de publication, et Infomaniak comme hébergeur
  • Les métadonnées SEO, les chapeaux et les titres sont réécrits pour privilégier des formulations descriptives sans bourrage de mots-clés
Version2.4.2
Stable

Lecture publique resserrée et preuves à la demande

La 2.4.2 simplifie le vocabulaire public, resserre les titres et espaces, filtre la trajectoire pour ne retenir que les évolutions utiles et recentre les exports sur les preuves.

Lecture

  • Navigation publique simplifiée : Lire un domaine, Dossiers et Notre approche
  • Nom de domaine renforcé dans le rapport, titres plus compacts et états vides masqués lorsqu’ils n’apportent rien
  • Trajectoire publique limitée aux évolutions utiles, avec normalisation des variations volatiles comme les nonces CSP

Preuves

  • Export JSON dédié aux preuves et impression limitée à la section preuves
  • Icônes de provenance ajoutées aux cartes de preuve
  • Moteur, pattern 2026.09.4 et schéma interne de stockage 2.3.1 inchangés
Version2.4.1
Stable

Nouvelle identité visuelle et trace constellation

La 2.4.1 renforce l’identité de Scanapse sans modifier le moteur : nouveau S constellation, baseline sous le logo, palette fonctionnelle et nouvelle hiérarchie graphique de l’accueil et du rapport.

Identité

  • Nouveau monogramme S composé de traces, nœuds et repères de lecture
  • Baseline Observer · Relier · Comprendre repositionnée sous le logo
  • Favicon aligné sur le nouveau signe et palette teal, cuivre et violette

Interface

  • Accueil et rapport enrichis avec motifs constellation, hiérarchie renforcée et accents fonctionnels
  • Douze angles conservés avec une identité plus marquée sans exposer davantage de technique
  • Moteur Evidence-first et schéma interne de stockage 2.3.1 inchangés
Version2.4.0
Stable

Dossier explicatif et contexte réglementaire

La 2.4.0 place le management de la connaissance au premier plan : comprendre les observations, qualifier le contexte de juridiction, relier avec prudence les cadres réglementaires, parcourir douze angles de connaissance puis remonter aux preuves.

Comprendre avant la technique

  • Le rapport public suit désormais Comprendre, Juridiction, Réglementation, 12 angles de connaissance et Preuves
  • Les compteurs techniques deviennent des informations secondaires et ne sont jamais présentés comme une note globale
  • Les preuves détaillées et métadonnées techniques sont repliées par défaut afin de préserver une lecture progressive

Juridiction et réglementation contextuelle

  • La juridiction publique utilise les états Établie, Probable ou À confirmer et affiche ses raisons et ses limites
  • Les textes réglementaires sont reliés au contexte observé avec des niveaux de pertinence et des sources officielles
  • Scanapse ne produit aucun verdict automatique de conformité, certification ou illégalité à partir d’un scan externe

Douze angles et identité visuelle

  • Les douze mappings moteur 2.3.1 restent inchangés mais deviennent publiquement douze angles de connaissance
  • Chaque angle possède un symbole SVG distinctif, un état de connaissance, une évolution et une explication Pourquoi, Comment, Finalité et Limites
  • Le moteur, les rulepacks et les mécanismes de corrélation fins restent côté serveur
Version2.3.4
Stable

Passe visuelle et premiers repères identitaires

La 2.3.4 renforce la hiérarchie visuelle de l’accueil et du rapport, introduit les premiers SVG des douze piliers et améliore l’explication des chiffres du dossier sans modifier le moteur.

Interface

  • Baseline courte dans le header à la place du badge de version
  • Accent couleur renforcé tout en conservant les thèmes clair, sombre et système
  • Ajout de repères SVG sur les douze piliers et continuité visuelle dans les panneaux de détail
Version2.3.2
Stable

Accueil centré sur la compréhension

La 2.3.2 refond le header, la page d’accueil et le footer autour du parcours utilisateur : scanner, comprendre les douze piliers, lire les mesures réelles et accéder aux preuves sans réintroduire de score global.

Accueil et navigation

  • Nouveau hero orienté utilité avec scan immédiat et aperçu du dossier de connaissance
  • Header simplifié avec accès direct à Scanner, Observatoire, Méthodologie, Changelog et Contact
  • Footer restructuré autour du produit, de la méthode, des ressources et de l’écosystème

Douze piliers et données réelles

  • Les douze piliers canoniques 2.3.1 sont présentés directement sur l’accueil avec leur question métier
  • Les statistiques et dernières observations restent alimentées par stockage interne et aucun chiffre de démonstration n’est fabriqué
  • Aucun score global de sécurité, confiance, souveraineté ou conformité n’est ajouté

Responsive et accessibilité

  • Mise en page mobile-first avec grille progressive des piliers et tableau d’observations transformé en cartes sur petit écran
  • Menu burger, focus clavier, thèmes clair/sombre/système et divulgation progressive restent conservés
Version2.3.1
Stable

Douze piliers pour expliquer les preuves

La 2.3.1 conserve toute la profondeur technique dans stockage interne et transforme la restitution publique en douze piliers fixes, lisibles et comparables dans le temps.

Lecture publique

  • Douze piliers fixes separent la synthese publique des modules techniques de collecte
  • Chaque pilier propose une explication simple, les observations associees et les details techniques a la demande
  • Les anciens indicateurs techniques restent accessibles par divulgation progressive et ne dominent plus la lecture

Memoire stockage interne

  • Definitions, mappings, snapshots et liens de preuves des piliers sont persistes de maniere additive
  • Chaque nouveau scan produit exactement douze snapshots, y compris lorsque le resultat est inconnu ou non teste
  • Les preuves sources restent autoritaires et une absence de preuve ne devient jamais un resultat favorable

administration et deploiement

  • administration peut inspecter les definitions, mappings et snapshots et simuler la projection sans modifier les preuves
  • La migration 2.3.0 vers 2.3.1 est additive et peut etre importee dans phpMyAdmin sur Infomaniak mutualise
Version2.3.0
Stable

Foundations for Continuous Evidence

La 2.3 transforme chaque mesure en historique horodate exploitable : scans immuables, watchlist explicite, automatisations administration, diagnostic stockage interne reel, baselines et recette privee chiffree.

Memoire et automatisation

  • Chaque scan conserve son horodatage, sa cible, son origine, ses versions moteur et regles, sa couverture et sa relation avec la mesure precedente
  • La watchlist administration est la seule source de rescans automatiques et le scheduler utilise des jobs idempotents avec leases
  • Le WebCron mutualisé appelle uniquement un point d’automatisation authentifié

Moteur prive et preuve

  • Les rulepacks declaratifs peuvent etre chiffres en stockage interne avec une cle conservee hors base et hors release publique
  • Aucun PHP, SQL, eval ou appel reseau arbitraire ne peut etre fourni par un rulepack
  • Les signaux publics exposent la conclusion et les preuves utiles sans distribuer les conditions privees

administration et UX

  • administration affiche la version stockage interne reelle, le schema lu, les tables et index critiques et un test transactionnel avec rollback
  • Les titres publics retrouvent une lecture naturelle sans retours forces par groupes de un ou deux mots
  • Les statistiques et historiques utilisent les scan_runs 2.3 comme memoire operationnelle principale
Version2.2.0
Stable

Strategic Evidence Engine

La 2.2 transforme Scanapse en moteur de connaissance strategique : cible canonique, memoire stockage interne, signaux correles, trajectoire, KM versionne et observatoire public sans score global.

Moteur et connaissance

  • Normalisation serveur des URL vers une cible canonique versionnee
  • Phases de scan mesurees et versionnees
  • stockage interne devient la memoire operationnelle des cibles, executions, changements, signaux et connaissances
  • Deep Scan reste reserve a la 2.5 au plus tard et n’est pas active implicitement
Version2.1.1
Stable

administration privacy, KM explicatif et stockage interne

La 2.1.1 ajoute le socle operationnel stockage interne, administration privacy-by-design, les messages locaux, les themes coherents et la lecture KM progressive.

Administration et connaissance

  • administration sans IP brute, User-Agent persistant ni fingerprint
  • stockage interne 10.11 pour statistiques, messages, KM et administration
  • Themes systeme, clair et sombre et rapport explicatif progressif
Version2.1.0
Stable

Tableau de bord intelligent Evidence-first

La 2.1 recentre Scanapse sur les preuves, les changements et les dependances sans score global.

Interface et methode

  • Tableau de bord intelligent avec lecture essentielle et experte
  • Fiches de preuve avec methode, source, fiabilite et limites
  • Contexte normatif et reglementaire explicatif sans verdict de conformite
Version2.0.1
Stable

Correctif Host pour le deploiement temporaire

La release autorise explicitement scanapse.com et almouatin.com tout en maintenant le refus de tout autre Host en production.

Securite et deploiement

  • Correction du 421 Misdirected Request lorsque la configuration locale n’est pas encore presente
  • Allowlist limitee a scanapse.com, www.scanapse.com, almouatin.com et www.almouatin.com
  • Le schema stockage interne et la methodologie Evidence-first restent en 2.0.0
Version2.0.0
Stable

Evidence-first, Knowledge Engine et observatoire de confiance

Scanapse separe maintenant les observations, les preuves, les affirmations, les relations, les signaux et la couverture de connaissance. La Constellation devient un observatoire et les anciens scores restent uniquement comme historique V1.

Connaissance

  • Sept etats epistemiques explicites, dont inconnu, contradictoire et non teste
  • Qualite observee et couverture de connaissance separees dans le Trust Profile
  • Aucune absence de preuve ne produit automatiquement un resultat favorable

Veille

  • Comparaison temporelle des observations avec changements apparus, disparus, modifies, stables ou non resolus
  • Constellation recentree sur couverture, signaux, inconnues, fournisseurs visibles et changements

Base et securite

  • Schema stockage interne 2.0.0 additif et backfill sans fabrication de donnees V2
  • Allowlist Host en production, HSTS explicite et garde de release contre les secrets
Version1.5.2
Stable

Persistance stockage interne, mur des scans et styles stabilisés

Correction des écritures PDO natives, synchronisation des rapports signés vers stockage interne, déduplication du mur par domaine et séparation des styles fonctionnels.

Base de données

  • Paramètres SQL uniques compatibles avec les requêtes préparées natives stockage interne
  • Écriture transactionnelle vérifiée des domaines, rapports et dépendances
  • Commandes doctor, probe et import-files pour contrôler et synchroniser la base

Interface

  • Retour à la feuille principale stable et isolation des composants de télémétrie, classement et modules
  • Un seul résultat public par domaine, avec le dernier scan et le nombre total de mesures
Version1.5.0
Stable

Télémétrie publique, classement en trois bandes et catalogue des modules

La page d’accueil expose maintenant les chiffres du moteur, un classement lisible en trois colonnes et le registre des derniers scans. La page Modules documente les douze analyseurs et les règles 2026.08.2 réduisent de nouveaux faux positifs.

Accueil et classement

  • Télémétrie du moteur avec domaines indexés, scans archivés, activité récente, meilleur score, couverture et dépendances visibles
  • Classement public en trois bandes configurables : 90 à 100, 50 à 89 et 0 à 49
  • Registre des derniers scans avec score, couverture, dépendances, variation et date
  • Les compteurs utilisent stockage interne lorsqu’elle est disponible et conservent le stockage fichier signé comme repli

Catalogue des modules

  • Nouvelle page détaillée pour les douze modules, leurs signaux, leurs sorties et les indices alimentés
  • Présentation du pipeline de collecte, qualification, corrélation et restitution
  • Limites de sécurité, budget réseau et contrat d’extension documentés

Précision du moteur

  • Version publique des règles de détection : 2026.08.2
  • Les ressources citées dans des exemples de code ou des chaînes JavaScript ne deviennent plus de fausses dépendances
  • Les chemins WordPress, Drupal et Joomla tiers ne suffisent plus à attribuer la technologie au domaine analysé
  • Un marqueur de challenge cité isolément ne suffit plus à classer une page comme protection active
  • Validation et normalisation conservatrice des lignes Set-Cookie

Validation

  • Tests de non-régression étendus sur le classement, la télémétrie, les modules et les faux positifs
  • Convention typographique contrôlée automatiquement avec le tiret simple
Version1.4.1
Stable

Stabilisation stockage interne et continuité des scans

La connexion stockage interne est corrigée, le diagnostic devient explicite et une panne de base optionnelle ne bloque plus la création du rapport signé sur fichier.

Correctifs stockage interne

  • Séparation des instructions de session SQL pour éviter une erreur de syntaxe lors de la connexion PDO
  • Contrôle explicite de la version du schéma avant toute lecture ou écriture
  • Codes de diagnostic sûrs pour pilote absent, hôte, authentification, droits, schéma et délai
  • Nouvelle commande php bin/database.php doctor sans exposition des identifiants

Continuité de service

  • Le mode fichier signé reste opérationnel lorsque stockage interne est attendue mais indisponible
  • Le blocage des scans exige désormais l’option explicite block_on_failure
  • L’état de santé distingue connexion, schéma, mode dégradé et blocage

Sécurité

  • Aucun secret SQL n’est affiché par les commandes de diagnostic ou la route de santé
  • La base reste protégée par des requêtes préparées et un compte applicatif à privilèges minimaux
Version1.4.0
Stable

Classement public, persistance stockage interne et règles de détection révisées

La page d’accueil expose désormais les derniers scans en trois niveaux lisibles. Le stockage devient hybride, avec stockage interne en option et conservation des rapports signés sur fichier. Les détecteurs privilégient des preuves structurelles pour réduire les faux positifs.

Classement

  • Tableau toujours visible sur l’accueil avec signaux maîtrisés, confiance à consolider et visibilité insuffisante
  • Classement fondé sur le Trust Index et le niveau de couverture, avec historique et variation
  • Alias /classement et /ranking vers la page Constellation

Données

  • Schéma stockage interne versionné pour les domaines, rapports, dépendances et migrations
  • Mode hybride fichier et stockage interne avec repli automatique si la base optionnelle devient indisponible
  • Commande d’import des anciens rapports JSON signés vers stockage interne
  • Classement manuel et masquage public optionnels par domaine sans modifier le rapport signé

Précision

  • Version publique des règles de détection : 2026.08.1
  • Détection des technologies fondée sur les chemins de ressources, attributs et marqueurs d’exécution
  • Détection des protections distantes pondérée par preuves structurelles
  • Noms de cookies sensibles reconnus par jetons complets plutôt que par fragments génériques
  • Suppression du faux rattachement Fastly provoqué par un en-tête Varnish générique

Sécurité et validation

  • Identifiants SQL préparés, contraintes de schéma, préfixe validé, compte SQL à privilèges minimaux et TLS optionnel
  • Le mode stockage interne obligatoire écrit en base avant de publier le rapport fichier et l’état public masque les erreurs SQL détaillées
  • Numéro de version du moteur et des règles conservé dans chaque rapport et chaque ligne stockage interne
  • Tests de non-régression ajoutés pour les faux positifs, le classement, le mode hybride et les titres
  • Convention typographique uniforme avec le tiret simple dans l’ensemble du projet
Version1.3.0
Stable

Constellation, trajectoires et chaîne de confiance

Scanapse devient un observatoire continu : les derniers rapports, leurs évolutions et les dépendances dominantes sont réunis sans transformer l’indice en palmarès opaque.

Nouveau

  • Page Constellation avec filtres, carte SVG, bandes de lecture et derniers signaux
  • Historique enrichi par domaine avec courbe du Trust Index, écarts et instantanés
  • Page Changelog bilingue alimentée par une source structurée
  • Aperçu des derniers rapports sur l’accueil

Moteur

  • Deux modules supplémentaires : maîtrise des ressources tierces et confiance de messagerie
  • Mesure SRI, contenus mixtes, destinations de formulaires, iframes et liens nouvel onglet
  • Lecture DNS étendue à TLS-RPT, MTA-STS et BIMI lorsque la messagerie est annoncée
  • Schéma de rapport 1.3 et calcul des catégories rééquilibré

Sécurité et qualité

  • La Constellation ne publie que des résumés minimisés et jamais les preuves brutes
  • Exclusion configurable de domaines du mur public
  • Tests ajoutés pour les nouveaux modules, l’historique et l’agrégation publique
Version1.2.2
Stable

Stabilisation du moteur sur hébergement mutualisé

Reconstruction de la livraison complète, isolation des modules et continuité de rapport en cas d’échec réseau.

Corrections

  • Suppression du conflit entre le dossier de modules et la route publique /modules
  • Repli du transport cURL vers le client socket sécurisé
  • Erreurs DNS, TLS et HTTP converties en couverture partielle ou minimale
Version1.1.0
Archivée

Refonte éditoriale et fin des faux rejets anti-abus

Titres raccourcis, hiérarchie visuelle plus contenue et formulaire de scan rendu compatible avec les gestionnaires de mots de passe.

Interface

  • Suppression du champ masqué qui déclenchait des faux positifs anti-robot
  • Réduction des titres et des espacements sur ordinateur et mobile
  • Niveaux de couverture explicités dans chaque rapport
Version1.0.1
Archivée

Déploiement portable

Suppression du domaine canonique codé en dur et adaptation automatique à l’hôte actif.

Déploiement

  • Canonical, sitemap, robots et security.txt générés depuis le domaine courant
  • Compatibilité racine de domaine ou sous-dossier
Version1.0.0
Archivée

Première base Trust et Dependency

Architecture Flat PHP, dix modules passifs, rapports signés et interface noire ou blanche.

Fondations

  • Routeur frontal index.php et pages isolées
  • CSP stricte, validation SSRF, limitation de débit et stockage HMAC
  • Cartographie des fournisseurs et cinq dimensions de confiance
VersionOrigine
Archivée

Naissance du projet Scanapse

Le 11 decembre 2025 marque le point de depart documente du projet. Les mois suivants comprennent plusieurs essais et orientations exploratoires ; aucune numerotation intermediaire n’est inventee lorsque les traces ne permettent pas de l’établir.

Periode experimentale

  • Premieres explorations autour de l’OSINT, de l’analyse locale et de la structuration de sources
  • La chronologie detaillee reprend uniquement les jalons ensuite documentes par les releases conservees
Avant une mise en ligne

Comment une version arrive en ligne

La simplicité de Scanapse n’exclut pas la discipline. Une livraison doit rester reproductible, relisible et compatible avec l’hébergement prévu.

01

Cadrer

Définir l’objectif de la modification, ce qu’elle change pour le lecteur et ce qu’elle ne doit pas modifier.

02

Isoler

Limiter la portée du changement afin de ne pas transformer une amélioration locale en régression ailleurs.

03

Vérifier

Contrôler les tests, la syntaxe, les routes, les assets, les traductions et les comportements importants avant livraison.

04

Livrer

Reconstruire les paquets, vérifier leur intégrité et garder un chemin de mise à jour compréhensible.

Un changement utile doit rester explicable Scanapse conserve son histoire pour permettre de comprendre pourquoi une lecture a changé entre deux versions. Une évolution d’interface ou de règle ne doit jamais rendre les anciens dossiers incompréhensibles.