chore: initialize Labfy Investigation project structure

.gitignore

@@ -0,0 +1,15 @@
+# Build
+*.o
+*.a
+*.so
+labfy-investigation
+
+# SQLite
+*.sqlite-wal
+*.sqlite-shm
+
+# QtCreator
+*.pro.user
+
+# DB Browser
+*.sqbpro

Enquete-gui/.gitignore

@@ -1,11 +0,0 @@
-# Build
-enquete-gui
-*.o
-
-# SQLite temporaires
-*.sqlite-shm
-*.sqlite-wal
-
-# Neovim / LSP
-.cache/
-compile_commands.json

Enquete-gui/Makefile

@@ -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

Enquete-gui/compile_flags.txt

@@ -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

Enquete-gui/include/app.h

@@ -1,8 +0,0 @@
-#ifndef APP_H
-#define APP_H
-
-#include <gtk/gtk.h>
-
-GtkWidget *app_create_main_window(GtkApplication *app);
-
-#endif

Enquete-gui/include/database.h

@@ -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

Enquete-gui/src/app.c

@@ -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;
-}

Enquete-gui/src/database.c

@@ -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);
-    }
-}

Enquete-gui/src/main.c

@@ -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;
-}

LICENSE

@@ -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.

README.md

@@ -162,3 +162,9 @@ Elle permet de :
 - documenter les recherches ;
 - générer les rapports ;
 - 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.

docs/ARCHITECTURE.md

@@ -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.

docs/DEVELOPMENT.md

@@ -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.