pre merge

2025-08-27 23:41:25 +02:00 · 2025-08-27 23:41:25 +02:00 · be5a5200d0
commit be5a5200d0
parent a7c6559620
13 changed files with 82 additions and 21 deletions
--- a/AGENTS.md
+++ b/AGENTS.md
@ -5,13 +5,13 @@
 - [Introduction](#introduction)
 - [Principes communs](#principes-communs)
 - [Agents fondamentaux](#agents-fondamentaux)
- [Agents spécialisés documentation](#agents-specialises-documentation)
- [Agents spécialisés tests](#agents-specialises-tests)
+- [Agents spécialisés documentation] (#agents-specialises-documentation)
+- [Agents spécialisés tests] (#agents-specialises-tests)
 - [Agents techniques](#agents-techniques)
 - [Agents frontend](#agents-frontend)
 - [Agents open source et CI](#agents-open-source-et-ci)
- [Agents de synchronisation et dérogations](#agents-de-synchronisation-et-derogations)
- [Matrice de coordination](#matrice-de-coordination)
+- [Agents de synchronisation et dérogations] (#agents-de-synchronisation-et-derogations)
+- [Matrice de coordination] (#matrice-de-coordination)
 - [Conclusion](#conclusion)

 ---
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@ -40,7 +40,6 @@ et ce projet adhère au [Semantic Versioning](https://semver.org/spec/v2.0.0.htm
 - Normalisation MD005/MD007/MD051 dans la documentation
 - Ancrages ASCII dans `AGENTS.md`, correction des titres emphase (MD036)

-
 - Documentation projet réécrite à partir des modèles `docs/templates/**` (générique, non applicative)
 - `docs/INDEX.md` mis à jour (liens Déploiement et SSH)
 - Alignement documentaire sur 4NK_template (titres, liens Gitea, wording) dans docs/**
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@ -4,16 +4,16 @@ Merci de votre intérêt pour contribuer au projet 4NK Node ! Ce guide vous aide

 ## 📋 Table des Matières

- [🎯 Comment Contribuer](#comment-contribuer)
- [🚀 Premiers Pas](#premiers-pas)
- [🔧 Environnement de Développement](#environnement-de-developpement)
- [📝 Processus de Contribution](#processus-de-contribution)
- [🧪 Tests](#tests)
- [📚 Documentation](#documentation)
- [🐛 Signaler un Bug](#signaler-un-bug)
- [💡 Proposer une Fonctionnalité](#proposer-une-fonctionnalite)
- [🔍 Code Review](#code-review)
- [📦 Release](#release)
+- [🎯 Comment Contribuer] (#comment-contribuer)
+- [🚀 Premiers Pas] (#premiers-pas)
+- [🔧 Environnement de Développement] (#environnement-de-developpement)
+- [📝 Processus de Contribution] (#processus-de-contribution)
+- [🧪 Tests] (#tests)
+- [📚 Documentation] (#documentation)
+- [🐛 Signaler un Bug] (#signaler-un-bug)
+- [💡 Proposer une Fonctionnalité] (#proposer-une-fonctionnalite)
+- [🔍 Code Review] (#code-review)
+- [📦 Release] (#release)

 ## 🎯 Comment Contribuer

--- a/SECURITY.md
+++ b/SECURITY.md
@ -9,6 +9,7 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 **NE PAS** créer d'issue publique pour les vulnérabilités de sécurité.

 #### À la place
+
 1. Envoyez un email à [security@4nkweb.com](mailto:security@4nkweb.com)
 2. Incluez "SECURITY VULNERABILITY" dans l'objet
 3. Décrivez la vulnérabilité de manière détaillée
@ -34,6 +35,7 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ### Pour les Contributeurs

 #### Code
+
 - Validez toutes les entrées utilisateur
 - Utilisez des requêtes préparées pour les bases de données
 - Évitez les injections de code
@ -41,12 +43,14 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 - Utilisez HTTPS pour toutes les communications

 #### Configuration
+
 - Ne committez jamais de secrets
 - Utilisez des variables d'environnement pour les données sensibles
 - Vérifiez les permissions des fichiers
 - Maintenez les dépendances à jour

 #### Tests
+
 - Incluez des tests de sécurité
 - Testez les cas limites
 - Validez les entrées malveillantes
@ -55,18 +59,21 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ### Pour les Utilisateurs

 #### Installation
+
 - Utilisez des sources officielles
 - Vérifiez les checksums
 - Maintenez le système à jour
 - Utilisez un pare-feu

 #### Configuration
+
 - Changez les mots de passe par défaut
 - Utilisez des clés SSH fortes
 - Limitez l'accès réseau
 - Surveillez les logs

 #### Opération
+
 - Surveillez les connexions
 - Sauvegardez régulièrement
 - Testez les sauvegardes
@ -77,24 +84,28 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ### Composants Principaux

 #### Bitcoin Core
+
 - **RPC Interface** : Authentification requise
 - **ZMQ** : Communication locale uniquement
 - **P2P** : Validation des blocs
 - **Wallet** : Chiffrement des clés

 #### Blindbit
+
 - **API HTTP** : Validation des entrées
 - **Filtres** : Vérification des signatures
 - **Cache** : Protection contre les attaques DoS
 - **Logs** : Pas d'informations sensibles

 #### SDK Relay
+
 - **WebSocket** : Validation des messages
 - **Synchronisation** : Authentification des pairs
 - **Cache** : Protection contre les attaques
 - **Configuration** : Validation des paramètres

 #### Tor
+
 - **Proxy** : Configuration sécurisée
 - **Contrôle** : Accès restreint
 - **Logs** : Anonymisation
@ -103,6 +114,7 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ### Tests de Sécurité

 #### Tests Automatisés
+
 ```bash
 # Tests de sécurité
 ./tests/run_security_tests.sh
@ -115,6 +127,7 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ```

 #### Tests Manuels
+
 - Tests de pénétration
 - Audit de code
 - Tests de configuration
@ -147,6 +160,7 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ## 📋 Checklist de Sécurité

 ### Avant le Déploiement
+
 - [ ] Audit de code de sécurité
 - [ ] Tests de vulnérabilités
 - [ ] Vérification des dépendances
@ -154,6 +168,7 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 - [ ] Tests de charge

 ### Pendant l'Opération
+
 - [ ] Monitoring de sécurité
 - [ ] Surveillance des logs
 - [ ] Mise à jour des composants
@ -161,6 +176,7 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 - [ ] Tests de récupération

 ### Après un Incident
+
 - [ ] Analyse post-mortem
 - [ ] Mise à jour des procédures
 - [ ] Formation de l'équipe
@ -170,18 +186,21 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ## 🔧 Outils de Sécurité

 ### Monitoring
+
 - **Logs** : Centralisation et analyse
 - **Métriques** : Surveillance en temps réel
 - **Alertes** : Notification automatique
 - **Tableaux de bord** : Vue d'ensemble

 ### Tests
+
 - **SAST** : Analyse statique
 - **DAST** : Tests dynamiques
 - **IAST** : Tests interactifs
 - **Fuzzing** : Tests de robustesse

 ### Protection
+
 - **WAF** : Pare-feu applicatif
 - **IDS/IPS** : Détection d'intrusion
 - **Antivirus** : Protection des endpoints
@ -190,18 +209,21 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ## 📚 Ressources

 ### Documentation
+
 - [Guide de Sécurité Bitcoin](https://bitcoin.org/en/security)
 - [OWASP Top 10](https://owasp.org/www-project-top-ten/)
 - [CWE/SANS Top 25](https://cwe.mitre.org/top25/)
 - [NIST Cybersecurity Framework](https://www.nist.gov/cyberframework)

 ### Outils
+
 - [Bandit](https://bandit.readthedocs.io/) - Analyse Python
 - [Clang Static Analyzer](https://clang-analyzer.llvm.org/) - Analyse C/C++
 - [SonarQube](https://www.sonarqube.org/) - Qualité du code
 - [OpenVAS](https://www.openvas.org/) - Scan de vulnérabilités

 ### Formation
+
 - Cours de sécurité applicative
 - Formation aux tests de pénétration
 - Certification en cybersécurité
@ -210,18 +232,21 @@ Nous prenons la sécurité très au sérieux. Si vous découvrez une vulnérabil
 ## 🤝 Collaboration

 ### Bug Bounty
+
 - Programme de récompenses pour les vulnérabilités
 - Critères d'éligibilité
 - Montants des récompenses
 - Processus de validation

 ### Responsible Disclosure
+
 - Timeline de divulgation
 - Coordination avec les chercheurs
 - Communication publique
 - Remerciements

 ### Communauté
+
 - Groupe de sécurité
 - Discussions techniques
 - Partage d'informations
--- a/docs/project/GITEA_SETUP.md
+++ b/docs/project/GITEA_SETUP.md
@ -1,29 +1,35 @@
 # Configuration Gitea — 4NK_template (projet)

 ## 1. Repository
+
 - Activer les Actions (workflows `.gitea/workflows/*.yml`)
 - Vérifier les templates d’issues/PR

 ## 2. Protections de branches
+
 - Reviews requises avant merge
 - Status checks requis (CI verte)
 - Mise à jour obligatoire de la branche avant merge

 ## 3. Secrets et variables
+
 - Secrets: `OPENAI_API_KEY` (optionnel), `RELEASE_TOKEN` (obligatoire pour publier les releases via API Gitea)
 - Variables: paramètres de CI non sensibles, ex: `OPENAI_MODEL`, `OPENAI_API_BASE`, `OPENAI_TEMPERATURE`, `GITEA_BASE_URL`

 ### Ajouter `RELEASE_TOKEN`
+
 - Aller dans Repository Settings → Secrets → New Repository Secret
 - Nom: `RELEASE_TOKEN` ; Valeur: un token personnel avec portée API sur le dépôt
 - Le job `release-create` utilisera ce secret lors d’un push de tag `v*`

 ## 4. Workflows requis
+
 - `code-quality`, `unit-tests`, `documentation-tests`, `security-audit`
 - `deployment-checks`, `bash-required`, `markdownlint`, `release-guard`, `release-create`
 - (Optionnels) `agents-smoke`, `openia-agents`

 ## 5. Processus PR
+
 - Branche dédiée, PR petite et ciblée
 - CI verte, review approuvée
 - Doc et changelog à jour
--- a/docs/project/OPEN_SOURCE_GUIDE.md
+++ b/docs/project/OPEN_SOURCE_GUIDE.md
@ -1,15 +1,18 @@
 # Guide open source — 4NK_template (projet)

 ## Pré-requis
+
 - LICENSE, CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md

 ## CI
+
 - tests, lint, security-audit, release-guard, bash-required

 ## Publication
+
 - Alignement version/changelog/tag, notes de release

 ## Communauté
+
 - Templates issues/PR, labels, milestones
 - Divulgation responsable des vulnérabilités
-
--- a/docs/project/QUALITY_STANDARDS.md
+++ b/docs/project/QUALITY_STANDARDS.md
@ -6,4 +6,3 @@
 - Tests verts (catégories pertinentes) et rapports conservés
 - Documentation à jour (INDEX, guides impactés)
 - Sécurité de base: secrets, permissions, audit CI
-
--- a/docs/project/RELEASE_PLAN.md
+++ b/docs/project/RELEASE_PLAN.md
@ -1,20 +1,23 @@
 # Plan de release — 4NK_template (projet)

 ## Objectifs
+
 - Version documentée, testée, sécurisée
 - Processus reproductible et traçable

 ## Préparation
+
 - CI verte: lint/tests/doc/security‑audit/release‑guard
 - Docs à jour (INDEX, guides impactés)
 - Version/Changelog/Tag alignés

 ## Lancement
+
 - Tagging: `vX.Y.Z` ou `vX.Y.Z-wip.N`
 - Notes de release (résumé, changements majeurs, impacts)

 ## Post‑lancement
+
 - Suivi issues/retours
 - Corrections critiques
 - Mise à jour de la roadmap
-
--- a/docs/project/ROADMAP.md
+++ b/docs/project/ROADMAP.md
@ -1,22 +1,25 @@
 # Roadmap — 4NK_template (projet)

 ## Vision
+
 Maintenir un template robuste (docs, CI, sécurité) pour accélérer les projets.

 ## Objectifs (12 mois)
+
 - Qualité: standards renforcés, automatisations CI supplémentaires
 - Documentation: squelettes enrichis, index cohérents
 - Sécurité: contrôles CI étendus, guides pratiques
 - Outillage: agents élargis, rapports synthétiques

 ## Jalons
+
 - T1: Mise à jour squelettes docs et agents
 - T2: Extensions CI (lint multi‑langages, déploiement dry‑run)
 - T3: Guides open source/qualité consolidés
 - T4: Synchronisation de template outillée

 ## Mesure du progrès
+
 - CI verte en continu
 - Adoption des squelettes par projets
 - Diminution des écarts de conformité
-
--- a/docs/project/SECURITY_AUDIT.md
+++ b/docs/project/SECURITY_AUDIT.md
@ -1,24 +1,28 @@
 # Audit de sécurité — 4NK_template (projet)

 ## Menaces
+
 - Secrets, permissions, endpoints sensibles, dépendances, supply chain

 ## Contrôles
+
 - Scan secrets/permissions
 - Audit dépendances (outil selon la pile des projets)
 - Vérifs de configuration (auth/TLS/CORS/rate‑limit)
 - Journalisation sécurité, traçabilité

 ## CI
+
 - Job `security-audit` échoue si alerte critique
 - Rapports archivés en artefacts

 ## Politique des secrets
+
 - Exclusivement secrets CI/variables d’environnement
 - Rotation régulière, révocation sur incident
 - Aucun secret en clair dans le dépôt

 ## Remédiation
+
 - Prioriser, corriger, documenter dans `CHANGELOG.md`
 - Ajouter des tests de non‑régression sécurité si pertinent
-
--- a/docs/project/USAGE.md
+++ b/docs/project/USAGE.md
@ -3,54 +3,63 @@
 Ce document explique comment utiliser le template pour initier, documenter, contrôler et publier des projets dérivés, en respectant les standards qualité, sécurité et open source.

 ## 1. Pré‑requis
+
 - Git opérationnel et accès à votre forge (Gitea recommandé)
 - CI activée sur le repository
 - bash disponible pour les agents (recommandé). À défaut, fallback PowerShell local

 ## 2. Démarrer un projet dérivé
+
 1) Créer un repository à partir de 4NK_template
 2) Copier/adapter la documentation depuis `docs/templates/**` vers votre `docs/**`
 3) Tenir `docs/INDEX.md` et `CHANGELOG.md` à jour
 4) Activer les workflows CI et vérifier `release-guard`/`security-audit`

 ## 3. Documentation
+
 - Utiliser les squelettes de `docs/templates/**` comme base
 - Documenter uniquement votre domaine applicatif (le template reste générique)
 - À chaque changement de code/dépendance/CI, synchroniser la doc correspondante

 ## 4. Agents (contrôles)
+
 - Recommandé (bash): `scripts/agents/run.sh [target_dir] [output_dir] [agent]`
 - Windows fallback: `scripts/agents/run.ps1 -TargetDir . -OutputDir tests/reports/agents -Agent <nom>`
 - Rapports: `tests/reports/agents/*.md`
 - Agents utiles en premier passage: `documentation`, `quality-technique`, `open-source`, `securite`, `deploiement`

 ## 5. Qualité et CI
+
 - Jobs attendus: qualité, tests (catégories pertinentes), documentation, security‑audit, bash‑required, release‑guard
 - `bash-required` garantit la présence de bash et du runner des agents
 - `release-guard` bloque les publications si tests/doc/build/sécurité/version/changelog/tag ne sont pas cohérents

 ## 6. Sécurité
+
 - Secrets uniquement via la CI (variables d’environnement), jamais en clair dans le dépôt
 - Audit sécurité automatisé (job `security-audit`) et remédiations tracées dans `CHANGELOG.md`

 ## 7. Workflow quotidien
+
 - Éditer: code et documentation (toujours en parallèle)
 - Exécuter: tests locaux, agents (diagnostics)
 - Vérifier: sorties CI, rapports `tests/reports/`
 - Commiter: messages clairs, PR petites et ciblées

 ## 8. Publication
+
 - Choisir `latest` (tag `vX.Y.Z`) ou `wip` (ex: `vX.Y.Z-wip.N`)
 - Aligner: fichier de version, `CHANGELOG.md`, tag git
 - Déployer si pipeline défini; sinon documenter la procédure

 ## 9. Dépannage
+
 - Agents fallback PowerShell si bash indisponible localement
 - Consulter `tests/reports/agents/*.md` pour les écarts à corriger
 - Vérifier les logs de la CI et le job `release-guard`

 ## 10. Bonnes pratiques
+
 - Pas d’exemples applicatifs dans le template
 - Toujours mettre à jour la documentation et le changelog
 - Réduire la dérive: synchroniser régulièrement vos projets avec les squelettes et standards
-
--- a/docs/templates/README.md
+++ b/docs/templates/README.md
@ -1,14 +1,17 @@
 # README — Template de projet

 ## Présentation
+
 Décrivez brièvement l’objectif du projet, son périmètre et ses utilisateurs cibles.

 ## Démarrage rapide
+
 - Prérequis (langages/outils)
 - Étapes d’installation
 - Commandes de démarrage

 ## Documentation
+
 - Index: `docs/INDEX.md`
 - Architecture: `docs/ARCHITECTURE.md`
 - Configuration: `docs/CONFIGURATION.md`
@ -17,8 +20,10 @@ Décrivez brièvement l’objectif du projet, son périmètre et ses utilisateur
 - Déploiement: `docs/DEPLOYMENT.md`

 ## Contribution
+
 - GUIDE: `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`
 - Processus de PR et revues

 ## Licence
+
 - Indiquez la licence choisie (MIT/Apache-2.0/GPL)
--- a/tests/README.md
+++ b/tests/README.md
@ -3,6 +3,7 @@
 Ce répertoire décrit la stratégie et l’organisation des tests exigées par le template 4NK.

 ## Pyramide de tests
+
 - Unit: validation des unités logicielles
 - Integration: interactions multi-composants
 - Connectivity: réseau et endpoints
@ -10,16 +11,20 @@ Ce répertoire décrit la stratégie et l’organisation des tests exigées par
 - Performance: charge et temps de réponse

 ## Exécution
+
 - Local: exécuter les suites pertinentes et déposer les résultats dans `tests/reports`
 - CI: orchestrée par `.gitea/workflows/ci.yml`

 ## Journaux et rapports
+
 - `tests/logs`: journaux d’exécution
 - `tests/reports`: rapports synthétiques

 ## Nettoyage
+
 Utiliser `tests/cleanup.sh` après exécution.

 ## Critères d’acceptation
+
 - Zéro échec avant commit
 - Documentation associée à jour dans `docs/TESTING.md`