grayTerminal-sh 8fcd6b0e0d docs/ update

2026-07-24 14:40:11 +02:00

8.5 KiB

Raw Blame History

Roadmap

Dernière mise à jour : 2026-07-24
État du projet : développement actif
Schéma SQLite courant : V10
Usage opérationnel : non prêt pour la production

1. Source de vérité

La feuille de route détaillée est suivie dans Forgejo :

https://git.labfytools.com/fy59/labfy-investigation/issues

Ce document donne une vue stratégique courte. Il ne duplique pas la liste complète des tickets fermés.

Pour connaître l'état d'une fonctionnalité :

consulter le code et les tests sur main ;
consulter les migrations SQL ;
consulter les tickets Forgejo ;
utiliser cette roadmap comme synthèse.

Un ticket ouvert décrit un chantier en cours. Il ne prouve pas que toutes ses fonctions sont déjà disponibles.

2. Vision

Labfy Investigation doit devenir un poste de travail local d'investigation numérique et d'OSINT capable de :

préserver les preuves originales ;
organiser les données d'une enquête autonome ;
extraire et normaliser des informations ;
créer des entités et des relations traçables ;
représenter les données sous forme de graphe ;
conserver la provenance des traitements ;
exécuter des outils externes de manière contrôlée ;
présenter les résultats à l'enquêteur avant intégration ;
produire des rapports compréhensibles et transmissibles.

Le logiciel doit rester :

libre ;
local ;
documenté ;
testable ;
maintenable ;
utilisable avec des dépendances optionnelles ;
compatible à terme avec une distribution Ubuntu institutionnelle.

3. Principes non négociables

Une enquête est autonome

MonEnquete/
├── 00_BaseDeDonnees/
│   └── Enquete.sqlite
├── 01_Preuves_Originales/
├── 02_Preuves_Traitees/
├── 03_Chronologie/
├── 04_Entites/
└── 05_Rapports/

SQLite est la source de vérité

Le graphe, la barre latérale, les tableaux et les futures vues chronologiques sont des projections des mêmes données persistées.

Les preuves originales sont immuables

Toute transformation produit un fichier ou un objet dérivé.

Toute donnée importante possède une provenance

Le système doit pouvoir expliquer :

ce qui a été trouvé ;
quand ;
à partir de quelle preuve ou cible ;
avec quel outil et quelle version ;
avec quels paramètres ;
quelle sortie brute a été produite ;
quelle interprétation a été confirmée ou rejetée.

L'enquêteur garde le contrôle

Une sortie OCR, une donnée OSINT ou une corrélation automatique reste une proposition tant qu'elle n'a pas été explicitement confirmée.

L'interface ne doit pas être bloquée

Les traitements longs sont exécutés en arrière-plan et restent annulables lorsque cela est techniquement possible.

Les outils externes restent optionnels

L'absence d'un outil réduit les capacités disponibles, mais ne doit pas empêcher le lancement de l'application.

4. Socle déjà implémenté

La branche main contient notamment :

création, validation et ouverture d'enquêtes ;
session d'enquête remplaçable proprement ;
infrastructure SQLite et migrations jusqu'à V10 ;
couche Database, DAO et services métier ;
import de preuves avec copie contrôlée et SHA-256 ;
vérification d'intégrité et reclassement des preuves ;
modèles et DAO d'entités et de relations ;
associations preuves–entités et preuves–relations ;
chargement asynchrone du graphe ;
déplacement des nœuds et persistance du viewport ;
registre, catalogue et exécution sécurisée d'outils externes ;
gestionnaire de tâches et panneau d'activité ;
premiers pivots DNS avec propositions puis intégration ;
conservation de la provenance des exécutions OSINT ;
comptes sociaux structurés ;
personnes, rôles d'enquête et identité usurpée ;
extractions liées aux preuves et aux entités ;
analyse EML, IBAN, métadonnées ExifTool et PDF ;
types canoniques de relations ;
vocabulaire contrôlé ;
table V10 bank_account_entities ;
premiers composants du pipeline EML.

Cette liste est une synthèse et non un contrat de stabilité.

5. Chantier actif

Ticket #107 — Pivot e-mail forensique

Statut :

PARTIEL

Les briques préparatoires existent, mais le flux complet reste à terminer.

Objectif principal :

preuve EML
    ↓
vérification d'intégrité
    ↓
analyse des en-têtes et de la structure MIME
    ↓
extraction sécurisée des pièces jointes
    ↓
SHA-256, type MIME et métadonnées
    ↓
OCR et détection d'indicateurs
    ↓
normalisation sans perte de la valeur brute
    ↓
interface de révision
    ↓
confirmation explicite
    ↓
intégration transactionnelle
    ↓
rafraîchissement des vues et du graphe

Priorités immédiates :

terminer l'extraction MIME robuste ;
conserver les pièces jointes comme fichiers dérivés ;
réunir EML, OCR, IBAN et ExifTool dans un pipeline unique ;
terminer l'interface de révision ;
persister uniquement les propositions confirmées ;
réutiliser ou créer les entités correspondantes ;
créer les relations canoniques avec leur provenance ;
garantir un rollback complet en cas d'échec ;
rafraîchir la barre latérale et le graphe ;
compléter les tests de migration et d'intégration ;
mettre à jour la documentation avec l'état réellement livré.

Le ticket reste ouvert tant que son flux complet et ses critères d'acceptation ne sont pas validés.

6. Inventaire permanent

Ticket #42 — Arsenal OSINT

Statut :

INVENTAIRE PERMANENT

Ce ticket sert à qualifier les outils et services potentiellement intégrables.

Un outil n'est pas ajouté en masse. Son intégration suit un besoin concret :

compréhension manuelle de la technique ;
vérification du cadre légal ;
vérification de la licence ;
vérification Arch Linux et Ubuntu ;
création d'un ticket dédié ;
développement d'un adaptateur ;
conservation des sorties brutes ;
normalisation des résultats ;
tests avec données synthétiques ;
documentation de ses limites.

Le ticket #42 reste ouvert tant que l'inventaire est utile au projet.

7. Axes suivants

L'ordre exact dépendra des tickets créés dans Forgejo.

7.1 Fiabilité des données

fixture dédiée V9 vers V10 ;
tests de rollback pour les migrations récentes ;
PRAGMA integrity_check et PRAGMA foreign_key_check systématiques ;
contrôle des références orphelines ;
vérification des sorties brutes persistées ;
journal d'audit plus complet.

7.2 Graphe d'enquête

améliorer la lisibilité des grands graphes ;
filtrer par type, date, source, statut et confiance ;
enregistrer des vues ;
créer et éditer des relations depuis le canvas ;
synchroniser toutes les modifications avec SQLite ;
préparer l'export du graphe.

7.3 Recherche et chronologie

recherche transversale ;
filtres structurés ;
chronologie liée aux preuves, entités et relations ;
notes, pistes et hypothèses clairement séparées des faits.

7.4 Rapports et transmission

rapport Markdown structuré ;
export PDF ;
annexes et empreintes ;
manifeste d'enquête ;
export autonome ;
expurgation et anonymisation ;
présentation adaptée aux forces de l'ordre.

7.5 Distribution Ubuntu

classifier les dépendances obligatoires et optionnelles ;
produire un script de compilation robuste ;
produire un paquet .deb ;
fonctionner avec des dépôts institutionnels restreints ;
documenter l'installation hors ligne ;
tester Wayland et X11 ;
éviter toute dépendance AUR obligatoire.

8. Critères de qualité communs

Un chantier n'est pas terminé tant que :

le code compile ;
les tests ciblés passent ;
la suite complète passe ;
les erreurs sont présentées correctement ;
l'interface reste réactive ;
les données brutes sont préservées ;
la provenance est suffisante ;
aucune donnée réelle d'enquête n'est présente dans le dépôt ;
la documentation reflète l'état livré.

Validation recommandée :

make clean
make -j8
make -j8 test
git diff --check

Le retour à une compilation séquentielle n'est utilisé que si la parallélisation provoque un échec réel.

9. Historique

L'historique détaillé du développement se trouve dans :

les tickets fermés Forgejo ;
les commits ;
CHANGELOG.md ;
les audits de schéma versionnés.

Les anciennes listes de tickets ne doivent pas être recopiées dans ce fichier, car elles deviennent rapidement obsolètes.

8.5 KiB Raw Blame History Unescape Escape