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 :
-- La version ou le commit concerné
-- Les étapes pour reproduire le problème
-- Le comportement observé et le comportement attendu
-- Le contexte (OS, navigateur, logs backend si disponibles)
+| Champ | Ce qu'on attend |
+|-------|-----------------|
+| **Version / commit** | Le hash court du commit concerné (`git log --oneline -1`) ou le numéro de version |
+| **Étapes pour reproduire** | Séquence minimale et reproductible menant au bug |
+| **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é).
-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.
-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.
-6. Soumettre la pull request sur le miroir GitHub avec une description claire du problème résolu et de l'approche retenue.
+### 1. Discuter avant de coder
+
+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.
+
+### 2. Préparer l'environnement
+
+```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.
 
 ---