Framework web applicatif Python, explicite et auditable.
Les parcours d'accueil sont exécutés dans de vrais projets, les blocs de commande de la documentation sont lancés, et chaque import ou commande cité est confronté à l'interpréteur et au CLI. Une page qui montre du code promet qu'il fonctionne : cette promesse est désormais vérifiée à chaque intégration, pas relue.
La sonde de disponibilité /health, pourtant au contrat de stabilité, répondait 404 en production. Soixante-cinq tests, dont les trente-trois d'en-têtes de sécurité, ne s'exécutaient plus. Corrigés, et tenus par des garde-fous qui empêchent le retour.
forge make:entity et forge make:relation acceptent la description complète en arguments, champs et relations compris. Un parcours devient rejouable, un projet reproductible, et l'outillage scriptable sans dialogue interactif.
L'audit hebdomadaire des dépendances expédiées a été remis en état, et il a relevé trois avis en moins de vingt-quatre heures. La borne haute de cryptography est levée : cette bibliothèque livre ses correctifs de sécurité dans une nouvelle version majeure, qu'un plafond interdisait au moment même de leur parution.
Installez Forge en quelques minutes sur Debian, Ubuntu ou Linux Mint.
pipx, sans modifier le Python système.
forge new.
Développez avec Forge sous Windows grâce à WSL et Ubuntu 24.04.
Les starters sont des projets pédagogiques pour apprendre Forge pas à pas.
La progression cœur : du premier affichage texte jusqu'à un CRUD complet à SQL visible, palier par palier (HTTP, vues, formulaires, base de données).
Recevoir, stocker et exposer des mesures de capteurs : configuration MQTT, lecture des événements, API HTTP JSON et subscriber temps réel.
La chaîne vidéo complète, brique par brique : upload, lecture en streaming, suivi d'état, sondage et transcodage MP4.
Téléverser, générer des variantes, attacher à une entité, gérer galerie et couverture, puis sécuriser l'upload contre les images piégées.
La brique d'upload générique : stockage sécurisé, service de fichiers, validation, limitation de débit et chemins anti-traversal.
Données de démonstration et de test rejouables : charger, purger, et générer du SQL relu depuis des factories (Faker), à SQL visible.
Téléverser un audio, le lire en streaming, sonder ses métadonnées et le transcoder en MP3, sans état.
Le second facteur de bout en bout : secret TOTP, enrôlement, challenge de connexion, codes de récupération et durcissement.
Le contrôle d'accès par rôles : contrat déclaratif, vérification de permission, garde de route, helper de gabarit et résolution par utilisateur.
Statuts et transitions applicatives : déclarer les passages autorisés, les vérifier, puis afficher des badges de statut.
Le tracking d'événements à SQL visible : schéma, insertion, validation, consultation et normalisation des lignes.
Composer et envoyer des emails : transports interchangeables (console, SMTP, log), templates Jinja et diagnostic du module.
Internationaliser une application : catalogues JSON, locale par défaut et fallback, helper trans() dans les templates.
Le moteur d'entités pas à pas : déclarer une entité, la relier, générer le SQL, le modèle et le CRUD, faire évoluer le schéma par migrations, jusqu'au pivot enrichi.
Générer des QR Codes PNG ou SVG depuis du texte ou une URL, et les servir depuis un contrôleur.
Persister des paramètres applicatifs en base : écrire et lire des valeurs typées via get_setting et set_setting.
Échanger des données en CSV : import validé champ par champ avec rapport d'erreurs, et export programmatique.
Tenir un journal d'audit applicatif : enregistrer et consulter des événements, borné et lisible.
Une file de tâches de fond adossée à votre base de données : enqueue et worker explicite, sans broker ni async.
Des notifications in-app : notifier un utilisateur, lister puis marquer comme lues.
Préparer la mise en production : générer la configuration Nginx, systemd et Gunicorn, puis vérifier l'environnement.
Un store de session persistant adossé à la base : sessions partagées entre workers, portable sur tous les backends.
Un back-office applicatif : CRUD générique sur les entités déclarées, avec auth, CSRF et RBAC optionnel.
Construire vos propres façades applicatives (Session, Cookies, Flash) au-dessus du noyau minimal, sans alourdir Forge.
Rédiger une page de documentation Forge palier par palier : titres, listes, tableaux, encadrés, code, onglets, diagrammes et toutes les extensions Markdown.
Construire des outils interactifs (calculateur de sous-réseau, oscilloscope) sous CSP stricte, sans SPA ni CDN : SSR pur et JavaScript local.
Utiliser le système de design livré par forge new, palier par palier, dans de vraies pages servies par un contrôleur : charte, composants, liste, recherche, pagination, validation.
Le backend de base de données le plus simple, sans serveur : configurer SQLite, appliquer les entités, migrer, inspecter, jusqu'aux particularités du dialecte.
Le backend MariaDB : configuration et connexion, pool, provisionnement de la base, application des entités et migrations.
Le backend PostgreSQL (psycopg) : configuration, application des entités, migrations et particularités du dialecte.
Le backend Microsoft SQL Server (pyodbc) : configuration, application des entités, migrations et particularités du dialecte.
Les briques Python publiques ou semi-publiques de Forge : configuration, HTTP, sessions, sécurité, WSGI.
Les commandes forge ... utilisées pour créer, diagnostiquer, générer et maintenir un projet Forge.
Les objets Request,
Response,
Router
et le fonctionnement des routes.
La structure mvc/routes/ et
mvc/controllers/
utilisée par les applications Forge.
L'entrée create_configured_wsgi_app() pour brancher Forge derrière un serveur WSGI externe (Gunicorn, …).
Accès à la documentation technique détaillée : modèle d'entités, schémas JSON, contrats publics.
Requêtes, réponses, routes nommées et contrôleurs explicites.
Structure claire : contrôleurs, modèles, vues, routes et formulaires.
Rendu serveur lisible, layouts publics/admin et composants simples.
Fichiers SQL auditables, sans ORM opaque imposé par défaut.
Une source canonique pour générer SQL, modèles et CRUD, avec des types explicites, dont le slug auto-généré depuis un champ source.
Migrations SQL versionnées, contrôlables et lisibles.
Back-office explicite, modifiable et non destructif, avec lecture par slug et unicité garantie.
Champs typés, validation serveur et messages clairs.
CSRF, sessions, headers HTTP, cookies durcis et audit complet.
Login, sessions, hachage Argon2id, vérification email et reset de mot de passe.
Tailwind officiel, HTMX recommandé, Alpine.js optionnel.
Validation du modèle d'entité, autocomplete VS Code et forge entity:validate.
Générer, vérifier, diagnostiquer et brancher les opt-in : famille unifiée opt-in:install / remove / enable / disable / list.
Nginx, systemd, check sécurité-prod du doctor, migrations en --dry-run et checklist de déploiement.
Endpoints JSON explicites avec auth Bearer, sans transformer Forge en moteur d'API.
Chaque brique s'installe à la carte, le cœur ne dépend d'aucune. Il est aussi agnostique de la base de données : vous choisissez un seul backend parmi SQLite, MariaDB, PostgreSQL et SQL Server, tous au niveau plein.
Backend MariaDB : serveur de production, connexion admin dédiée et migrations à SQL visible.
Backend SQLite : zéro configuration, un seul fichier, idéal en développement et pour les tests.
Backend PostgreSQL : dialecte, provisioning db:init et intégration validés en continu sur serveur réel.
Backend SQL Server : dialecte, provisioning db:init et intégration validés en continu sur serveur réel.
Authentification multi-facteurs : TOTP, codes de récupération, challenge à la connexion.
Rôles, permissions fines, helpers Jinja et décorateurs @require_permission.
Statuts et transitions applicatives : brouillon → publié → archivé.
Tracking d'événements applicatifs génériques : page vues, clics, conversions.
Upload générique : écriture sécurisée anti-traversal, stockage et service de fichiers (HTTP Range).
Données de démonstration et de test rejouables : charger, purger, générer du SQL relu depuis des factories (Faker).
Traitement d'images (Pillow) : variantes, galerie, couverture et garde anti-image-bombe à l'upload.
Réception et exposition de données IoT via MQTT : subscriber, stockage d'événements, API JSON.
Upload, transcodage MP4 (H.264/AAC) et lecture vidéo en streaming HTTP Range.
Upload, sondage (ffprobe), transcodage MP3 (ffmpeg) et lecture audio en streaming HTTP Range.
Envoi d'emails : composition, transports interchangeables (console, SMTP, log), templates Jinja et CLI mail:*.
Moteur d'entités : make:entity, relations many_to_one et many_to_many (pivot enrichi), build:model, migrations et make:crud.
Internationalisation : traduction par catalogues JSON, locale par défaut et fallback, helper trans() pour les templates.
Génération de QR Codes PNG ou SVG depuis du texte ou une URL, réponse HTTP servable depuis un contrôleur.
Paramètres applicatifs persistés en base (table app_settings), API explicite get_setting et set_setting.
Store de session persistant adossé à la base (DbSessionStore) : sessions partagées entre workers, concurrence optimiste.
Échange CSV : import validé par champ avec rapport d'erreurs, et export programmatique to_csv.
Journal d'audit applicatif (table audit_log) : record_audit et get_audit_log, borné, pas un SIEM.
File de tâches de fond adossée à votre base de données : enqueue et worker explicite, sans broker ni async.
Notifications in-app (table notifications) : notify, get_notifications, mark_read.
Outillage de déploiement CLI-only : deploy:init (Nginx, systemd, wsgi.py) et deploy:check.
Back-office applicatif opt-in : CRUD générique sur les entités déclarées, auth, CSRF et RBAC optionnel.
Forge automatise les répétitions, mais les fichiers restent visibles, auditables et modifiables.
1. Tout part d'un fichier JSON d'entité canonique, source unique du modèle.
2. La commande forge entity:validate vérifie le contrat avant toute génération.
3. Le SQL et les migrations demeurent visibles et lisibles.
4. Le modèle *_base.py est régénéré à chaque exécution.
5. Le modèle manuel, lui, est toujours préservé.
6. Le contrôleur, le formulaire et les vues CRUD sont ensuite échafaudés.
7. Il en résulte une application MVC claire et maintenable.
$ forge new mon-app $ cd mon-app $ forge make:entity Contact $ forge make:crud Contact --dry-run $ forge make:crud Contact
{
"$schema": "../../schemas/entity.schema.json",
"schema_version": "1.0",
"name": "Contact",
"table": "contacts",
"label": "Contact",
"plural_label": "Contacts",
"fields": [
{ "name": "email", "type": "email", "required": true },
{ "name": "message", "type": "text", "required": true }
],
"options": { "timestamps": true }
}
$ forge make:crud Contact # Génère : [CRÉÉ] mvc/controllers/contact_controller.py [CRÉÉ] mvc/models/contact_model.py [CRÉÉ] mvc/forms/contact_form.py [CRÉÉ] mvc/views/contact/index.html [CRÉÉ] mvc/views/contact/show.html [CRÉÉ] mvc/views/contact/form.html
from core.http.router import Router from mvc.controllers.contact_controller import ContactController router = Router() with router.group("/contacts") as contacts: contacts.add("GET", "/", ContactController.index, name="contacts.index")
$ forge make:crud Contact --dry-run [DRY-RUN] mvc/controllers/contact_controller.py [DRY-RUN] mvc/models/contact_model.py [DRY-RUN] mvc/views/contact/form.html [DRY-RUN] Aucun fichier modifié. # Prévisualiser avant d'écrire. # Comprendre avant de modifier. # Garder la main.
Pour toute question sur Forge, retour d'usage, remontée de bug ou demande de licence.
Roger Lequette · forgemvc@gmail.com
Écrire à Forge