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.
HISTOIRE / Histoire du produit
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.
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.
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.
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.
Les configurations, contacts techniques et URLs canoniques convergent vers scanapse.com, tout en conservant la trace du déploiement temporaire.
Le Canary public ajoute à scanapse.com une preuve cryptographique datée, avec historique et continuité vérifiables.
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.
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.
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.
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.
La 2.9.4 reprend un run interrompu depuis ses checkpoints durables sans recollecter les phases déjà acceptées.
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.
La 2.9.2.1 corrige la finalisation technique qui pouvait laisser une lecture terminée affichée comme toujours en cours.
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.
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.
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.
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.
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é.
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.
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.
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é.
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.
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.
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.
La 2.7.3 harmonise la page Canary publique et le cockpit administration avec le design Scanapse, sans modifier le protocole cryptographique P1.8.
P1.8 introduit le Canary signé par délégation Ed25519, son automatisation administration/WebCron et finalise les exports professionnels vérifiables.
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.
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.
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.
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é.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
La 2.1 recentre Scanapse sur les preuves, les changements et les dependances sans score global.
La release autorise explicitement scanapse.com et almouatin.com tout en maintenant le refus de tout autre Host en production.
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.
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.
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.
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.
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.
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.
Reconstruction de la livraison complète, isolation des modules et continuité de rapport en cas d’échec réseau.
Titres raccourcis, hiérarchie visuelle plus contenue et formulaire de scan rendu compatible avec les gestionnaires de mots de passe.
Suppression du domaine canonique codé en dur et adaptation automatique à l’hôte actif.
Architecture Flat PHP, dix modules passifs, rapports signés et interface noire ou blanche.
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.
La simplicité de Scanapse n’exclut pas la discipline. Une livraison doit rester reproductible, relisible et compatible avec l’hébergement prévu.
Définir l’objectif de la modification, ce qu’elle change pour le lecteur et ce qu’elle ne doit pas modifier.
Limiter la portée du changement afin de ne pas transformer une amélioration locale en régression ailleurs.
Contrôler les tests, la syntaxe, les routes, les assets, les traductions et les comportements importants avant livraison.
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.