fy59/labfy-investigation
1
0
Fork 0
Code Issues 3 Pull requests Projects Releases Packages Wiki Activity Actions

docs/ update

Browse source
This commit is contained in:
grayTerminal-sh 2026-07-24 14:40:11 +02:00
parent 613d2096bc
commit 8fcd6b0e0d
12 changed files with 7658 additions and 5029 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

871
docs/ARCHITECTURE.md
View file

@ -1,440 +1,619 @@
# Architecture # Architecture
Version : 2.0 > **Version :** 3.0
> **Dernière mise à jour :** 2026-07-24
Dernière mise à jour : 2026-07-14 > **Schéma SQLite courant :** V10
> **Statut :** architecture courante
Auteur : fy59
--- ---
# Objectif ## 1. Objectif
Ce document décrit l'architecture logicielle de **Labfy Investigation**. Ce document décrit l'architecture logicielle actuelle de Labfy Investigation.
Il constitue le document de référence du projet. Il définit :
Son objectif est de : - les responsabilités des couches ;
- la direction autorisée des dépendances ;
- le cycle de vie d'une enquête ;
- la place de SQLite et du système de fichiers ;
- le fonctionnement des tâches asynchrones ;
- l'intégration des outils externes ;
- la projection graphique des données ;
- les règles de sécurité et de traçabilité.
- définir les responsabilités de chaque module ; La documentation détaillée du schéma SQLite se trouve dans :
- garantir une architecture cohérente ;
- limiter le couplage entre les composants ;
- faciliter les évolutions futures ;
- permettre la réalisation de tests unitaires indépendants de l'interface graphique.
---
# Vision
Labfy Investigation est un logiciel libre d'investigation numérique,
développé en **C17** avec **GTK4**.
Le projet a pour objectif de fournir un environnement professionnel
permettant de gérer une enquête numérique de bout en bout :
- création d'une enquête ;
- collecte des preuves ;
- organisation des informations ;
- analyse ;
- génération de rapports.
L'application est conçue pour être utilisée aussi bien par :
- des particuliers ;
- des journalistes ;
- des analystes OSINT ;
- des experts judiciaires ;
- des forces de l'ordre.
---
# Principes fondamentaux
## Une enquête = un dossier autonome
Chaque enquête contient tout ce qui est nécessaire à son fonctionnement.
```text
docs/database/DATABASE_ARCHITECTURE.md
docs/database/SCHEMA_AUDIT_CURRENT.md
``` ```
MonEnquete/
---
## 2. Vision
Labfy Investigation est un poste de travail local d'investigation numérique et
d'OSINT développé en C17 avec GTK4.
Une enquête doit pouvoir être :
- créée ;
- ouverte ;
- copiée ;
- sauvegardée ;
- archivée ;
- transmise ;
avec son dossier et sa base SQLite.
Le logiciel n'est pas encore prêt pour un usage opérationnel en production.
Les formats et interfaces peuvent évoluer tant que le projet reste en
développement actif.
---
## 3. Sources de vérité
Pour déterminer l'état réel d'une fonction :
1. code de `main` ;
2. tests ;
3. migrations SQL ;
4. commits ;
5. tickets Forgejo ;
6. documentation.
Les documents historiques ne décrivent pas l'état courant.
SQLite est la source de vérité des données structurées d'une enquête.
Le système de fichiers est la source de vérité des fichiers originaux et
dérivés référencés par la base.
Le graphe, la barre latérale et les autres vues ne possèdent pas leur propre
copie métier indépendante.
---
## 4. Principes fondamentaux
### 4.1 Une enquête est autonome
```text
MonEnquete/
├── 00_BaseDeDonnees/ ├── 00_BaseDeDonnees/
│ └── Enquete.sqlite │ └── Enquete.sqlite
│
├── 01_Preuves_Originales/ ├── 01_Preuves_Originales/
├── 02_Preuves_Traitees/ ├── 02_Preuves_Traitees/
├── 03_Chronologie/ ├── 03_Chronologie/
├── 04_Entites/ ├── 04_Entites/
├── 05_Rapports/ └── 05_Rapports/
│
└── ...
``` ```
Une enquête peut être : Aucune donnée métier d'une enquête ne doit être stockée dans une base globale.
- copiée ; Les préférences générales de l'application, lorsqu'elles seront ajoutées,
- déplacée ; resteront séparées des données d'enquête.
- synchronisée ;
- sauvegardée ;
- archivée ;
- transmise.
Aucune dépendance externe ne doit être nécessaire. ### 4.2 Les preuves originales sont immuables
L'application ne modifie jamais un fichier original importé.
Toute annotation, conversion, extraction, analyse ou expurgation produit un
objet dérivé.
### 4.3 Le cœur ne dépend pas de GTK
Les modèles, DAO et services métier doivent pouvoir être testés sans lancer
l'interface graphique.
### 4.4 Les widgets ne contiennent pas la logique métier
Un widget :
- affiche un état ;
- collecte une intention utilisateur ;
- déclenche une action de l'application ;
- présente le résultat.
Il ne :
- construit pas de requête SQL ;
- ne déplace pas directement une preuve ;
- ne lance pas une commande shell ;
- ne décide pas seul de la validation métier d'une donnée.
### 4.5 Les traitements longs sont asynchrones
Le thread GTK principal ne réalise pas les opérations longues.
### 4.6 Les résultats automatiques restent révisables
Une donnée OCR, OSINT ou dérivée ne devient pas un fait confirmé sans action
explicite lorsque le domaine l'exige.
--- ---
## Les preuves originales sont immuables ## 5. Architecture en couches
Les preuves originales ne doivent jamais être modifiées. ```text
┌──────────────────────────────────────────────┐
Toute opération produisant : │ Interface GTK4 │
│ views / widgets │
- une annotation ; └──────────────────────┬───────────────────────┘
- une conversion ; │ intentions et affichage
- une extraction ; ┌──────────────────────▼───────────────────────┐
- une analyse ; │ Application et contrôleurs │
│ cycle de vie, session, navigation, messages │
doit produire un nouveau fichier dans un espace dédié. └──────────────────────┬───────────────────────┘
│ orchestration
--- ┌──────────────────────▼───────────────────────┐
│ Services métier et tâches │
## Le Core est indépendant de GTK │ import, relations, OSINT, EML, graphe │
└───────────────┬───────────────────┬──────────┘
La logique métier ne dépend jamais de l'interface graphique. │ │
┌───────────────▼────────────┐ ┌────▼─────────────────┐
Le Core doit pouvoir être testé sans lancer GTK. │ DAO │ │ Adaptateurs │
│ requêtes métier SQLite │ │ fichiers / CLI / API│
--- └───────────────┬────────────┘ └────┬─────────────────┘
│ │
## Les Widgets ne connaissent pas le métier ┌───────────────▼───────────────────▼──────────┐
│ Infrastructure │
Les widgets affichent uniquement les informations fournies. │ SQLite / transactions / système de fichiers │
└──────────────────────────────────────────────┘
Ils ne manipulent jamais :
- SQLite ;
- le système de fichiers ;
- les preuves.
---
## Développement incrémental
Chaque ticket doit :
- compiler sans warning ;
- être documenté ;
- être testé ;
- ne pas casser les fonctionnalités existantes.
---
# Architecture générale
```
Utilisateur
│
▼
+-----------------+
| GTK4 |
| Views / Widgets |
+-----------------+
│
▼
+-----------------+
| Application |
+-----------------+
│
▼
+---------------------------+
| InvestigationProject |
+---------------------------+
│ │
▼ ▼
FileSystem Database
│ │
└────────┬────────┘
▼
Investigation
│
▼
Models
``` ```
Cette architecture permet une séparation claire entre : Les modèles métier circulent entre ces couches sans dépendre de GTK ni de
SQLite.
- l'interface graphique ;
- la logique métier ;
- le stockage.
--- ---
# Organisation du projet ## 6. Organisation du dépôt
``` ```text
labfy-investigation/ database/ scripts SQL versionnés et schéma courant
docs/ architecture, conventions et procédures
include/ include/core/ interfaces des services et du cœur
src/ include/dao/ interfaces d'accès métier aux données
include/database/ interfaces de l'infrastructure SQLite
database/ include/models/ modèles métier
docs/ include/views/ fenêtres et dialogues GTK
resources/ include/widgets/ widgets réutilisables
tests/ resources/ ressources de l'application
tools/ src/core/ services, tâches et orchestration métier
src/dao/ requêtes métier SQLite
README.md src/database/ connexion, schéma, statements, transactions, erreurs
LICENSE src/models/ implémentation des modèles
CHANGELOG.md src/views/ fenêtres et dialogues GTK
CONTRIBUTING.md src/widgets/ composants GTK réutilisables
Makefile tests/ tests unitaires et d'intégration ciblée
``` ```
--- ---
# Organisation du code ## 7. Responsabilités des modules
``` ### 7.1 Point d'entrée et application
src/
core/ `src/main.c` démarre l'application.
database/
models/ La couche application :
views/
widgets/ - gère le cycle de vie GTK ;
utils/ - crée la fenêtre principale ;
- ouvre ou crée une enquête ;
- remplace la session active uniquement après succès ;
- coordonne les messages utilisateur ;
- relie les services métier aux vues ;
- ferme proprement les ressources.
Une erreur d'ouverture ne doit pas détruire une session valide déjà active.
### 7.2 Core et services métier
`src/core` contient notamment :
- représentation et validation d'une enquête ;
- session et projet d'enquête ;
- construction de l'arborescence ;
- tâches d'arrière-plan ;
- gestionnaire de tâches ;
- registre et catalogue d'outils ;
- exécution de processus ;
- hachage et copie de fichiers ;
- import et intégrité des preuves ;
- services d'entités et de relations ;
- chargement du graphe ;
- actions OSINT ;
- analyse EML, IBAN, OCR, métadonnées et PDF ;
- vocabulaire contrôlé ;
- pipeline EML.
Un service métier peut coordonner plusieurs DAO, une transaction et une
opération de fichier.
### 7.3 Modèles
`src/models` représente les données manipulées par l'application.
Les modèles :
- ne lancent pas de requête SQL ;
- ne dépendent pas de GTK ;
- valident leurs invariants lorsque cela leur appartient ;
- exposent une API claire de création, lecture et destruction.
### 7.4 Infrastructure Database
`src/database` gère :
- ouverture et fermeture de SQLite ;
- activation des clés étrangères ;
- lecture de la version ;
- installation du schéma ;
- migrations ;
- statements préparés ;
- transactions ;
- traduction structurée des erreurs.
Cette couche ne contient pas l'orchestration complète d'une fonctionnalité
utilisateur.
### 7.5 DAO
`src/dao` contient les requêtes métier.
Un DAO :
- transforme des lignes SQLite en modèles ;
- utilise des statements préparés ;
- ne dépend pas de GTK ;
- ne lance pas d'outil externe ;
- ne décide pas seul d'un workflow multi-étapes ;
- expose des erreurs exploitables par le service appelant.
### 7.6 Vues et widgets
`src/views` contient les fenêtres et dialogues complets.
`src/widgets` contient les composants réutilisables, notamment :
- barre latérale ;
- arborescence ;
- panneau de tâches ;
- listes ;
- espace de travail ;
- graphe.
Les vues et widgets ne deviennent pas propriétaires des données persistées.
---
## 8. Cycle de vie d'une enquête
### 8.1 Création
```text
sélection du dossier
↓
validation du chemin
↓
création de l'arborescence
↓
initialisation transactionnelle de SQLite V10
↓
création de l'identité de l'enquête
↓
ouverture d'une session
↓
construction des vues
``` ```
--- Un échec laisse l'application dans un état cohérent et nettoie les artefacts
partiels prévus par le service.
# Description des modules ### 8.2 Ouverture
## Core ```text
sélection du dossier
↓
validation de l'arborescence
↓
ouverture de SQLite
↓
lecture de schema_version
↓
migration éventuelle
↓
chargement de l'enquête
↓
construction de l'arborescence et du graphe
↓
remplacement atomique de la session active
```
Le Core pilote l'application. Une base plus récente que l'application doit être refusée.
Il ne dépend jamais de GTK. ### 8.3 Fermeture
Il gère : La fermeture libère :
- le cycle de vie de l'application ;
- l'ouverture d'une enquête ;
- la fermeture d'une enquête ;
- les interactions entre les modules.
---
## InvestigationProject
InvestigationProject est le point d'entrée métier.
Il est responsable de :
- créer une enquête ;
- ouvrir une enquête ;
- fermer une enquête ;
- valider une enquête ;
- initialiser SQLite ;
- gérer le système de fichiers.
Toute manipulation d'une enquête passe obligatoirement par ce module.
---
## Database
Le module Database est responsable du stockage.
Il gère :
- les tâches ;
- les références de modèles ;
- la connexion SQLite ; - la connexion SQLite ;
- le schéma ; - la session ;
- les migrations ; - les widgets dépendants ;
- les transactions. - les ressources externes.
Aucune requête SQL ne doit apparaître ailleurs.
--- ---
## Models ## 9. Gestion des preuves
Les modèles représentent les objets métier. ### 9.1 Import
Par exemple : Le flux d'import vise à garantir l'intégrité :
- InvestigationNode ```text
- Preuve validation de la source
- Entité ↓
- Relation SHA-256 source
- Chronologie ↓
copie vers une destination contrôlée
Ils ne connaissent ni GTK ni SQLite. ↓
SHA-256 destination
--- ↓
écriture SQLite
## Views ↓
validation ou nettoyage
Les vues représentent les fenêtres de l'application.
Elles ne contiennent aucune logique métier.
---
## Widgets
Les widgets sont des composants GTK réutilisables.
Par exemple :
- Sidebar
- Workspace
- InvestigationTreeView
- Toolbar
- Statusbar
---
## Utils
Fonctions génériques.
Exemples :
- SHA-256
- Dates
- Gestion des fichiers
- Journalisation
Les utilitaires ne doivent dépendre d'aucun module métier.
---
# Flux de données
Lorsqu'un utilisateur ouvre une enquête :
```
Utilisateur
↓
GTK
↓
Application
↓
InvestigationProject
↓
FileSystem
↓
Database
↓
Investigation
↓
GUI
``` ```
Le flux est toujours unidirectionnel. L'import groupé traite les fichiers de manière contrôlée et produit un bilan
détaillé.
### 9.2 Reclassement
Un changement de type peut impliquer :
- vérification préalable de l'intégrité ;
- déplacement cohérent du fichier interne ;
- mise à jour SQLite ;
- rollback et restauration en cas d'échec.
L'UUID, l'empreinte et l'historique ne doivent pas être recréés silencieusement.
### 9.3 Dérivés
Les extractions, OCR, pièces jointes EML et versions traitées restent reliés à
leur preuve source.
--- ---
# Dépendances ## 10. Tâches asynchrones
Les dépendances suivent toujours cette règle : Les tâches longues utilisent l'infrastructure de tâche d'arrière-plan et le
gestionnaire de tâches.
``` Une tâche expose selon ses besoins :
Widgets
│ ```text
▼ pending
Views running
│ completed
▼ failed
Application cancelled
│
▼
InvestigationProject
│
┌──┴───────┐
▼ ▼
Database FileSystem
│
▼
Models
``` ```
Les dépendances inverses sont interdites. Elle doit :
- éviter l'accès direct à GTK depuis un thread de travail ;
- transférer le résultat vers le thread principal ;
- conserver une erreur structurée ;
- libérer ses ressources même après annulation ;
- ne pas laisser une transaction ouverte ;
- ne pas écrire simultanément dans SQLite sans coordination.
--- ---
# Gestion de la mémoire ## 11. Outils externes et OSINT
Chaque allocation possède une fonction de libération correspondante. ### 11.1 Registre et catalogue
Les responsabilités de libération sont clairement définies. Le registre détecte la présence et la version des outils.
Aucun module ne libère une ressource qu'il n'a pas créée. Le catalogue décrit les capacités et les actions compatibles avec une
sélection.
Une dépendance absente désactive l'action concernée sans empêcher le démarrage.
### 11.2 Exécution
Les outils sont lancés avec `GSubprocess`.
Les arguments sont transmis séparément.
Aucune commande shell dynamique n'est construite.
Les exécutions persistées peuvent conserver :
- outil et version ;
- cible et paramètres ;
- dates ;
- code de retour ;
- sorties brutes ;
- empreintes ;
- statut d'analyse ;
- objets intégrés.
### 11.3 Intégration
Une action OSINT suit le modèle :
```text
sélection
↓
validation de l'action
↓
tâche asynchrone
↓
sortie brute
↓
propositions normalisées
↓
révision
↓
intégration transactionnelle
↓
rafraîchissement des vues
```
--- ---
# Gestion des erreurs ## 12. Graphe d'enquête
Les erreurs remontent toujours jusqu'à Application. Le graphe est une projection de SQLite.
L'interface graphique est uniquement responsable de leur affichage. Il représente notamment :
- entités ;
- relations ;
- preuves ou extractions lorsque le modèle le prévoit ;
- positions et viewport persistés séparément des données métier.
Les coordonnées et le zoom sont un état de présentation.
Une modification du graphe qui change le métier doit passer par un service et
être persistée dans SQLite avant d'être considérée comme acquise.
Le graphe ne doit jamais inventer une relation seulement parce que deux nœuds
sont proches visuellement.
--- ---
# Tests ## 13. Pivot EML
Chaque nouveau module doit pouvoir être testé indépendamment. Statut :
Les tests unitaires ne doivent jamais dépendre de GTK. ```text
PARTIEL
```
La branche contient des briques d'analyse EML, d'extraction MIME, d'IBAN, OCR,
ExifTool, vocabulaire contrôlé, propositions bancaires et pipeline de tâche.
Le flux cible est :
```text
EML original
↓
en-têtes et MIME
↓
pièces jointes dérivées
↓
empreintes et métadonnées
↓
OCR et indicateurs
↓
valeurs brutes + normalisées + dérivées
↓
révision humaine
↓
intégration transactionnelle
```
Les valeurs brutes restent immuables.
Une IP de relais SMTP ne doit pas être présentée comme l'adresse personnelle
d'un suspect.
Une donnée bancaire observée ne prouve pas l'identité de l'auteur d'une fraude.
Le ticket Forgejo #107 reste la référence fonctionnelle du chantier.
--- ---
# Évolutivité ## 14. Erreurs et journalisation
L'architecture doit permettre l'ajout de nouveaux modules sans modifier les composants existants. Les couches basses produisent des erreurs structurées.
Les nouvelles fonctionnalités doivent privilégier l'extension plutôt que la modification. Les services ajoutent le contexte métier.
L'application décide :
- du journal technique ;
- du message utilisateur ;
- du maintien ou du remplacement de la session ;
- de la possibilité de réessayer.
Les messages ne doivent pas divulguer inutilement :
- chemins absolus sensibles ;
- données personnelles ;
- contenu complet d'une preuve ;
- secrets ou jetons.
--- ---
# Objectifs à long terme ## 15. Sécurité
Le projet doit permettre : Règles obligatoires :
- la gestion complète d'une enquête numérique ; - requêtes préparées pour les données variables ;
- la conservation de la chaîne de preuve ; - clés étrangères activées ;
- l'intégration de modules OSINT ; - chemins contrôlés ;
- l'analyse de fichiers ; - neutralisation des traversées `../` ;
- la génération de rapports professionnels ; - aucune ouverture automatique de pièce jointe ;
- le packaging multiplateforme. - aucun chargement automatique de ressource distante d'un e-mail ;
- limites de taille et de profondeur pour les formats complexes ;
Le logiciel doit rester : - aucune commande shell dynamique ;
- aucune installation automatique d'outil ;
- libre ; - aucune donnée réelle d'enquête dans les tests ou le dépôt ;
- documenté ; - aucune action intrusive non autorisée.
- modulaire ;
- testable ;
- maintenable.
--- ---
# Conclusion ## 16. Tests
Toute nouvelle fonctionnalité doit respecter cette architecture. Le cœur, les modèles, DAO, migrations et tâches possèdent des tests ciblés.
En cas de dérogation, celle-ci devra être documentée et justifiée. Les tests GTK restent limités aux composants qui nécessitent réellement GTK.
L'objectif est de garantir la stabilité du projet tout en facilitant son évolution sur le long terme. Les scénarios critiques incluent :
- base neuve ;
- migration ;
- rollback ;
- import interrompu ;
- annulation ;
- erreur d'outil ;
- donnée malformée ;
- doublon ;
- intégrité ;
- clés étrangères ;
- conservation de la valeur brute ;
- absence d'une dépendance optionnelle.
Validation :
```sh
make clean
make -j8
make -j8 test
git diff --check
```
---
## 17. Règles d'évolution
Une nouvelle fonctionnalité doit :
1. respecter la direction des dépendances ;
2. réutiliser les services existants avant d'en créer un concurrent ;
3. définir clairement la propriété mémoire ;
4. ajouter les tests nécessaires ;
5. documenter les formats persistés ;
6. utiliser des fixtures synthétiques ;
7. préserver les données brutes ;
8. maintenir la branche compilable ;
9. mettre à jour l'architecture lorsque ses responsabilités changent.

740
docs/CONVENTIONS.md
View file

@ -1,302 +1,616 @@
# Conventions de développement # Conventions de développement
Version : 1.0 > **Version :** 2.0
> **Dernière mise à jour :** 2026-07-24
> **Projet :** Labfy Investigation
--- ---
# Philosophie ## 1. Objectif
Labfy Investigation est développé comme un logiciel d'enquête numérique. Ces conventions définissent les règles communes du dépôt.
Les choix d'architecture privilégient : Elles visent à garantir :
- la lisibilité ; - un code lisible et maintenable ;
- la maintenabilité ; - une séparation claire des responsabilités ;
- la robustesse ; - la traçabilité des données d'enquête ;
- la traçabilité ; - la stabilité des formats persistés ;
- la simplicité. - des tests reproductibles ;
- une documentation qui distingue l'état réel du projet de son historique.
Une solution simple et cohérente est toujours préférée à une solution Lorsqu'une convention contredit le code courant, le problème doit être résolu :
complexe. soit le code est corrigé, soit la convention est mise à jour. La divergence ne
doit pas devenir permanente.
--- ---
# Langue ## 2. Hiérarchie des sources
Le domaine métier est écrit en français. Pour déterminer l'état réel du projet, utiliser cet ordre de confiance :
1. code présent sur la branche `main` ;
2. tests automatisés ;
3. scripts SQL et migrations ;
4. commits ;
5. tickets Forgejo fermés ;
6. tickets Forgejo ouverts ;
7. documentation courante ;
8. documents historiques et anciennes roadmaps.
Un ticket ouvert décrit un chantier, pas une fonctionnalité terminée.
Un audit nommé `SCHEMA_AUDIT_V1.md` ou `SCHEMA_AUDIT_V9.md` décrit uniquement
la version indiquée. La référence courante est :
```text
docs/database/SCHEMA_AUDIT_CURRENT.md
```
---
## 3. Langue et terminologie
### 3.1 Code et identifiants techniques
Le code C, les noms de fichiers, les fonctions, les structures, les constantes
et les codes persistés utilisent un anglais technique cohérent.
Exemples : Exemples :
- preuve ```text
- entite evidence_record
- personne entity_dao
- source relation_service
- chronologie bank_proposal
- journal controlled_vocab
- hypothese eml_pipeline_task
- recherche created_at
verification_status
```
Les standards techniques conservent leur nom d'origine. Les identifiants persistés doivent être stables et indépendants des libellés
affichés.
Exemple :
```text
code persistant : proposed
libellé français : Proposé
```
Un libellé peut être traduit ou reformulé sans modifier le code persistant.
### 3.2 Interface et documentation
L'interface utilisateur et la documentation destinée aux utilisateurs sont
rédigées en français.
Les termes juridiques ou métier restent en français dans les textes lorsque
cela améliore la précision.
### 3.3 Abréviations
Les abréviations sont limitées aux formes techniques reconnues :
```text
UUID
SHA-256
MIME
UTC
SQL
DAO
OCR
EML
IBAN
BIC
```
Les noms de variables raccourcis sans nécessité sont interdits.
Préférer :
```c
relative_path
verification_status
evidence_record
created_at
```
Éviter :
```c
path
stat
rec
crt
```
---
## 4. Organisation et dépendances entre couches
Le projet suit une architecture en couches :
```text
Interface GTK4
↓
Application et contrôleurs
↓
Services métier et tâches
↓
DAO et adaptateurs
├── SQLite
├── système de fichiers
├── outils externes
└── futures API
↓
Modèles métier
```
Règles obligatoires :
- le cœur métier ne dépend pas de GTK ;
- les modèles ne connaissent ni GTK ni SQLite ;
- les vues et widgets n'exécutent aucune requête SQL ;
- les vues et widgets ne manipulent pas directement les preuves sur disque ;
- les migrations, connexions, statements et transactions appartiennent à la
couche Database ;
- les requêtes métier appartiennent aux DAO ;
- les services orchestrent les opérations impliquant plusieurs DAO ou
adaptateurs ;
- les opérations longues sont exécutées dans des tâches asynchrones ;
- le graphe est une projection de SQLite, jamais une seconde source de vérité.
Chaque module possède une responsabilité clairement identifiable.
---
## 5. Code C
### 5.1 Standard
Le projet utilise exclusivement :
```text
C17
```
Le Makefile principal compile avec :
```text
-std=c17 -Wall -Wextra -Werror
```
Plusieurs cibles de tests ajoutent également `-Wpedantic`.
Aucun avertissement ne doit être ignoré sans justification documentée.
### 5.2 Nommage
- fichiers : `snake_case.c` et `snake_case.h` ;
- fonctions : `snake_case` ;
- variables : noms explicites ;
- constantes : `UPPER_SNAKE_CASE` ;
- types publics : `PascalCase` lorsque cela correspond aux conventions GLib ;
- fonctions publiques préfixées par leur module.
Exemples : Exemples :
- uuid ```c
- sha256 database_open()
- mime_type evidence_dao_insert()
- sqlite relation_service_create()
- created_at eml_pipeline_task_new()
- updated_at ```
- relative_path
--- ### 5.3 Structures
# Architecture Les structures publiques sont opaques lorsque cela protège les invariants du
module.
Le projet est organisé par domaine métier.
Exemple : Exemple :
``` ```c
preuve typedef struct EvidenceRecord EvidenceRecord;
↓
preuve.h
preuve.c
entite
↓
entite.h
entite.c
``` ```
Chaque module possède une responsabilité unique. Un champ ne doit être public que lorsque l'accès direct est réellement prévu
par l'API.
### 5.4 Mémoire
Toute allocation possède un propriétaire clair.
Chaque API doit permettre de déterminer :
- qui alloue ;
- qui libère ;
- si une chaîne est empruntée ou copiée ;
- si une structure peut survivre au module qui l'a créée ;
- si un callback transfère la propriété.
Les conventions GLib sont utilisées de manière cohérente :
```text
_new() retourne généralement une nouvelle référence
_ref() ajoute une référence
_unref() retire une référence
_free() libère un objet non référencé
_dup_*() retourne une copie possédée
_peek_*() retourne une valeur empruntée
```
### 5.5 Erreurs
Les erreurs attendues sont remontées avec `GError` ou l'abstraction d'erreur du
module concerné.
Une fonction ne doit pas :
- masquer une erreur importante ;
- transformer silencieusement un échec en succès partiel ;
- afficher directement une boîte de dialogue depuis le cœur métier ;
- journaliser des données sensibles sans nécessité.
Les erreurs techniques sont journalisées. L'application décide de leur
présentation graphique.
--- ---
# SQL ## 6. SQLite
Une table représente un objet métier. ### 6.1 Version courante
Une table importante possède : La version courante du schéma est :
- une structure C ; ```text
- un module C ; V10
- des tests.
Les objets métier utilisent :
```
TEXT PRIMARY KEY
``` ```
contenant un UUID. Les scripts versionnés sont conservés dans :
Les tables de référence utilisent : ```text
database/schema_v1.sql
``` ...
INTEGER PRIMARY KEY database/schema_v10.sql
``` ```
--- Le complément idempotent du schéma courant est :
# UUID ```text
database/schema_current.sql
Tous les objets métier utilisent un UUID.
Exemple :
```
preuve
entite
personne
source
chronologie
journal
``` ```
Il n'existe pas simultanément : ### 6.2 Identifiants
``` Les objets métier utilisent généralement :
id
uuid ```sql
id TEXT PRIMARY KEY
``` ```
La colonne : avec un UUID généré par l'application.
``` Les tables de référence peuvent utiliser un identifiant entier lorsque cela
id correspond à leur rôle.
```
contient directement l'UUID. La convention doit être vérifiée table par table : aucune généralisation ne
doit remplacer la lecture du schéma réel.
--- ### 6.3 Dates
# Dates Les dates persistées utilisent l'UTC.
Toutes les dates sont enregistrées en UTC. Format attendu lorsque la table impose une date complète :
Format : ```text
```
YYYY-MM-DDTHH:MM:SSZ YYYY-MM-DDTHH:MM:SSZ
``` ```
La conversion vers l'heure locale est réservée à l'affichage.
### 6.4 Requêtes
Toute valeur variable utilise une requête préparée :
```c
sqlite3_prepare_v2()
sqlite3_bind_*()
sqlite3_step()
```
La concaténation de données utilisateur dans une requête SQL est interdite.
Les requêtes SQL statiques peuvent être exécutées avec `sqlite3_exec()` lorsque
cela reste adapté.
### 6.5 Transactions
Toute opération portant sur plusieurs écritures liées doit être atomique.
Exemples :
- création d'une enquête ;
- import d'une preuve ;
- reclassement d'une preuve ;
- création d'une relation avec ses preuves ;
- intégration de propositions OSINT ;
- migration de schéma ;
- validation finale d'un pivot EML.
En cas d'échec, les écritures partielles sont annulées et les modifications du
système de fichiers sont restaurées ou nettoyées.
### 6.6 Migrations
Toute évolution persistante doit :
1. définir une nouvelle version ;
2. ajouter un script `schema_vN.sql` ;
3. ajouter ou adapter la fonction d'installation ;
4. raccorder la migration depuis la version précédente ;
5. mettre à jour la version courante ;
6. tester une base neuve ;
7. tester une ancienne base migrée ;
8. exécuter `PRAGMA integrity_check` ;
9. exécuter `PRAGMA foreign_key_check` ;
10. mettre à jour l'audit courant et la documentation.
Une ancienne migration publiée ne doit pas être réécrite pour modifier son
sens historique.
### 6.7 Accès par couche
- `src/database` : infrastructure SQLite, schéma, statements, transactions,
erreurs et migrations ;
- `src/dao` : requêtes métier ;
- `src/core` : orchestration métier ;
- `src/views` et `src/widgets` : aucun SQL direct.
--- ---
# Chemins ## 7. Fichiers et preuves
Les chemins sont toujours relatifs à la racine de l'enquête. ### 7.1 Chemins
Les chemins persistés dans une enquête sont relatifs à sa racine.
Autorisé : Autorisé :
``` ```text
01_Preuves_Originales/Documents/facture.pdf 01_Preuves_Originales/Documents/facture.pdf
``` ```
Interdit : Interdit :
```text
/home/utilisateur/Documents/facture.pdf
``` ```
/home/user/Documents/...
Une entrée externe peut être absolue pendant l'import, mais le chemin enregistré
dans l'enquête doit respecter le modèle prévu par le schéma.
### 7.2 Immutabilité des preuves originales
Une preuve originale n'est jamais modifiée.
Toute opération produisant :
- une annotation ;
- une conversion ;
- une extraction ;
- un OCR ;
- une analyse ;
- une version expurgée ;
crée un nouvel objet ou un nouveau fichier dérivé.
### 7.3 Valeurs brutes et valeurs interprétées
Les données suivantes restent distinctes :
```text
valeur brute
valeur normalisée
valeur dérivée
correction utilisateur
statut de vérification
confiance
provenance
``` ```
Une valeur brute ne doit jamais être réécrite pour correspondre à une
interprétation ultérieure.
Un résultat OCR ou OSINT est une proposition à vérifier, pas un fait confirmé.
### 7.4 Suppression
La suppression logique est privilégiée pour les objets de traçabilité, mais la
règle exacte dépend de chaque table et de chaque DAO.
Une suppression physique n'est autorisée que lorsque :
- le schéma la permet explicitement ;
- le service métier l'encadre ;
- les conséquences sur les clés étrangères et les fichiers sont testées ;
- la traçabilité requise est préservée.
--- ---
# Suppression ## 8. Outils externes et réseau
Les objets métier importants ne sont jamais supprimés immédiatement. Les outils externes sont optionnels sauf décision explicite contraire.
Une suppression est une modification d'état. Ils sont lancés avec `GSubprocess` et une liste d'arguments séparés.
Exemple :
```
active
archived
deleted
```
Une purge physique éventuelle devra être explicite.
---
# Nommage
Le SQL utilise :
- snake_case
- minuscules
- aucun accent
- aucun espace
---
# Code C
Norme :
```
C17
```
Variables :
Toujours explicites.
Autorisé :
```c
relative_path
description
commentaire
created_at
```
Interdit : Interdit :
```c ```c
path system(dynamic_command);
desc
comm
crt
``` ```
Les fonctions utilisent le nom du module. Interdit également :
- construire une commande shell par concaténation ;
- ouvrir automatiquement une pièce jointe ;
- charger automatiquement une ressource distante d'un e-mail HTML ;
- installer automatiquement un outil ;
- utiliser un secret découvert ;
- contourner une authentification ;
- effectuer une action intrusive non autorisée.
Chaque exécution doit pouvoir conserver :
- l'outil ;
- sa version ;
- les arguments ;
- la date UTC ;
- la cible ;
- le code de retour ;
- `stdout` et `stderr` lorsque nécessaire ;
- les empreintes des sorties persistées ;
- les objets créés ou réutilisés.
---
## 9. Asynchronisme
Toute opération susceptible de bloquer l'interface doit être exécutée hors du
thread GTK principal.
Exemples :
- copie ou hachage de fichiers ;
- import massif ;
- chargement du graphe ;
- interrogation réseau ;
- lancement d'un outil ;
- OCR ;
- extraction de métadonnées ;
- analyse EML ;
- génération de rapport.
Une tâche longue doit prévoir, lorsque cela est possible :
- un état ;
- une progression ;
- une annulation ;
- un résultat ;
- une erreur ;
- une date de début ;
- une date de fin.
Les écritures SQLite concurrentes doivent être évitées ou sérialisées par
l'architecture prévue.
---
## 10. Tests
Toute fonctionnalité importante possède des tests adaptés.
Les tests couvrent selon le cas :
- arguments invalides ;
- cas nominal ;
- échecs ;
- annulation ;
- rollback ;
- responsabilités mémoire ;
- limites de taille ;
- entrées malformées ;
- anciennes versions de base ;
- intégrité et clés étrangères ;
- régressions.
Les tests utilisent uniquement des données synthétiques.
Il est interdit de placer dans le dépôt ou de fournir à un agent de
développement :
- une base `Enquete.sqlite` réelle ;
- des captures réelles ;
- des e-mails réels ;
- des RIB réels ;
- des pièces jointes réelles ;
- toute donnée personnelle issue d'une enquête.
Validation recommandée :
```sh
make clean
make -j8
make -j8 test
git diff --check
```
Une exécution séquentielle est utilisée seulement si la parallélisation
provoque un échec réel et identifié :
```sh
make
make test
```
---
## 11. Git et tickets
Forgejo est la source de vérité du suivi.
À partir des tickets postérieurs à l'historique numéroté manuellement, le titre
ne contient pas de numéro ajouté à la main : Forgejo attribue le numéro.
Un ticket peut nécessiter plusieurs commits.
Chaque commit doit :
- porter un changement cohérent ;
- compiler ;
- conserver la branche stable ;
- inclure ou adapter les tests nécessaires ;
- ne contenir aucune donnée réelle d'enquête.
Les messages de commit sont rédigés en anglais.
Exemple : Exemple :
```c ```text
preuve_create() feat(database): add bank account entities
preuve_load()
preuve_update()
preuve_delete()
``` ```
Aucun commit n'est effectué tant que la fonction concernée ne marche pas et que
la validation prévue n'a pas été réalisée.
--- ---
# Structures ## 12. Documentation
Une structure représente un objet métier. Toute décision importante est documentée.
Exemple : Une modification doit mettre à jour les documents concernés dans le même
chantier, notamment pour :
```c - l'architecture ;
typedef struct Preuve Preuve; - les conventions ;
- les dépendances ;
- le schéma SQLite ;
- les migrations ;
- les formats persistés ;
- les procédures de compilation et de test ;
- les limitations légales ou techniques.
La documentation doit indiquer clairement l'un des statuts suivants lorsque
cela évite une ambiguïté :
```text
IMPLÉMENTÉ
PARTIEL
PRÉVU
HISTORIQUE
``` ```
Les structures publiques sont opaques lorsque cela est possible. La priorité reste la qualité, la traçabilité et la compréhension durable du
projet.
---
# Tests
Toute nouvelle fonctionnalité importante possède un test.
Le développement suit toujours l'ordre :
```
Conception
↓
Implémentation
↓
Tests
↓
Commit
```
---
# Git
Un ticket terminé correspond à un commit.
Le message de commit est rédigé en anglais.
Exemple :
```
feat(database): initialize investigation database
```
---
# Documentation
Les décisions importantes sont documentées.
Les changements de schéma SQLite sont précédés d'un audit.
Aucune décision importante ne doit exister uniquement dans le code.
---
# Objectif
Le projet doit rester compréhensible plusieurs années après sa création.
La priorité est donnée à la qualité du code plutôt qu'à la rapidité de
développement.

1192
docs/DEVELOPMENT.md
View file

File diff suppressed because it is too large Load diff

781
docs/DOCUMENTATION_AUDIT_V10.md Normal file
View file

@ -0,0 +1,781 @@
# Audit de la documentation — état V10
> Projet : Labfy Investigation
> Date : 2026-07-24
> Branche examinée : `main`
> Commit de référence : `613d2096bc5eeb2c1c4f60ae701292e19a2abe66`
> Schéma SQLite courant : V10
> Tickets ouverts au moment de l’audit : `#107` et `#42`
## Conclusion générale
La documentation doit être remise à niveau.
Le `README.md` a déjà reçu plusieurs ajouts récents et reste globalement utile.
En revanche, les documents de référence situés dans `docs/` décrivent encore
en grande partie l’architecture du premier socle ou de la V1 SQLite.
Le problème principal n’est pas l’absence de documentation, mais le mélange
entre :
- l’architecture historique ;
- l’architecture cible ;
- les fonctionnalités déjà implémentées ;
- les tickets encore ouverts ;
- le schéma SQLite réellement courant.
Ce mélange a déjà provoqué une mauvaise interprétation par un agent local, qui
a présenté la V1 et le ticket #023 comme l’état actuel du dépôt.
## Ordre de confiance à documenter
Toute analyse du projet doit respecter cet ordre :
1. code présent sur `main` ;
2. tests automatisés ;
3. migrations et scripts SQL ;
4. commits ;
5. tickets Forgejo fermés ;
6. tickets Forgejo ouverts ;
7. documentation générale ;
8. documents historiques et anciennes roadmaps.
Un ticket ouvert décrit un chantier, pas une fonctionnalité terminée.
Un audit versionné décrit la version qu’il nomme, pas automatiquement la
version courante.
---
# Matrice des documents
| Document | État | Priorité | Action |
|---|---|---:|---|
| `README.md` | Partiellement à jour | Haute | Corriger l’état courant et les commandes |
| `CHANGELOG.md` | Incomplet | Haute | Documenter V10 et le pivot EML préparatoire |
| `docs/ARCHITECTURE.md` | Obsolète | Critique | Réécrire l’architecture actuelle |
| `docs/DEVELOPMENT.md` | Partiellement faux | Critique | Aligner sur Makefile et couches réelles |
| `docs/CONVENTIONS.md` | Obsolète par endroits | Haute | Aligner langue, SQL, suppression et Git |
| `docs/ROADMAP.md` | Très obsolète | Critique | Remplacer par une roadmap vivante |
| `docs/BACKLOG.md` | Vide | Haute | Supprimer ou rediriger vers Forgejo |
| `docs/DEPENDENCE.md` | Globalement utile | Moyenne | Vérifier les outils réellement invoqués |
| `docs/database/DATABASE_ARCHITECTURE.md` | Marqué V1 | Critique | Transformer en architecture V10 |
| `docs/database/SCHEMA_AUDIT_V1.md` | Historique non signalé | Critique | Déplacer et ajouter un avertissement |
| `docs/database/SCHEMA_AUDIT_CURRENT.md` | À ajouter | Critique | Référence courante V10 |
| `docs/database/audits/SCHEMA_AUDIT_V10.md` | À ajouter | Haute | Photographie versionnée de V10 |
---
# 1. README.md
## Éléments corrects
Le README décrit correctement :
- le dépôt Forgejo comme source principale ;
- le caractère non opérationnel du logiciel ;
- le cadre légal et éthique ;
- l’autonomie d’une enquête ;
- l’immutabilité des preuves originales ;
- SQLite comme source de vérité ;
- l’exécution asynchrone ;
- l’interdiction de construire des commandes shell dynamiques ;
- une grande partie des fonctionnalités ajoutées jusqu’à V9/V10.
## Mises à jour nécessaires
### Ajouter explicitement le schéma courant
Ajouter dans l’état du projet :
```text
Version du schéma SQLite : V10
```
avec un lien vers :
```text
docs/database/SCHEMA_AUDIT_CURRENT.md
```
### Mettre à jour les fonctionnalités présentes
Ajouter dans la liste du socle actuel :
- pipeline EML asynchrone préparatoire ;
- extraction MIME sécurisée ;
- assainissement des noms de pièces jointes ;
- propositions bancaires IBAN/BIC ;
- vocabulaire contrôlé ;
- table `bank_account_entities` ;
- types canoniques de relations liés au pivot e-mail ;
- tests `test_controlled_vocab`, `test_bank_proposal` et
`test_eml_pipeline_task`.
Préciser que le ticket `#107` reste ouvert et que le flux complet de révision
et d’intégration n’est pas encore terminé.
### Corriger le prochain chantier
Le texte indiquant que le prochain chantier porte sur l’initialisation
asynchrone du registre d’outils est obsolète.
Le chantier actif est désormais :
```text
#107 — Pivot e-mail forensique
```
Le ticket `#42` reste l’inventaire permanent des outils OSINT.
### Corriger les commandes de validation
Utiliser :
```sh
make clean
make -j8
make -j8 test
git diff --check
```
Prévoir un retour séquentiel uniquement si l’exécution parallèle échoue pour
une raison réelle.
---
# 2. CHANGELOG.md
## Problème
Le changelog ne reflète pas encore correctement l’ampleur du commit V10.
## Ajouts à documenter
Dans une section `Unreleased` ou `0.1.0-dev`, ajouter au minimum :
- schéma SQLite V10 ;
- table `bank_account_entities` ;
- statuts de vérification et provenances contrôlés ;
- nouveaux types système de relations ;
- pipeline EML asynchrone ;
- extraction MIME sécurisée ;
- détection et proposition IBAN/BIC ;
- vocabulaire contrôlé ;
- premiers objets d’intégration EML ;
- tests associés ;
- migration V9 vers V10 ;
- mise à jour de `schema_current.sql`.
## Règle recommandée
Le changelog doit décrire les capacités livrées, pas seulement les premiers
modules historiques de la fenêtre GTK.
---
# 3. docs/ARCHITECTURE.md
## Problèmes observés
Le document date du 14 juillet et décrit essentiellement le premier socle.
Il ne représente pas correctement :
- `src/dao` et `include/dao` ;
- les services métier ;
- les tâches asynchrones ;
- le gestionnaire de tâches ;
- le registre et le catalogue d’outils ;
- la provenance OSINT ;
- le graphe d’enquête ;
- les types canoniques de relations ;
- les extractions ;
- les comptes sociaux ;
- les personnes et leurs rôles ;
- le pipeline EML ;
- les propositions bancaires ;
- le vocabulaire contrôlé.
La phrase suivante est désormais incorrecte :
```text
Aucune requête SQL ne doit apparaître ailleurs.
```
Le dépôt possède une couche DAO contenant les requêtes métier.
## Architecture à documenter
```text
Interface GTK4
↓
Application et contrôleurs
↓
Services métier / tâches
↓
DAO et adaptateurs
├── SQLite
├── système de fichiers
├── outils externes
└── futures API
↓
Modèles métier
```
## Règle SQL correcte
- l’infrastructure SQLite, les migrations et les transactions appartiennent à
`src/database` ;
- les requêtes métier appartiennent aux DAO ;
- les widgets et vues n’accèdent jamais directement à SQLite ;
- les modèles ne connaissent pas SQLite.
## Organisation actuelle à ajouter
```text
include/core/
include/dao/
include/database/
include/models/
include/views/
include/widgets/
src/core/
src/dao/
src/database/
src/models/
src/views/
src/widgets/
```
## Statuts à utiliser
Pour éviter les ambiguïtés, chaque grande capacité doit être marquée :
```text
IMPLÉMENTÉ
PARTIEL
PRÉVU
HISTORIQUE
```
---
# 4. docs/DEVELOPMENT.md
## Incohérences avec le Makefile
### Cible `make docs`
Le document mentionne :
```sh
make docs
```
mais le Makefile courant ne définit pas de cible `docs`.
Action :
- supprimer cette commande ;
- ou créer réellement une cible Doxygen avant de la documenter.
### Options de compilation
Le document affirme que tout le projet utilise :
```text
-Wpedantic
```
Le Makefile principal utilise globalement :
```text
-std=c17 -Wall -Wextra -Werror
```
`-Wpedantic` est ajouté à plusieurs tests, mais pas aux `CFLAGS` globaux.
Il faut choisir une seule vérité :
- ajouter `-Wpedantic` globalement au Makefile ;
- ou corriger le document.
### Versions minimales
Le document annonce :
- GTK 4.10+ ;
- SQLite 3.45+ ;
- GCC 15+.
Ces versions ne sont pas imposées par le Makefile via `pkg-config`.
Pour la future cible Ubuntu, annoncer GCC 15+ risque d’exclure inutilement les
postes institutionnels.
Action :
- documenter les versions réellement minimales requises par les API utilisées ;
- distinguer l’environnement de développement Arch de la cible minimale
Ubuntu.
### Architecture MVC
Le terme MVC est désormais trop réducteur.
Utiliser plutôt :
```text
architecture en couches
```
avec services, DAO, tâches et adaptateurs.
### Accès SQLite
Remplacer :
```text
Toutes les opérations sur SQLite passent par la couche DAO.
```
par :
```text
Les migrations, connexions, statements et transactions appartiennent à la
couche Database. Les requêtes métier passent par les DAO. Les vues, widgets et
modèles n’accèdent jamais directement à SQLite.
```
### Commandes
Mettre les commandes recommandées à jour :
```sh
make clean
make -j8
make -j8 test
git diff --check
```
---
# 5. docs/CONVENTIONS.md
## Langue du code
Le document affirme que le domaine métier est écrit en français, avec des
exemples tels que `preuve.c` et `entite.c`.
Le code actuel utilise principalement des noms techniques anglais :
```text
evidence_record
entity_dao
relation_service
bank_proposal
controlled_vocab
eml_pipeline_task
```
## Convention proposée
- code C, noms de fichiers, fonctions, structures et codes persistés : anglais
technique cohérent ;
- libellés de l’interface et documentation utilisateur : français ;
- termes juridiques et métier : français dans les textes ;
- codes persistés : anglais stable, sans dépendre du libellé affiché.
Exemple :
```text
code persistant : proposed
libellé français : Proposé
```
## Suppression
Le document affirme que les objets importants ne sont jamais supprimés
immédiatement.
Cette règle doit être qualifiée table par table :
- suppression logique par défaut pour les objets de traçabilité ;
- suppression physique autorisée uniquement lorsqu’un DAO et les contraintes
métier la prévoient explicitement ;
- aucune affirmation générale non vérifiée.
## Git
Remplacer la règle trop stricte :
```text
Un ticket terminé correspond à un commit.
```
par :
```text
Chaque commit porte un changement cohérent et vérifiable. Un ticket peut
nécessiter plusieurs commits, mais chaque commit doit compiler, être testé et
laisser la branche stable.
```
## Schéma
Ajouter :
- toute migration possède un script versionné ;
- une base existante est migrée transactionnellement ;
- la version courante est documentée dans
`SCHEMA_AUDIT_CURRENT.md` ;
- les audits anciens sont historiques.
---
# 6. docs/ROADMAP.md
## Problème critique
Le document conserve plusieurs générations de roadmap dans le même fichier.
Il présente encore comme non réalisés :
- création d’une enquête ;
- validation ;
- initialisation SQLite ;
- `InvestigationProject` ;
- preuves ;
- entités ;
- relations ;
- tâches asynchrones ;
- plusieurs fonctions déjà présentes.
Il commence également une seconde roadmap au ticket `#031.1`.
Cette structure est la principale source de confusion documentaire du dépôt.
## Action recommandée
Remplacer complètement le fichier par une roadmap courte et vivante.
Structure proposée :
```markdown
# Roadmap
## Source de vérité
Les tickets Forgejo sont la source de vérité du suivi.
## État courant
- Schéma SQLite : V10
- Développement actif
- Logiciel non prêt pour la production
## Chantiers actifs
- #107 — Pivot e-mail forensique
## Inventaires permanents
- #42 — Arsenal OSINT
## Prochains axes
- terminer le flux de révision EML ;
- persister les propositions confirmées ;
- améliorer les tests de migration V9 → V10 ;
- mettre à jour le packaging Ubuntu ;
- poursuivre le graphe et les rapports.
## Historique
Consulter le changelog et les tickets fermés.
```
Déplacer l’ancienne roadmap vers :
```text
docs/archive/ROADMAP_LEGACY.md
```
ou la supprimer si Forgejo conserve déjà tout l’historique utile.
---
# 7. docs/BACKLOG.md
## État
Le fichier est vide.
## Action
Deux choix valables :
### Choix recommandé
Supprimer le fichier et utiliser uniquement Forgejo.
### Alternative
Conserver un simple pointeur :
```markdown
# Backlog
Le backlog actif est suivi dans Forgejo :
https://git.labfytools.com/fy59/labfy-investigation/issues
Ce fichier ne décrit pas l’état courant du projet.
```
Ne pas dupliquer les tickets dans un backlog Markdown.
---
# 8. docs/DEPENDENCE.md
## Éléments corrects
Le document couvre déjà :
- Tesseract ;
- ExifTool ;
- dig ;
- host ;
- whois ;
- curl ;
- OpenSSL ;
- qpdf ;
- John/pdf2john ;
- Sherlock ;
- Maigret ;
- Holehe.
## Vérifications nécessaires
Comparer les exécutables documentés avec :
- `tool_catalog.c` ;
- `tool_registry.c` ;
- `eml_pipeline_task.c` ;
- `rib_ocr.c` ;
- `exiftool_metadata.c` ;
- `pdf_password_recovery.c`.
Documenter pour chaque dépendance :
- obligatoire ou optionnelle ;
- fonctionnalité concernée ;
- commande de détection ;
- commande de version ;
- comportement lorsque l’outil est absent ;
- paquet Arch ;
- paquet Ubuntu ;
- compatibilité avec dépôts institutionnels restreints.
## Ajout recommandé
Ajouter une matrice :
| Outil | Fonction | Obligatoire | Dégradation si absent |
|---|---|---:|---|
| Tesseract | OCR | Non | Analyse partielle |
| ExifTool | Métadonnées | Non | Métadonnées externes absentes |
| dig | DNS | Non | Action DNS indisponible |
| John/pdf2john | PDF protégé | Non | Pas d’audit de mot de passe |
Ne jamais présenter un outil optionnel comme condition de démarrage.
---
# 9. docs/database/DATABASE_ARCHITECTURE.md
## Problème critique
L’en-tête indique encore :
```text
Statut : Stable (V1)
Schéma : V1
```
alors que la branche contient un schéma V10.
Le document a reçu un ajout V10 en fin de fichier, mais son titre, son statut et
la majorité de son inventaire restent centrés sur V1.
## Action recommandée
Transformer le document en architecture courante V10.
Nouvel en-tête :
```markdown
# Architecture de la base de données
> Statut : architecture courante
> Version du schéma : V10
> Source de vérité détaillée : SCHEMA_AUDIT_CURRENT.md
```
## Éléments à ajouter à l’inventaire
- `osint_executions` ;
- liaisons de provenance OSINT ;
- `comptes_sociaux` ;
- `person_roles` ;
- `extractions` ;
- tables de disposition et viewport du graphe ;
- `relation_types` ;
- `bank_account_entities`.
## Accès SQL
Remplacer la centralisation dans un unique module `database` par la séparation
réelle :
```text
Database : connexion, statements, transactions, schémas et migrations
DAO : requêtes métier
Services : orchestration transactionnelle
GTK : aucune requête SQL
```
## Migrations
Ajouter un résumé V1 → V10 et renvoyer vers l’audit courant pour les détails.
---
# 10. docs/database/SCHEMA_AUDIT_V1.md
## Problème
Le document est facilement interprété comme l’état actuel.
## Action
Déplacer vers :
```text
docs/database/audits/SCHEMA_AUDIT_V1.md
```
Ajouter en première ligne :
```markdown
> [!WARNING]
> Document historique. Cet audit décrit exclusivement la V1.
> Il ne représente pas le schéma courant.
> Consulter ../SCHEMA_AUDIT_CURRENT.md.
```
---
# 11. Nouveaux documents de base
Organisation recommandée :
```text
docs/database/
├── DATABASE_ARCHITECTURE.md
├── SCHEMA_AUDIT_CURRENT.md
└── audits/
├── SCHEMA_AUDIT_V1.md
├── SCHEMA_AUDIT_V9.md
└── SCHEMA_AUDIT_V10.md
```
Règle :
- `SCHEMA_AUDIT_CURRENT.md` est mis à jour à chaque migration ;
- l’audit versionné reste immuable après validation ;
- le ticket de migration n’est pas terminé sans mise à jour documentaire.
---
# 12. Hygiène du dépôt hors documentation
Deux éléments présents à la racine doivent être contrôlés :
```text
meline59760.txt
watch_20260723-211101
```
Ils ne ressemblent pas à des fichiers source ou de documentation standards.
Avant de les conserver publiquement :
1. vérifier qu’ils utilisent exclusivement des données synthétiques ;
2. vérifier qu’ils ne contiennent aucune donnée d’enquête réelle ;
3. les déplacer vers une fixture clairement nommée s’ils sont utiles aux tests ;
4. les supprimer du dépôt sinon ;
5. ajouter les motifs nécessaires dans `.gitignore`.
Ne jamais versionner :
- `Enquete.sqlite` réelle ;
- captures ;
- e-mails réels ;
- RIB réels ;
- pièces jointes réelles ;
- exports bruts issus d’une enquête ;
- données personnelles non synthétiques.
---
# Ordre de mise à jour recommandé
## Commit 1 — Références SQLite
- ajouter `SCHEMA_AUDIT_CURRENT.md` ;
- ajouter l’audit V10 ;
- archiver l’audit V1 ;
- mettre à jour `DATABASE_ARCHITECTURE.md`.
## Commit 2 — Roadmap et suivi
- remplacer `ROADMAP.md` ;
- supprimer ou rediriger `BACKLOG.md` ;
- corriger la section suivi du README.
## Commit 3 — Architecture et développement
- mettre à jour `ARCHITECTURE.md` ;
- mettre à jour `DEVELOPMENT.md` ;
- mettre à jour `CONVENTIONS.md`.
## Commit 4 — Dépendances et présentation
- vérifier `DEPENDENCE.md` ;
- compléter `CHANGELOG.md` ;
- finaliser `README.md`.
## Commit 5 — Hygiène du dépôt
- auditer les fichiers isolés à la racine ;
- supprimer ou déplacer les éléments non conformes ;
- ajuster `.gitignore`.
---
# Critères de validation documentaire
La mise à jour est terminée lorsque :
- aucun document courant ne présente V1 comme schéma actuel ;
- V10 est identifiée comme version courante ;
- les audits historiques sont explicitement marqués historiques ;
- la roadmap ne duplique plus les tickets fermés ;
- `#107` est présenté comme chantier actif ;
- `#42` est présenté comme inventaire permanent ;
- les commandes documentées existent réellement dans le Makefile ;
- `make docs` n’est plus documenté sans cible correspondante ;
- l’architecture distingue Database, DAO, services et GTK ;
- le nommage documenté correspond au code actuel ;
- les dépendances optionnelles sont clairement identifiées ;
- les données d’enquête réelles sont explicitement interdites dans le dépôt ;
- tous les liens Markdown sont valides ;
- `git diff --check` passe.

1742
docs/ROADMAP.md
View file

File diff suppressed because it is too large Load diff

2782
docs/database/DATABASE_ARCHITECTURE.md
View file

File diff suppressed because it is too large Load diff

1581
docs/database/SCHEMA_AUDIT_CURRENT.md Normal file
View file

File diff suppressed because it is too large Load diff

0
docs/database/SCHEMA_AUDIT_V1.md → docs/database/audits/SCHEMA_AUDIT_V1.md
View file

1581
docs/database/audits/SCHEMA_AUDIT_V10.md Normal file
View file

File diff suppressed because it is too large Load diff

1408
docs/database/audits/SCHEMA_AUDIT_V9.md Normal file
View file

File diff suppressed because it is too large Load diff

4
meline59760.txt
View file

@ -1,4 +0,0 @@
https://forum.velomania.ru/member.php?username=meline59760
https://www.youtube.com/@meline59760
https://www.baby.ru/u/meline59760
Total Websites Username Detected On : 3

5
watch_20260723-211101
View file

@ -1,5 +0,0 @@
NAME ID SIZE PROCESSOR CONTEXT UNTIL
total utilisé libre partagé tamp/cache disponible
Mem: 14Gi 5,1Gi 7,9Gi 70Mi 2,2Gi 9,8Gi
Échange: 4,0Gi 3,8Gi 224Mi