docs/ update
This commit is contained in:
grayTerminal-sh
parent
613d2096bc
commit
8fcd6b0e0d
12 changed files with 7658 additions and 5029 deletions
|
|
@ -1,440 +1,619 @@
|
|||
# Architecture
|
||||
|
||||
Version : 2.0
|
||||
|
||||
Dernière mise à jour : 2026-07-14
|
||||
|
||||
Auteur : fy59
|
||||
> **Version :** 3.0
|
||||
> **Dernière mise à jour :** 2026-07-24
|
||||
> **Schéma SQLite courant :** V10
|
||||
> **Statut :** architecture courante
|
||||
|
||||
---
|
||||
|
||||
# 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 ;
|
||||
- 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.
|
||||
La documentation détaillée du schéma SQLite se trouve dans :
|
||||
|
||||
```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/
|
||||
│ └── Enquete.sqlite
|
||||
│
|
||||
├── 01_Preuves_Originales/
|
||||
├── 02_Preuves_Traitees/
|
||||
├── 03_Chronologie/
|
||||
├── 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 ;
|
||||
- déplacée ;
|
||||
- synchronisée ;
|
||||
- sauvegardée ;
|
||||
- archivée ;
|
||||
- transmise.
|
||||
Les préférences générales de l'application, lorsqu'elles seront ajoutées,
|
||||
resteront séparées des données d'enquête.
|
||||
|
||||
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.
|
||||
|
||||
Toute opération produisant :
|
||||
|
||||
- une annotation ;
|
||||
- une conversion ;
|
||||
- une extraction ;
|
||||
- une analyse ;
|
||||
|
||||
doit produire un nouveau fichier dans un espace dédié.
|
||||
|
||||
---
|
||||
|
||||
## Le Core est indépendant de GTK
|
||||
|
||||
La logique métier ne dépend jamais de l'interface graphique.
|
||||
|
||||
Le Core doit pouvoir être testé sans lancer GTK.
|
||||
|
||||
---
|
||||
|
||||
## Les Widgets ne connaissent pas le métier
|
||||
|
||||
Les widgets affichent uniquement les informations fournies.
|
||||
|
||||
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 |
|
||||
+---------------------------+
|
||||
```text
|
||||
┌──────────────────────────────────────────────┐
|
||||
│ Interface GTK4 │
|
||||
│ views / widgets │
|
||||
└──────────────────────┬───────────────────────┘
|
||||
│ intentions et affichage
|
||||
┌──────────────────────▼───────────────────────┐
|
||||
│ Application et contrôleurs │
|
||||
│ cycle de vie, session, navigation, messages │
|
||||
└──────────────────────┬───────────────────────┘
|
||||
│ orchestration
|
||||
┌──────────────────────▼───────────────────────┐
|
||||
│ Services métier et tâches │
|
||||
│ import, relations, OSINT, EML, graphe │
|
||||
└───────────────┬───────────────────┬──────────┘
|
||||
│ │
|
||||
▼ ▼
|
||||
FileSystem Database
|
||||
┌───────────────▼────────────┐ ┌────▼─────────────────┐
|
||||
│ DAO │ │ Adaptateurs │
|
||||
│ requêtes métier SQLite │ │ fichiers / CLI / API│
|
||||
└───────────────┬────────────┘ └────┬─────────────────┘
|
||||
│ │
|
||||
└────────┬────────┘
|
||||
▼
|
||||
Investigation
|
||||
│
|
||||
▼
|
||||
Models
|
||||
┌───────────────▼───────────────────▼──────────┐
|
||||
│ Infrastructure │
|
||||
│ SQLite / transactions / système de fichiers │
|
||||
└──────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
Cette architecture permet une séparation claire entre :
|
||||
|
||||
- l'interface graphique ;
|
||||
- la logique métier ;
|
||||
- le stockage.
|
||||
Les modèles métier circulent entre ces couches sans dépendre de GTK ni de
|
||||
SQLite.
|
||||
|
||||
---
|
||||
|
||||
# Organisation du projet
|
||||
## 6. Organisation du dépôt
|
||||
|
||||
```
|
||||
labfy-investigation/
|
||||
|
||||
include/
|
||||
src/
|
||||
|
||||
database/
|
||||
docs/
|
||||
resources/
|
||||
tests/
|
||||
tools/
|
||||
|
||||
README.md
|
||||
LICENSE
|
||||
CHANGELOG.md
|
||||
CONTRIBUTING.md
|
||||
Makefile
|
||||
```text
|
||||
database/ scripts SQL versionnés et schéma courant
|
||||
docs/ architecture, conventions et procédures
|
||||
include/core/ interfaces des services et du cœur
|
||||
include/dao/ interfaces d'accès métier aux données
|
||||
include/database/ interfaces de l'infrastructure SQLite
|
||||
include/models/ modèles métier
|
||||
include/views/ fenêtres et dialogues GTK
|
||||
include/widgets/ widgets réutilisables
|
||||
resources/ ressources de l'application
|
||||
src/core/ services, tâches et orchestration métier
|
||||
src/dao/ requêtes métier SQLite
|
||||
src/database/ connexion, schéma, statements, transactions, erreurs
|
||||
src/models/ implémentation des modèles
|
||||
src/views/ fenêtres et dialogues GTK
|
||||
src/widgets/ composants GTK réutilisables
|
||||
tests/ tests unitaires et d'intégration ciblée
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Organisation du code
|
||||
## 7. Responsabilités des modules
|
||||
|
||||
```
|
||||
src/
|
||||
### 7.1 Point d'entrée et application
|
||||
|
||||
core/
|
||||
database/
|
||||
models/
|
||||
views/
|
||||
widgets/
|
||||
utils/
|
||||
`src/main.c` démarre l'application.
|
||||
|
||||
La couche application :
|
||||
|
||||
- gère le cycle de vie GTK ;
|
||||
- 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 :
|
||||
|
||||
- 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 :
|
||||
La fermeture libère :
|
||||
|
||||
- les tâches ;
|
||||
- les références de modèles ;
|
||||
- la connexion SQLite ;
|
||||
- le schéma ;
|
||||
- les migrations ;
|
||||
- les transactions.
|
||||
|
||||
Aucune requête SQL ne doit apparaître ailleurs.
|
||||
- la session ;
|
||||
- les widgets dépendants ;
|
||||
- les ressources externes.
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
- Preuve
|
||||
- Entité
|
||||
- Relation
|
||||
- Chronologie
|
||||
|
||||
Ils ne connaissent ni GTK ni SQLite.
|
||||
|
||||
---
|
||||
|
||||
## Views
|
||||
|
||||
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
|
||||
```text
|
||||
validation de la source
|
||||
↓
|
||||
SHA-256 source
|
||||
↓
|
||||
copie vers une destination contrôlée
|
||||
↓
|
||||
SHA-256 destination
|
||||
↓
|
||||
écriture SQLite
|
||||
↓
|
||||
validation ou nettoyage
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
```
|
||||
Widgets
|
||||
│
|
||||
▼
|
||||
Views
|
||||
│
|
||||
▼
|
||||
Application
|
||||
│
|
||||
▼
|
||||
InvestigationProject
|
||||
│
|
||||
┌──┴───────┐
|
||||
▼ ▼
|
||||
Database FileSystem
|
||||
│
|
||||
▼
|
||||
Models
|
||||
Une tâche expose selon ses besoins :
|
||||
|
||||
```text
|
||||
pending
|
||||
running
|
||||
completed
|
||||
failed
|
||||
cancelled
|
||||
```
|
||||
|
||||
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 ;
|
||||
- la conservation de la chaîne de preuve ;
|
||||
- l'intégration de modules OSINT ;
|
||||
- l'analyse de fichiers ;
|
||||
- la génération de rapports professionnels ;
|
||||
- le packaging multiplateforme.
|
||||
|
||||
Le logiciel doit rester :
|
||||
|
||||
- libre ;
|
||||
- documenté ;
|
||||
- modulaire ;
|
||||
- testable ;
|
||||
- maintenable.
|
||||
- requêtes préparées pour les données variables ;
|
||||
- clés étrangères activées ;
|
||||
- chemins contrôlés ;
|
||||
- neutralisation des traversées `../` ;
|
||||
- aucune ouverture automatique de pièce jointe ;
|
||||
- aucun chargement automatique de ressource distante d'un e-mail ;
|
||||
- limites de taille et de profondeur pour les formats complexes ;
|
||||
- aucune commande shell dynamique ;
|
||||
- aucune installation automatique d'outil ;
|
||||
- aucune donnée réelle d'enquête dans les tests ou le dépôt ;
|
||||
- aucune action intrusive non autorisée.
|
||||
|
||||
---
|
||||
|
||||
# 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.
|
||||
|
|
|
|||
|
|
@ -1,302 +1,616 @@
|
|||
# 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é ;
|
||||
- la maintenabilité ;
|
||||
- la robustesse ;
|
||||
- la traçabilité ;
|
||||
- la simplicité.
|
||||
- un code lisible et maintenable ;
|
||||
- une séparation claire des responsabilités ;
|
||||
- la traçabilité des données d'enquête ;
|
||||
- la stabilité des formats persistés ;
|
||||
- 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
|
||||
complexe.
|
||||
Lorsqu'une convention contredit le code courant, le problème doit être résolu :
|
||||
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 :
|
||||
|
||||
- preuve
|
||||
- entite
|
||||
- personne
|
||||
- source
|
||||
- chronologie
|
||||
- journal
|
||||
- hypothese
|
||||
- recherche
|
||||
```text
|
||||
evidence_record
|
||||
entity_dao
|
||||
relation_service
|
||||
bank_proposal
|
||||
controlled_vocab
|
||||
eml_pipeline_task
|
||||
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 :
|
||||
|
||||
- uuid
|
||||
- sha256
|
||||
- mime_type
|
||||
- sqlite
|
||||
- created_at
|
||||
- updated_at
|
||||
- relative_path
|
||||
```c
|
||||
database_open()
|
||||
evidence_dao_insert()
|
||||
relation_service_create()
|
||||
eml_pipeline_task_new()
|
||||
```
|
||||
|
||||
---
|
||||
### 5.3 Structures
|
||||
|
||||
# Architecture
|
||||
|
||||
Le projet est organisé par domaine métier.
|
||||
Les structures publiques sont opaques lorsque cela protège les invariants du
|
||||
module.
|
||||
|
||||
Exemple :
|
||||
|
||||
```
|
||||
preuve
|
||||
↓
|
||||
preuve.h
|
||||
preuve.c
|
||||
|
||||
entite
|
||||
↓
|
||||
entite.h
|
||||
entite.c
|
||||
```c
|
||||
typedef struct EvidenceRecord EvidenceRecord;
|
||||
```
|
||||
|
||||
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 ;
|
||||
- un module C ;
|
||||
- des tests.
|
||||
|
||||
Les objets métier utilisent :
|
||||
|
||||
```
|
||||
TEXT PRIMARY KEY
|
||||
```text
|
||||
V10
|
||||
```
|
||||
|
||||
contenant un UUID.
|
||||
Les scripts versionnés sont conservés dans :
|
||||
|
||||
Les tables de référence utilisent :
|
||||
|
||||
```
|
||||
INTEGER PRIMARY KEY
|
||||
```text
|
||||
database/schema_v1.sql
|
||||
...
|
||||
database/schema_v10.sql
|
||||
```
|
||||
|
||||
---
|
||||
Le complément idempotent du schéma courant est :
|
||||
|
||||
# UUID
|
||||
|
||||
Tous les objets métier utilisent un UUID.
|
||||
|
||||
Exemple :
|
||||
|
||||
```
|
||||
preuve
|
||||
entite
|
||||
personne
|
||||
source
|
||||
chronologie
|
||||
journal
|
||||
```text
|
||||
database/schema_current.sql
|
||||
```
|
||||
|
||||
Il n'existe pas simultanément :
|
||||
### 6.2 Identifiants
|
||||
|
||||
```
|
||||
id
|
||||
uuid
|
||||
Les objets métier utilisent généralement :
|
||||
|
||||
```sql
|
||||
id TEXT PRIMARY KEY
|
||||
```
|
||||
|
||||
La colonne :
|
||||
avec un UUID généré par l'application.
|
||||
|
||||
```
|
||||
id
|
||||
```
|
||||
Les tables de référence peuvent utiliser un identifiant entier lorsque cela
|
||||
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
|
||||
```
|
||||
|
||||
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é :
|
||||
|
||||
```
|
||||
```text
|
||||
01_Preuves_Originales/Documents/facture.pdf
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
```
|
||||
Ils sont lancés avec `GSubprocess` et une liste d'arguments séparés.
|
||||
|
||||
Interdit :
|
||||
|
||||
```c
|
||||
path
|
||||
desc
|
||||
comm
|
||||
crt
|
||||
system(dynamic_command);
|
||||
```
|
||||
|
||||
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 :
|
||||
|
||||
```c
|
||||
preuve_create()
|
||||
preuve_load()
|
||||
preuve_update()
|
||||
preuve_delete()
|
||||
```text
|
||||
feat(database): add bank account entities
|
||||
```
|
||||
|
||||
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
|
||||
typedef struct Preuve Preuve;
|
||||
- l'architecture ;
|
||||
- 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.
|
||||
|
||||
---
|
||||
|
||||
# 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.
|
||||
La priorité reste la qualité, la traçabilité et la compréhension durable du
|
||||
projet.
|
||||
|
|
|
|||
1192
docs/DEVELOPMENT.md
1192
docs/DEVELOPMENT.md
File diff suppressed because it is too large
Load diff
781
docs/DOCUMENTATION_AUDIT_V10.md
Normal file
781
docs/DOCUMENTATION_AUDIT_V10.md
Normal 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
1742
docs/ROADMAP.md
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
1581
docs/database/SCHEMA_AUDIT_CURRENT.md
Normal file
1581
docs/database/SCHEMA_AUDIT_CURRENT.md
Normal file
File diff suppressed because it is too large
Load diff
1581
docs/database/audits/SCHEMA_AUDIT_V10.md
Normal file
1581
docs/database/audits/SCHEMA_AUDIT_V10.md
Normal file
File diff suppressed because it is too large
Load diff
1408
docs/database/audits/SCHEMA_AUDIT_V9.md
Normal file
1408
docs/database/audits/SCHEMA_AUDIT_V9.md
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -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
|
||||
|
|
@ -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
|
||||
Loading…
Reference in a new issue