chore: initialize Labfy Investigation project structure
This commit is contained in:
grayTerminal-sh
parent
6d90c10ca1
commit
919bd1b7ad
20 changed files with 1076 additions and 177 deletions
15
.gitignore
vendored
Normal file
15
.gitignore
vendored
Normal file
|
|
@ -0,0 +1,15 @@
|
||||||
|
# Build
|
||||||
|
*.o
|
||||||
|
*.a
|
||||||
|
*.so
|
||||||
|
labfy-investigation
|
||||||
|
|
||||||
|
# SQLite
|
||||||
|
*.sqlite-wal
|
||||||
|
*.sqlite-shm
|
||||||
|
|
||||||
|
# QtCreator
|
||||||
|
*.pro.user
|
||||||
|
|
||||||
|
# DB Browser
|
||||||
|
*.sqbpro
|
||||||
11
Enquete-gui/.gitignore
vendored
11
Enquete-gui/.gitignore
vendored
|
|
@ -1,11 +0,0 @@
|
||||||
# Build
|
|
||||||
enquete-gui
|
|
||||||
*.o
|
|
||||||
|
|
||||||
# SQLite temporaires
|
|
||||||
*.sqlite-shm
|
|
||||||
*.sqlite-wal
|
|
||||||
|
|
||||||
# Neovim / LSP
|
|
||||||
.cache/
|
|
||||||
compile_commands.json
|
|
||||||
|
|
@ -1,28 +0,0 @@
|
||||||
CC = gcc
|
|
||||||
|
|
||||||
PKG_CONFIG = pkg-config
|
|
||||||
|
|
||||||
CFLAGS = -Wall -Wextra -Wpedantic -Werror -std=c17 -g \
|
|
||||||
-Iinclude \
|
|
||||||
$(shell $(PKG_CONFIG) --cflags gtk4 sqlite3)
|
|
||||||
|
|
||||||
LDFLAGS = $(shell $(PKG_CONFIG) --libs gtk4 sqlite3)
|
|
||||||
|
|
||||||
SRC := $(wildcard src/*.c)
|
|
||||||
OBJ := $(SRC:.c=.o)
|
|
||||||
|
|
||||||
TARGET = enquete-gui
|
|
||||||
|
|
||||||
$(TARGET): $(OBJ)
|
|
||||||
$(CC) $(OBJ) -o $@ $(LDFLAGS)
|
|
||||||
|
|
||||||
%.o: %.c
|
|
||||||
$(CC) $(CFLAGS) -c $< -o $@
|
|
||||||
|
|
||||||
clean:
|
|
||||||
rm -f $(OBJ) $(TARGET)
|
|
||||||
|
|
||||||
run: $(TARGET)
|
|
||||||
./$(TARGET)
|
|
||||||
|
|
||||||
.PHONY: clean run
|
|
||||||
|
|
@ -1,22 +0,0 @@
|
||||||
-I/usr/include/gtk-4.0
|
|
||||||
-I/usr/include/pango-1.0
|
|
||||||
-I/usr/include/fribidi
|
|
||||||
-I/usr/include/harfbuzz
|
|
||||||
-I/usr/include/gdk-pixbuf-2.0
|
|
||||||
-I/usr/include/glycin-2
|
|
||||||
-I/usr/include/cairo
|
|
||||||
-I/usr/include/freetype2
|
|
||||||
-I/usr/include/libpng16
|
|
||||||
-I/usr/include/pixman-1
|
|
||||||
-I/usr/include/graphene-1.0
|
|
||||||
-I/usr/lib/graphene-1.0/include
|
|
||||||
-mfpmath=sse
|
|
||||||
-msse
|
|
||||||
-msse2
|
|
||||||
-I/usr/include/glib-2.0
|
|
||||||
-I/usr/lib/glib-2.0/include
|
|
||||||
-I/usr/include/libmount
|
|
||||||
-I/usr/include/blkid
|
|
||||||
-I/usr/include/sysprof-6
|
|
||||||
-pthread
|
|
||||||
-Iinclude
|
|
||||||
|
|
@ -1,8 +0,0 @@
|
||||||
#ifndef APP_H
|
|
||||||
#define APP_H
|
|
||||||
|
|
||||||
#include <gtk/gtk.h>
|
|
||||||
|
|
||||||
GtkWidget *app_create_main_window(GtkApplication *app);
|
|
||||||
|
|
||||||
#endif
|
|
||||||
|
|
@ -1,9 +0,0 @@
|
||||||
#ifndef DATABASE_H
|
|
||||||
#define DATABASE_H
|
|
||||||
|
|
||||||
#include <sqlite3.h>
|
|
||||||
|
|
||||||
int db_open(sqlite3 **db, const char *path);
|
|
||||||
void db_close(sqlite3 *db);
|
|
||||||
|
|
||||||
#endif
|
|
||||||
|
|
@ -1,42 +0,0 @@
|
||||||
#include "app.h"
|
|
||||||
|
|
||||||
GtkWidget *app_create_main_window(GtkApplication *app)
|
|
||||||
{
|
|
||||||
GtkWidget *window;
|
|
||||||
GtkWidget *box;
|
|
||||||
GtkWidget *sidebar;
|
|
||||||
GtkWidget *content;
|
|
||||||
GtkWidget *label;
|
|
||||||
|
|
||||||
window = gtk_application_window_new(app);
|
|
||||||
gtk_window_set_title(GTK_WINDOW(window), "Enquête OSINT");
|
|
||||||
gtk_window_set_default_size(GTK_WINDOW(window), 1000, 650);
|
|
||||||
|
|
||||||
box = gtk_box_new(GTK_ORIENTATION_HORIZONTAL, 0);
|
|
||||||
gtk_window_set_child(GTK_WINDOW(window), box);
|
|
||||||
|
|
||||||
sidebar = gtk_list_box_new();
|
|
||||||
gtk_widget_set_size_request(sidebar, 220, -1);
|
|
||||||
|
|
||||||
gtk_list_box_append(GTK_LIST_BOX(sidebar), gtk_label_new("Preuves"));
|
|
||||||
gtk_list_box_append(GTK_LIST_BOX(sidebar), gtk_label_new("Entités"));
|
|
||||||
gtk_list_box_append(GTK_LIST_BOX(sidebar), gtk_label_new("Chronologie"));
|
|
||||||
gtk_list_box_append(GTK_LIST_BOX(sidebar), gtk_label_new("Recherches"));
|
|
||||||
gtk_list_box_append(GTK_LIST_BOX(sidebar), gtk_label_new("Hypothèses"));
|
|
||||||
gtk_list_box_append(GTK_LIST_BOX(sidebar), gtk_label_new("Sources"));
|
|
||||||
gtk_list_box_append(GTK_LIST_BOX(sidebar), gtk_label_new("Rapport"));
|
|
||||||
|
|
||||||
content = gtk_box_new(GTK_ORIENTATION_VERTICAL, 10);
|
|
||||||
gtk_widget_set_margin_top(content, 20);
|
|
||||||
gtk_widget_set_margin_bottom(content, 20);
|
|
||||||
gtk_widget_set_margin_start(content, 20);
|
|
||||||
gtk_widget_set_margin_end(content, 20);
|
|
||||||
|
|
||||||
label = gtk_label_new("Tableau de bord de l'enquête");
|
|
||||||
gtk_box_append(GTK_BOX(content), label);
|
|
||||||
|
|
||||||
gtk_box_append(GTK_BOX(box), sidebar);
|
|
||||||
gtk_box_append(GTK_BOX(box), content);
|
|
||||||
|
|
||||||
return window;
|
|
||||||
}
|
|
||||||
|
|
@ -1,21 +0,0 @@
|
||||||
#include "database.h"
|
|
||||||
#include <stdio.h>
|
|
||||||
|
|
||||||
int db_open(sqlite3 **db, const char *path)
|
|
||||||
{
|
|
||||||
int rc = sqlite3_open(path, db);
|
|
||||||
|
|
||||||
if (rc != SQLITE_OK) {
|
|
||||||
fprintf(stderr, "Erreur SQLite: %s\n", sqlite3_errmsg(*db));
|
|
||||||
return 1;
|
|
||||||
}
|
|
||||||
|
|
||||||
return 0;
|
|
||||||
}
|
|
||||||
|
|
||||||
void db_close(sqlite3 *db)
|
|
||||||
{
|
|
||||||
if (db != NULL) {
|
|
||||||
sqlite3_close(db);
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
@ -1,36 +0,0 @@
|
||||||
#include <gtk/gtk.h>
|
|
||||||
#include <sqlite3.h>
|
|
||||||
|
|
||||||
#include "app.h"
|
|
||||||
#include "database.h"
|
|
||||||
|
|
||||||
static void activate(GtkApplication *app, gpointer user_data)
|
|
||||||
{
|
|
||||||
(void)user_data;
|
|
||||||
|
|
||||||
GtkWidget *window = app_create_main_window(app);
|
|
||||||
gtk_window_present(GTK_WINDOW(window));
|
|
||||||
}
|
|
||||||
|
|
||||||
int main(int argc, char **argv)
|
|
||||||
{
|
|
||||||
sqlite3 *db = NULL;
|
|
||||||
|
|
||||||
if (db_open(&db, "../../03_Chronologie/Enquete.sqlite") != 0) {
|
|
||||||
return 1;
|
|
||||||
}
|
|
||||||
|
|
||||||
GtkApplication *app = gtk_application_new(
|
|
||||||
"com.labfytools.enquete",
|
|
||||||
G_APPLICATION_DEFAULT_FLAGS
|
|
||||||
);
|
|
||||||
|
|
||||||
g_signal_connect(app, "activate", G_CALLBACK(activate), NULL);
|
|
||||||
|
|
||||||
int status = g_application_run(G_APPLICATION(app), argc, argv);
|
|
||||||
|
|
||||||
g_object_unref(app);
|
|
||||||
db_close(db);
|
|
||||||
|
|
||||||
return status;
|
|
||||||
}
|
|
||||||
21
LICENSE
Normal file
21
LICENSE
Normal file
|
|
@ -0,0 +1,21 @@
|
||||||
|
MIT License
|
||||||
|
|
||||||
|
Copyright (c) 2026 fy59
|
||||||
|
|
||||||
|
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||||
|
of this software and associated documentation files (the "Software"), to deal
|
||||||
|
in the Software without restriction, including without limitation the rights
|
||||||
|
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||||
|
copies of the Software, and to permit persons to whom the Software is
|
||||||
|
furnished to do so, subject to the following conditions:
|
||||||
|
|
||||||
|
The above copyright notice and this permission notice shall be included in all
|
||||||
|
copies or substantial portions of the Software.
|
||||||
|
|
||||||
|
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||||
|
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||||
|
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||||
|
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||||
|
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||||
|
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||||
|
SOFTWARE.
|
||||||
|
|
@ -162,3 +162,9 @@ Elle permet de :
|
||||||
- documenter les recherches ;
|
- documenter les recherches ;
|
||||||
- générer les rapports ;
|
- générer les rapports ;
|
||||||
- faciliter la navigation dans la base de données.
|
- faciliter la navigation dans la base de données.
|
||||||
|
|
||||||
|
## Licence
|
||||||
|
|
||||||
|
Ce projet est distribué sous licence MIT.
|
||||||
|
|
||||||
|
Voir le fichier `LICENSE` pour plus d'informations.
|
||||||
|
|
|
||||||
351
docs/ARCHITECTURE.md
Normal file
351
docs/ARCHITECTURE.md
Normal file
|
|
@ -0,0 +1,351 @@
|
||||||
|
# Architecture
|
||||||
|
|
||||||
|
Version : 1.0
|
||||||
|
|
||||||
|
Dernière mise à jour : 2026-07-06
|
||||||
|
|
||||||
|
Auteur : fy59
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Objectif
|
||||||
|
|
||||||
|
Ce document décrit l'architecture logicielle de **Labfy Investigation**.
|
||||||
|
|
||||||
|
Son objectif est de :
|
||||||
|
|
||||||
|
- définir les responsabilités de chaque composant ;
|
||||||
|
- faciliter la maintenance ;
|
||||||
|
- garantir une architecture cohérente ;
|
||||||
|
- limiter les dépendances entre les modules.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Philosophie
|
||||||
|
|
||||||
|
Labfy Investigation repose sur une architecture modulaire.
|
||||||
|
|
||||||
|
Chaque composant possède une responsabilité clairement définie.
|
||||||
|
|
||||||
|
Aucun module ne doit effectuer plusieurs tâches sans justification.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Architecture générale
|
||||||
|
|
||||||
|
Le projet suit une architecture inspirée du modèle MVC (Model - View - Controller).
|
||||||
|
|
||||||
|
```
|
||||||
|
Utilisateur
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
+------------------+
|
||||||
|
| Vue (GTK4) |
|
||||||
|
+------------------+
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
+------------------+
|
||||||
|
| Contrôleur |
|
||||||
|
+------------------+
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
+------------------+
|
||||||
|
| DAO |
|
||||||
|
+------------------+
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
+------------------+
|
||||||
|
| SQLite |
|
||||||
|
+------------------+
|
||||||
|
```
|
||||||
|
|
||||||
|
Chaque couche communique uniquement avec la couche immédiatement inférieure.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Arborescence
|
||||||
|
|
||||||
|
```
|
||||||
|
labfy-investigation/
|
||||||
|
|
||||||
|
├── include/
|
||||||
|
├── src/
|
||||||
|
│
|
||||||
|
├── docs/
|
||||||
|
├── database/
|
||||||
|
├── tests/
|
||||||
|
├── tools/
|
||||||
|
├── resources/
|
||||||
|
│
|
||||||
|
├── Makefile
|
||||||
|
├── README.md
|
||||||
|
├── LICENSE
|
||||||
|
├── CHANGELOG.md
|
||||||
|
└── CONTRIBUTING.md
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Description des dossiers
|
||||||
|
|
||||||
|
## include/
|
||||||
|
|
||||||
|
Contient l'ensemble des interfaces publiques.
|
||||||
|
|
||||||
|
Aucun code métier ne doit être présent dans les fichiers d'en-tête.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## src/
|
||||||
|
|
||||||
|
Contient l'implémentation du logiciel.
|
||||||
|
|
||||||
|
Il est organisé en plusieurs modules :
|
||||||
|
|
||||||
|
```
|
||||||
|
src/
|
||||||
|
|
||||||
|
core/
|
||||||
|
dao/
|
||||||
|
models/
|
||||||
|
controllers/
|
||||||
|
views/
|
||||||
|
widgets/
|
||||||
|
utils/
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## database/
|
||||||
|
|
||||||
|
Contient :
|
||||||
|
|
||||||
|
- le schéma SQLite ;
|
||||||
|
- les scripts d'initialisation ;
|
||||||
|
- les éventuelles migrations.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## docs/
|
||||||
|
|
||||||
|
Documentation technique.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## tests/
|
||||||
|
|
||||||
|
Tests unitaires et fonctionnels.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## resources/
|
||||||
|
|
||||||
|
Toutes les ressources utilisées par l'application :
|
||||||
|
|
||||||
|
- icônes ;
|
||||||
|
- feuilles CSS ;
|
||||||
|
- fichiers GtkBuilder (.ui).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Description des modules
|
||||||
|
|
||||||
|
## Core
|
||||||
|
|
||||||
|
Le module Core initialise l'application.
|
||||||
|
|
||||||
|
Il gère :
|
||||||
|
|
||||||
|
- le cycle de vie du programme ;
|
||||||
|
- la configuration ;
|
||||||
|
- l'ouverture de l'enquête ;
|
||||||
|
- la fermeture propre.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Models
|
||||||
|
|
||||||
|
Les modèles représentent les objets métiers.
|
||||||
|
|
||||||
|
Exemples :
|
||||||
|
|
||||||
|
- Preuve
|
||||||
|
- Entite
|
||||||
|
- Personne
|
||||||
|
- Recherche
|
||||||
|
- Source
|
||||||
|
|
||||||
|
Ils ne connaissent ni GTK ni SQLite.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## DAO
|
||||||
|
|
||||||
|
Les DAO sont responsables de l'accès aux données.
|
||||||
|
|
||||||
|
Ils sont les seuls autorisés à communiquer avec SQLite.
|
||||||
|
|
||||||
|
Ils réalisent :
|
||||||
|
|
||||||
|
- INSERT
|
||||||
|
- UPDATE
|
||||||
|
- DELETE
|
||||||
|
- SELECT
|
||||||
|
|
||||||
|
Aucune requête SQL ne doit apparaître ailleurs.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Controllers
|
||||||
|
|
||||||
|
Les contrôleurs assurent la logique applicative.
|
||||||
|
|
||||||
|
Ils reçoivent les événements provenant de l'interface graphique.
|
||||||
|
|
||||||
|
Ils utilisent les DAO.
|
||||||
|
|
||||||
|
Ils mettent à jour les vues.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Views
|
||||||
|
|
||||||
|
Les vues représentent l'interface utilisateur.
|
||||||
|
|
||||||
|
Elles ne contiennent aucun code métier.
|
||||||
|
|
||||||
|
Une vue affiche uniquement des informations.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Widgets
|
||||||
|
|
||||||
|
Les widgets sont des composants GTK réutilisables.
|
||||||
|
|
||||||
|
Par exemple :
|
||||||
|
|
||||||
|
- Sidebar
|
||||||
|
- Toolbar
|
||||||
|
- Statusbar
|
||||||
|
- PropertyPanel
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Utils
|
||||||
|
|
||||||
|
Fonctions utilitaires :
|
||||||
|
|
||||||
|
- SHA-256
|
||||||
|
- Date
|
||||||
|
- Fichiers
|
||||||
|
- Journalisation
|
||||||
|
|
||||||
|
Les utilitaires ne doivent jamais dépendre du reste du projet.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Flux de données
|
||||||
|
|
||||||
|
Lorsqu'un utilisateur ajoute une preuve :
|
||||||
|
|
||||||
|
```
|
||||||
|
Utilisateur
|
||||||
|
|
||||||
|
↓
|
||||||
|
|
||||||
|
Vue GTK
|
||||||
|
|
||||||
|
↓
|
||||||
|
|
||||||
|
Controller
|
||||||
|
|
||||||
|
↓
|
||||||
|
|
||||||
|
DAO
|
||||||
|
|
||||||
|
↓
|
||||||
|
|
||||||
|
SQLite
|
||||||
|
|
||||||
|
↓
|
||||||
|
|
||||||
|
DAO
|
||||||
|
|
||||||
|
↓
|
||||||
|
|
||||||
|
Controller
|
||||||
|
|
||||||
|
↓
|
||||||
|
|
||||||
|
Vue GTK
|
||||||
|
```
|
||||||
|
|
||||||
|
Le flux est toujours identique.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Dépendances
|
||||||
|
|
||||||
|
Les dépendances suivent la règle suivante :
|
||||||
|
|
||||||
|
```
|
||||||
|
Views
|
||||||
|
↓
|
||||||
|
Controllers
|
||||||
|
↓
|
||||||
|
DAO
|
||||||
|
↓
|
||||||
|
SQLite
|
||||||
|
```
|
||||||
|
|
||||||
|
Les dépendances inverses sont interdites.
|
||||||
|
|
||||||
|
Par exemple :
|
||||||
|
|
||||||
|
Le DAO ne doit jamais appeler une vue.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Gestion de la mémoire
|
||||||
|
|
||||||
|
Chaque module est responsable des ressources qu'il alloue.
|
||||||
|
|
||||||
|
Toute allocation possède une fonction de libération correspondante.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Gestion des erreurs
|
||||||
|
|
||||||
|
Les erreurs remontent toujours vers le contrôleur.
|
||||||
|
|
||||||
|
L'interface graphique est responsable de leur affichage.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Évolutivité
|
||||||
|
|
||||||
|
L'ajout d'un nouveau type d'entité ou d'une nouvelle fonctionnalité doit nécessiter le moins de modifications possibles.
|
||||||
|
|
||||||
|
L'architecture doit favoriser l'extension plutôt que la modification du code existant.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Principes
|
||||||
|
|
||||||
|
L'architecture repose sur les principes suivants :
|
||||||
|
|
||||||
|
- responsabilité unique ;
|
||||||
|
- faible couplage ;
|
||||||
|
- forte cohésion ;
|
||||||
|
- séparation des responsabilités ;
|
||||||
|
- simplicité ;
|
||||||
|
- lisibilité ;
|
||||||
|
- maintenabilité.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Conclusion
|
||||||
|
|
||||||
|
Toute nouvelle fonctionnalité doit s'intégrer dans cette architecture.
|
||||||
|
|
||||||
|
Si une évolution nécessite de contourner ces règles, la décision doit être documentée et justifiée.
|
||||||
683
docs/DEVELOPMENT.md
Normal file
683
docs/DEVELOPMENT.md
Normal file
|
|
@ -0,0 +1,683 @@
|
||||||
|
# Développement
|
||||||
|
|
||||||
|
Version : 1.0
|
||||||
|
|
||||||
|
Dernière mise à jour : 2026-07-06
|
||||||
|
|
||||||
|
Auteur : fy59
|
||||||
|
|
||||||
|
# Sommaire
|
||||||
|
|
||||||
|
1. Objet
|
||||||
|
2. Objectif
|
||||||
|
3. Technologies
|
||||||
|
4. Outils
|
||||||
|
5. Commandes
|
||||||
|
6. Revue de code
|
||||||
|
7. Philosophie
|
||||||
|
8. Architecture
|
||||||
|
9. Règles de codage
|
||||||
|
10. Documentation
|
||||||
|
11. Organisation des fichiers
|
||||||
|
12. Gestion mémoire
|
||||||
|
13. Base de données
|
||||||
|
14. Git
|
||||||
|
15. Développement
|
||||||
|
16. Tests
|
||||||
|
17. Gestion des erreurs
|
||||||
|
18. Convention de nommage
|
||||||
|
- Fichiers
|
||||||
|
- Fonctions
|
||||||
|
- Variables
|
||||||
|
- Types
|
||||||
|
- Constantes
|
||||||
|
- Énumérations
|
||||||
|
19. Principes de conception
|
||||||
|
- Simplicité
|
||||||
|
- Lisibilité
|
||||||
|
- Responsabilité unique
|
||||||
|
- Zéro surprise
|
||||||
|
- Style de code
|
||||||
|
- Le compilateur est notre premier relecteur
|
||||||
|
- Documentation
|
||||||
|
- Boy Scout Rule
|
||||||
|
- Robustesse avant optimisation
|
||||||
|
- Une fonctionnalité = un commit
|
||||||
|
20. Décisions techniques
|
||||||
|
21. Branche principale
|
||||||
|
22. Dépendances
|
||||||
|
---
|
||||||
|
|
||||||
|
## Objet
|
||||||
|
|
||||||
|
Ce document définit les règles de développement du projet **Labfy Investigation**.
|
||||||
|
|
||||||
|
L'objectif est de garantir un code :
|
||||||
|
|
||||||
|
- lisible ;
|
||||||
|
- maintenable ;
|
||||||
|
- documenté ;
|
||||||
|
- portable ;
|
||||||
|
- simple à faire évoluer.
|
||||||
|
|
||||||
|
Ces règles s'appliquent à l'ensemble du projet.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Objectif
|
||||||
|
|
||||||
|
L'objectif du projet est de produire un logiciel libre, robuste et documenté destiné à faciliter la gestion d'enquêtes OSINT, tout en constituant un support d'apprentissage du langage C, de GTK4, de SQLite et des bonnes pratiques de développement logiciel.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Technologies
|
||||||
|
|
||||||
|
Le projet repose sur les technologies suivantes :
|
||||||
|
|
||||||
|
| Technologie | Version |
|
||||||
|
|-------------|----------|
|
||||||
|
| Langage | C17 |
|
||||||
|
| Interface graphique | GTK 4.10+ |
|
||||||
|
| Base de données | SQLite 3.45+ |
|
||||||
|
| Compilateur | GCC 15+ |
|
||||||
|
| Build | Make |
|
||||||
|
| Documentation | Doxygen |
|
||||||
|
| Gestion de version | Git |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Outils
|
||||||
|
|
||||||
|
Les outils suivants sont utilisés pendant le développement :
|
||||||
|
|
||||||
|
- gcc
|
||||||
|
- clang
|
||||||
|
- clang-format
|
||||||
|
- clang-tidy
|
||||||
|
- cppcheck
|
||||||
|
- valgrind
|
||||||
|
- doxygen
|
||||||
|
- graphviz
|
||||||
|
- make
|
||||||
|
- Git
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Commandes
|
||||||
|
|
||||||
|
Compilation :
|
||||||
|
|
||||||
|
make
|
||||||
|
|
||||||
|
Exécution :
|
||||||
|
|
||||||
|
make run
|
||||||
|
|
||||||
|
Nettoyage :
|
||||||
|
|
||||||
|
make clean
|
||||||
|
|
||||||
|
Documentation :
|
||||||
|
|
||||||
|
make docs
|
||||||
|
|
||||||
|
Tests :
|
||||||
|
|
||||||
|
make test
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Revue de code
|
||||||
|
|
||||||
|
Avant chaque commit important, le code doit être vérifié selon les critères suivants :
|
||||||
|
|
||||||
|
- respecte les conventions de nommage ;
|
||||||
|
- compile sans warning ;
|
||||||
|
- est documenté ;
|
||||||
|
- respecte l'architecture MVC ;
|
||||||
|
- ne duplique pas de code ;
|
||||||
|
- gère correctement les erreurs ;
|
||||||
|
- libère correctement les ressources.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Philosophie
|
||||||
|
|
||||||
|
Labfy Investigation est développé comme un logiciel professionnel.
|
||||||
|
|
||||||
|
Les priorités sont les suivantes :
|
||||||
|
|
||||||
|
1. Simplicité.
|
||||||
|
2. Lisibilité.
|
||||||
|
3. Robustesse.
|
||||||
|
4. Documentation.
|
||||||
|
5. Évolutivité.
|
||||||
|
|
||||||
|
Un code plus simple est toujours préféré à un code plus complexe.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Architecture
|
||||||
|
|
||||||
|
Le projet suit une architecture de type MVC.
|
||||||
|
|
||||||
|
```
|
||||||
|
Vue (GTK)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
Contrôleur
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
DAO
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
SQLite
|
||||||
|
```
|
||||||
|
|
||||||
|
Les responsabilités sont clairement séparées.
|
||||||
|
|
||||||
|
Une couche ne doit jamais accéder directement à une couche qui ne lui appartient pas.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Règles de codage
|
||||||
|
|
||||||
|
Le projet est développé en **C17**.
|
||||||
|
|
||||||
|
Les options de compilation sont :
|
||||||
|
|
||||||
|
- `-std=c17`
|
||||||
|
- `-Wall`
|
||||||
|
- `-Wextra`
|
||||||
|
- `-Wpedantic`
|
||||||
|
- `-Werror`
|
||||||
|
|
||||||
|
Aucun warning n'est accepté.
|
||||||
|
|
||||||
|
Le projet doit compiler sans erreur ni avertissement.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Documentation
|
||||||
|
|
||||||
|
Chaque fichier possède un en-tête.
|
||||||
|
|
||||||
|
Chaque fonction publique est documentée avec Doxygen.
|
||||||
|
|
||||||
|
Les commentaires expliquent :
|
||||||
|
|
||||||
|
- pourquoi un choix a été fait ;
|
||||||
|
- les contraintes techniques ;
|
||||||
|
- les hypothèses.
|
||||||
|
|
||||||
|
Les commentaires ne doivent jamais simplement répéter le code.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Organisation des fichiers
|
||||||
|
|
||||||
|
Chaque fichier possède une responsabilité unique.
|
||||||
|
|
||||||
|
Une fonction ne doit réaliser qu'une seule tâche.
|
||||||
|
|
||||||
|
Lorsque cela devient nécessaire, le code est découpé en plusieurs modules.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Gestion mémoire
|
||||||
|
|
||||||
|
Toute allocation mémoire possède une fonction de libération correspondante.
|
||||||
|
|
||||||
|
Les fuites mémoire sont considérées comme des bugs.
|
||||||
|
|
||||||
|
Les vérifications sont réalisées régulièrement avec Valgrind.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Base de données
|
||||||
|
|
||||||
|
Toutes les opérations sur SQLite passent par la couche DAO.
|
||||||
|
|
||||||
|
Le reste de l'application ne manipule jamais directement SQLite.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Git
|
||||||
|
|
||||||
|
Le dépôt Git contient uniquement :
|
||||||
|
|
||||||
|
- le code source ;
|
||||||
|
- la documentation ;
|
||||||
|
- les modèles ;
|
||||||
|
- les scripts.
|
||||||
|
|
||||||
|
Les enquêtes réelles ne sont jamais versionnées.
|
||||||
|
|
||||||
|
Chaque commit :
|
||||||
|
|
||||||
|
- compile ;
|
||||||
|
- fonctionne ;
|
||||||
|
- correspond à une seule fonctionnalité.
|
||||||
|
|
||||||
|
Les messages de commit suivent la convention :
|
||||||
|
|
||||||
|
```
|
||||||
|
type(scope): description
|
||||||
|
```
|
||||||
|
|
||||||
|
Exemples :
|
||||||
|
|
||||||
|
```
|
||||||
|
feat(gui): create main window
|
||||||
|
|
||||||
|
feat(database): add evidence dao
|
||||||
|
|
||||||
|
fix(core): close sqlite connection
|
||||||
|
|
||||||
|
docs: update architecture
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Développement
|
||||||
|
|
||||||
|
Avant toute nouvelle fonctionnalité :
|
||||||
|
|
||||||
|
1. Définir le besoin.
|
||||||
|
2. Concevoir l'architecture.
|
||||||
|
3. Développer.
|
||||||
|
4. Tester.
|
||||||
|
5. Documenter.
|
||||||
|
6. Commit.
|
||||||
|
|
||||||
|
Aucune fonctionnalité n'est considérée comme terminée tant que ces six étapes ne sont pas réalisées.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Tests
|
||||||
|
|
||||||
|
Chaque fonctionnalité doit être testée avant son intégration.
|
||||||
|
|
||||||
|
Lorsque cela est possible :
|
||||||
|
|
||||||
|
- tests unitaires ;
|
||||||
|
- tests fonctionnels ;
|
||||||
|
- vérification sous Valgrind ;
|
||||||
|
- compilation sans warning.
|
||||||
|
|
||||||
|
Un correctif est toujours accompagné d'un test permettant de vérifier que le problème est résolu.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Gestion des erreurs
|
||||||
|
|
||||||
|
Aucune erreur ne doit être ignorée.
|
||||||
|
|
||||||
|
Les valeurs de retour des fonctions sont systématiquement vérifiées.
|
||||||
|
|
||||||
|
Les messages d'erreur doivent être explicites et permettre d'identifier rapidement l'origine du problème.
|
||||||
|
|
||||||
|
Les ressources ouvertes doivent toujours être libérées, même en cas d'erreur.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Convention de nommage
|
||||||
|
|
||||||
|
Afin de garantir la cohérence du projet, une convention de nommage stricte est appliquée.
|
||||||
|
|
||||||
|
Toute dérogation à cette convention doit être justifiée.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Fichiers
|
||||||
|
|
||||||
|
Les noms de fichiers sont écrits en **snake_case**.
|
||||||
|
|
||||||
|
Exemples :
|
||||||
|
|
||||||
|
```text
|
||||||
|
database.c
|
||||||
|
database.h
|
||||||
|
|
||||||
|
preuve.c
|
||||||
|
preuve.h
|
||||||
|
|
||||||
|
main_window.c
|
||||||
|
main_window.h
|
||||||
|
|
||||||
|
types_entite.c
|
||||||
|
types_entite.h
|
||||||
|
```
|
||||||
|
|
||||||
|
Les noms doivent être explicites et refléter la responsabilité du module.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Fonctions
|
||||||
|
|
||||||
|
Les fonctions sont toujours préfixées par le nom du module auquel elles appartiennent.
|
||||||
|
|
||||||
|
Exemples :
|
||||||
|
|
||||||
|
```c
|
||||||
|
db_open();
|
||||||
|
db_close();
|
||||||
|
|
||||||
|
preuve_new();
|
||||||
|
preuve_free();
|
||||||
|
|
||||||
|
main_window_create();
|
||||||
|
main_window_destroy();
|
||||||
|
```
|
||||||
|
|
||||||
|
Les fonctions génériques telles que :
|
||||||
|
|
||||||
|
```c
|
||||||
|
create();
|
||||||
|
init();
|
||||||
|
run();
|
||||||
|
```
|
||||||
|
|
||||||
|
sont interdites, car elles deviennent rapidement ambiguës lorsque le projet grandit.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Variables
|
||||||
|
|
||||||
|
Les variables utilisent également la convention **snake_case**.
|
||||||
|
|
||||||
|
Exemples :
|
||||||
|
|
||||||
|
```c
|
||||||
|
preuve_id
|
||||||
|
|
||||||
|
type_id
|
||||||
|
|
||||||
|
main_window
|
||||||
|
|
||||||
|
database
|
||||||
|
|
||||||
|
source_id
|
||||||
|
|
||||||
|
date_collecte
|
||||||
|
```
|
||||||
|
|
||||||
|
Les noms doivent décrire clairement le contenu de la variable.
|
||||||
|
|
||||||
|
Les noms suivants sont à proscrire :
|
||||||
|
|
||||||
|
```c
|
||||||
|
x
|
||||||
|
|
||||||
|
tmp
|
||||||
|
|
||||||
|
toto
|
||||||
|
|
||||||
|
test
|
||||||
|
```
|
||||||
|
|
||||||
|
à l'exception des variables locales très courtes utilisées dans une boucle ou un contexte limité :
|
||||||
|
|
||||||
|
```c
|
||||||
|
for (size_t i = 0; i < count; ++i)
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Types
|
||||||
|
|
||||||
|
Les structures représentent des objets métiers et utilisent le **PascalCase**.
|
||||||
|
|
||||||
|
Exemples :
|
||||||
|
|
||||||
|
```c
|
||||||
|
typedef struct
|
||||||
|
{
|
||||||
|
...
|
||||||
|
} Preuve;
|
||||||
|
|
||||||
|
typedef struct
|
||||||
|
{
|
||||||
|
...
|
||||||
|
} Entite;
|
||||||
|
|
||||||
|
typedef struct
|
||||||
|
{
|
||||||
|
...
|
||||||
|
} Personne;
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Constantes
|
||||||
|
|
||||||
|
Les constantes et macros sont écrites en majuscules avec des underscores.
|
||||||
|
|
||||||
|
Exemples :
|
||||||
|
|
||||||
|
```c
|
||||||
|
MAX_PATH_LENGTH
|
||||||
|
|
||||||
|
SHA256_LENGTH
|
||||||
|
|
||||||
|
DEFAULT_WINDOW_WIDTH
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Énumérations
|
||||||
|
|
||||||
|
Les énumérations utilisent un préfixe correspondant au type.
|
||||||
|
|
||||||
|
Exemple :
|
||||||
|
|
||||||
|
```c
|
||||||
|
typedef enum
|
||||||
|
{
|
||||||
|
PREUVE_CAPTURE,
|
||||||
|
PREUVE_EMAIL,
|
||||||
|
PREUVE_VIDEO
|
||||||
|
} PreuveType;
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Objectif
|
||||||
|
|
||||||
|
Le nom d'un fichier, d'une fonction ou d'une variable doit permettre de comprendre immédiatement son rôle, sans avoir à consulter son implémentation.
|
||||||
|
|
||||||
|
Le code doit être explicite avant d'être concis.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Principes de conception
|
||||||
|
|
||||||
|
Les principes suivants guident le développement de l'ensemble du projet.
|
||||||
|
|
||||||
|
Ils doivent être respectés avant toute considération d'optimisation.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Simplicité
|
||||||
|
|
||||||
|
La solution la plus simple est privilégiée.
|
||||||
|
|
||||||
|
Un code plus court n'est pas forcément un meilleur code.
|
||||||
|
|
||||||
|
La lisibilité prime toujours.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Lisibilité
|
||||||
|
|
||||||
|
Le code doit pouvoir être compris plusieurs mois après son écriture.
|
||||||
|
|
||||||
|
Les noms des fichiers, fonctions, variables et structures doivent être explicites.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Responsabilité unique
|
||||||
|
|
||||||
|
Chaque module possède une responsabilité unique.
|
||||||
|
|
||||||
|
Chaque fonction réalise une seule tâche.
|
||||||
|
|
||||||
|
Si une fonction devient difficile à expliquer, elle doit probablement être découpée.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Zéro surprise
|
||||||
|
|
||||||
|
Le comportement d'une fonction doit être prévisible.
|
||||||
|
|
||||||
|
Le nom d'une fonction doit permettre de comprendre ce qu'elle réalise sans avoir à lire son implémentation.
|
||||||
|
|
||||||
|
Exemple :
|
||||||
|
|
||||||
|
```c
|
||||||
|
preuve_save();
|
||||||
|
```
|
||||||
|
|
||||||
|
est préférable à :
|
||||||
|
|
||||||
|
```c
|
||||||
|
save();
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Style de code
|
||||||
|
|
||||||
|
- Indentation : 4 espaces.
|
||||||
|
- Largeur maximale : 100 colonnes.
|
||||||
|
- Accolades sur une nouvelle ligne (style Allman).
|
||||||
|
- Une déclaration par ligne.
|
||||||
|
- Une instruction par ligne.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Le compilateur est notre premier relecteur
|
||||||
|
|
||||||
|
Les warnings sont considérés comme des erreurs.
|
||||||
|
|
||||||
|
Le projet compile toujours avec :
|
||||||
|
|
||||||
|
- `-Wall`
|
||||||
|
- `-Wextra`
|
||||||
|
- `-Wpedantic`
|
||||||
|
- `-Werror`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Documentation
|
||||||
|
|
||||||
|
Le code explique **comment** fonctionne une fonctionnalité.
|
||||||
|
|
||||||
|
Les commentaires expliquent **pourquoi** elle existe.
|
||||||
|
|
||||||
|
Les commentaires ne doivent jamais simplement répéter le code.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Boy Scout Rule
|
||||||
|
|
||||||
|
À chaque modification d'un fichier, celui-ci doit être laissé dans un état au moins aussi propre qu'avant la modification.
|
||||||
|
|
||||||
|
Cela peut être :
|
||||||
|
|
||||||
|
- améliorer un nom de variable ;
|
||||||
|
- corriger un commentaire ;
|
||||||
|
- supprimer du code mort ;
|
||||||
|
- simplifier une fonction.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Robustesse avant optimisation
|
||||||
|
|
||||||
|
Les optimisations ne sont réalisées que lorsqu'un besoin est identifié et mesuré.
|
||||||
|
|
||||||
|
La robustesse et la lisibilité sont prioritaires.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Une fonctionnalité = un commit
|
||||||
|
|
||||||
|
Chaque commit correspond à une seule fonctionnalité.
|
||||||
|
|
||||||
|
Chaque commit :
|
||||||
|
|
||||||
|
- compile ;
|
||||||
|
- est testé ;
|
||||||
|
- est documenté.
|
||||||
|
|
||||||
|
Les messages de commit suivent la convention :
|
||||||
|
|
||||||
|
```
|
||||||
|
type(scope): description
|
||||||
|
```
|
||||||
|
|
||||||
|
Exemples :
|
||||||
|
|
||||||
|
```
|
||||||
|
feat(gui): create main window
|
||||||
|
feat(database): add evidence dao
|
||||||
|
fix(core): close sqlite connection
|
||||||
|
docs: update development guide
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Décisions techniques
|
||||||
|
|
||||||
|
Toute décision technique importante doit être documentée.
|
||||||
|
|
||||||
|
Le projet privilégie les choix simples, documentés et facilement maintenables.
|
||||||
|
|
||||||
|
Lorsque plusieurs solutions existent, la préférence est donnée à celle qui facilite la compréhension du code par un nouveau développeur.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Branche principale
|
||||||
|
|
||||||
|
La branche `main` est toujours stable.
|
||||||
|
|
||||||
|
Le projet doit toujours :
|
||||||
|
|
||||||
|
- compiler ;
|
||||||
|
- démarrer ;
|
||||||
|
- être documenté.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Dépendances
|
||||||
|
|
||||||
|
Les nouvelles dépendances doivent être justifiées.
|
||||||
|
|
||||||
|
Avant d'ajouter une bibliothèque externe, il convient de vérifier :
|
||||||
|
|
||||||
|
- si la bibliothèque standard suffit ;
|
||||||
|
- si GTK ou GLib proposent déjà la fonctionnalité ;
|
||||||
|
- si la nouvelle dépendance apporte un réel bénéfice.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Licence
|
||||||
|
|
||||||
|
Le projet est distribué sous la licence MIT.
|
||||||
|
|
||||||
|
Toute nouvelle contribution est considérée comme publiée sous cette même licence.
|
||||||
|
|
||||||
|
Le texte complet de la licence est disponible dans le fichier `LICENSE` situé à la racine du projet.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Historique
|
||||||
|
|
||||||
|
## Version 1.0
|
||||||
|
|
||||||
|
- Création du guide de développement.
|
||||||
|
- Définition des conventions de codage.
|
||||||
|
- Définition de l'architecture.
|
||||||
|
- Définition des règles Git.
|
||||||
0
docs/ROADMAP.md
Normal file
0
docs/ROADMAP.md
Normal file
Loading…
Reference in a new issue