CONTRIBUTING : procédure formalisée + README : soutien remonté

- CONTRIBUTING.md : section "Proposer une contribution" réécrite avec
  tableaux Markdown, blocs de code inline (convention branches, commits,
  template PR), règles backend/frontend détaillées
- README.md : mention financement déplacée juste après la présentation,
  avant la section Fonctionnalités ; section Soutenir le projet supprimée
  en fin de fichier

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

CONTRIBUTING.md

@@ -6,7 +6,7 @@ Merci de l'intérêt pour le projet. Ce document décrit comment signaler un pro
 
 ## Dépôts
 
-Le dépôt source est hébergé sur Gitea (instance privée). GitHub est un miroir public en lecture seule. Les pull requests doivent être soumises sur le miroir GitHub — elles seront intégrées manuellement dans le dépôt source après relecture.
+Le dépôt source est hébergé sur Gitea (instance privée). **GitHub est un miroir public en lecture seule.** Les pull requests doivent être soumises sur le miroir GitHub — elles seront intégrées manuellement dans le dépôt source après relecture.
 
 ---
 
@@ -14,24 +14,106 @@ Le dépôt source est hébergé sur Gitea (instance privée). GitHub est un miro
 
 Avant d'ouvrir une issue, vérifier qu'elle n'existe pas déjà.
 
-Une bonne issue contient :
+| Champ | Ce qu'on attend |
-- La version ou le commit concerné
+|-------|-----------------|
-- Les étapes pour reproduire le problème
+| **Version / commit** | Le hash court du commit concerné (`git log --oneline -1`) ou le numéro de version |
-- Le comportement observé et le comportement attendu
+| **Étapes pour reproduire** | Séquence minimale et reproductible menant au bug |
-- Le contexte (OS, navigateur, logs backend si disponibles)
+| **Comportement observé** | Ce qui se passe réellement (inclure les messages d'erreur, logs backend) |
+| **Comportement attendu** | Ce qui devrait se passer |
+| **Contexte** | OS, navigateur (pour les bugs frontend), version Python/Node si pertinent |
 
-Pour les failles de sécurité, ne pas ouvrir d'issue publique. Contacter directement l'auteur.
+Pour les failles de sécurité, **ne pas ouvrir d'issue publique**. Contacter directement l'auteur.
 
 ---
 
 ## Proposer une contribution
 
-1. Ouvrir une issue pour discuter de la modification avant de coder, sauf pour les corrections triviales (faute d'orthographe, lien cassé).
+### 1. Discuter avant de coder
-2. Forker le dépôt et créer une branche à partir de `main`.
+
-3. Respecter les conventions existantes : TypeScript strict côté frontend, Python 3.11+ côté backend, pas d'ORM, pas de dépendances superflues.
+Ouvrir une issue pour décrire la modification envisagée, sauf pour les corrections triviales (faute d'orthographe, lien cassé, coquille dans la doc). Cela évite de travailler dans le vide si la direction ne correspond pas au projet.
-4. Toute modification fonctionnelle doit être testable manuellement — décrire la procédure de test dans la PR.
+
-5. Ne pas modifier le fichier `LICENSE` ni les en-têtes de copyright.
+### 2. Préparer l'environnement
-6. Soumettre la pull request sur le miroir GitHub avec une description claire du problème résolu et de l'approche retenue.
+
+```bash
+# Forker le dépôt sur GitHub, puis cloner votre fork
+git clone https://github.com/<votre-pseudo>/la-voix-du-peuple.git
+cd la-voix-du-peuple
+
+# Créer une branche nommée selon la convention ci-dessous
+git checkout -b fix/description-courte
+# ou
+git checkout -b feat/description-courte
+```
+
+Convention de nommage des branches :
+
+| Préfixe | Usage |
+|---------|-------|
+| `fix/` | Correction de bug |
+| `feat/` | Nouvelle fonctionnalité |
+| `docs/` | Documentation uniquement |
+| `refactor/` | Refactorisation sans changement de comportement |
+| `chore/` | Maintenance (dépendances, config, scripts) |
+
+### 3. Conventions de code
+
+**Backend (Python)**
+
+| Règle | Détail |
+|-------|--------|
+| Version minimale | Python 3.11 |
+| Pas d'ORM | psycopg2 direct, comme le reste du code |
+| Validation des entrées | Toujours via `sanitize_text()` et `validate_idea_input()` existants |
+| Nouveaux modules | Pas de dépendance externe sans discussion préalable |
+| Secrets | Jamais dans le code — variables d'environnement uniquement |
+
+**Frontend (TypeScript / React)**
+
+| Règle | Détail |
+|-------|--------|
+| Typage | TypeScript strict, pas de `any` |
+| Composants UI | shadcn/ui en priorité, pas de librairie tierce sans discussion |
+| Routing | Wouter — pas de `react-router` |
+| État serveur | `@tanstack/react-query` via le client généré dans `lib/api-client-react` |
+| CSS | Tailwind uniquement, pas de CSS inline arbitraire |
+
+**Commits**
+
+Format : `type: description courte en impératif présent` (anglais)
+
+```
+fix: reject empty author after sanitization
+feat: add webhook retry on consultation close
+docs: clarify REDIS_URL usage in .env.example
+```
+
+Types valides : `fix`, `feat`, `docs`, `refactor`, `chore`, `test`.
+
+### 4. Tester manuellement
+
+Toute modification fonctionnelle doit être testable. Décrire dans la PR :
+
+```
+## Test manuel
+1. Lancer l'env de dev : `bash scripts/dev-local.sh`
+2. Soumettre une contribution via le formulaire
+3. Vérifier que [comportement attendu]
+```
+
+Le projet n'a pas de suite de tests automatisés — la description du test manuel dans la PR en tient lieu.
+
+### 5. Soumettre la pull request
+
+Ouvrir la PR sur le miroir GitHub. Le titre suit la même convention que les commits. Le corps doit contenir :
+
+| Section | Contenu |
+|---------|---------|
+| **Problème** | Référence à l'issue (`Fixes #42`) ou description du problème |
+| **Solution** | Approche retenue et pourquoi |
+| **Test manuel** | Étapes pour vérifier le comportement (voir §4) |
+| **Impact** | Changements de comportement visibles, variables d'environnement ajoutées, migrations BDD |
+
+Ne pas modifier `LICENSE` ni les en-têtes de copyright en tête de fichier.
 
 ---
 

README.md

@@ -4,6 +4,11 @@ Plateforme civique de participation démocratique assistée par intelligence art
 
 Les citoyens soumettent des propositions politiques en texte libre. Chaque contribution est filtrée automatiquement selon le droit international des droits humains et le droit pénal français, puis intégrée à une synthèse thématique collective générée par IA. La plateforme fonctionne en mode ouvert (contributions globales) ou en mode consultation ciblée (sujet défini, dates de début et de fin, organisateur identifié). Elle ne produit pas un consensus : elle donne à voir ce que des citoyens ont choisi d'exprimer, tel quel.
 
+La Voix du Peuple est un projet personnel open-source. Si vous l'utilisez et voulez soutenir son développement, un don est toujours bienvenu — mais une étoile sur le dépôt et des retours concrets comptent autant.
+
+- Ko-fi : [LIEN_KO_FI]
+- GitHub Sponsors : [LIEN_GITHUB_SPONSORS]
+
 ---
 
 ## Fonctionnalités
@@ -156,15 +161,6 @@ Les contributions sont les bienvenues. Voir [CONTRIBUTING.md](CONTRIBUTING.md) p
 
 ---
 
-## Soutenir le projet
-
-La Voix du Peuple est un projet personnel open-source. Si vous l'utilisez et voulez soutenir son développement, un don est toujours bienvenu — mais une étoile sur le dépôt et des retours concrets comptent autant.
-
-- Ko-fi : [LIEN_KO_FI]
-- GitHub Sponsors : [LIEN_GITHUB_SPONSORS]
-
----
-
 ## Licence
 
 EUPL-1.2 — voir fichier [LICENSE](LICENSE).