Bonjour,
Merci pour vos commentaires. Vous êtes tous ultra éfficaces.
Voici une synthèse de vos remarques :
A. Numérotation automatique des factures
B. Gestion des clients
C. Catalogue de prestations
D. Historique
E. Version smartphone
Les remarques juridiques
Les remarques d'architecture. → ajouter les mentions légales
Canvas → PDF pas top
Version Desktop
IA ou pas IA ?
Oui ma landing page est faite avec l"IA. Dans la vie, je fais du support technique. Je sais lire des logs interminables d’un serveur RADIUS et vous dire pourquoi la connexion VPN plante. Je n'aime pas coder du HTML. Beaucoup de personnes à qui j’ai montré mon projet m'ont fait la remarque qu’il manquait une landing page qui expliquait le projet. Alors oui, j’ai pris l’IA pour faire la landing page. Parce que sinon ça allé prendre trop de temps.
L’application est codée par moi-même quand j’ai le temps. C’est pour ça qu’il n’y a que 3 commits.
Voici un petit topo technique
Architecture du facturier : du formulaire HTML au document Factur-X
Le principe de l'application est volontairement simple pour l'utilisateur : remplir un formulaire, cliquer sur « Générer » et obtenir une facture électronique conforme.
En interne, le traitement est découpé en plusieurs étapes indépendantes afin de séparer explicitement les responsabilités.
L'architecture générale est la suivante :
Interface HTML/JavaScript
│
▼
JSON métier
│
▼
API FastAPI
│
▼
Orchestrateur Python
│
┌──────┴────────┐
▼ ▼
PDF lisible XML CII EN16931
└──────┬────────┘
▼
Fusion Factur-X (PDF/A-3)
▼
Facture électronique finale
L'ensemble du pipeline repose sur un modèle de données unique. Le formulaire HTML ne génère pas directement un PDF ou un XML : il produit un objet JSON représentant la facture. Toutes les étapes suivantes travaillent sur cette même structure de données, ce qui garantit la cohérence entre le document visible par l'utilisateur et les données structurées destinées aux plateformes de dématérialisation (PDP)
La couche de présentation
L'application est composée d'une interface HTML et JavaScript.
Le navigateur construit un objet JSON contenant notamment :
• les informations générales de la facture ;
• le vendeur ;
• l'acheteur ;
• les lignes de facturation ;
• les conditions de paiement ;
• les mentions légales.
Pour faciliter la compréhension de l’application, la partie JavaScript pré-remplit automatiquement certains identifiants techniques propres à la sandbox SuperPDP (endpoint_id, SIREN, etc.) pour deux entreprises fictives. J’ai initialement basé mon projet sur superPDP. C’est un PDP qui propose une API avec une documentation détaillée. Un compte gratuit si on ne dépose pas plus de 1000 factures par mois. L’entreprise Burgeer Queen et Tricatel sont les entreprises de leur Sandbox.
Le navigateur ne produit donc aucun document final.
Il ne fait qu'envoyer un modèle de facture normalisé au serveur.
L'API FastAPI
L'API constitue le point d'entrée de toute l'application.
La route :
POST /api/generate-facturx
reçoit le JSON transmis par le navigateur.
Avant tout traitement :
• le payload est validé par Pydantic ;
• les types sont contrôlés ;
• les champs obligatoires sont vérifiés.
Une fois ces contrôles effectués, l'API ne réalise aucun traitement métier.
Son rôle est simplement de transmettre le modèle de facture à l'orchestrateur principal.
Cette séparation permet de conserver une API très légère.
L'orchestrateur
Le cœur de l'application est la fonction :
generate_all_from_json()
Elle coordonne l'ensemble du pipeline.
Son rôle consiste à exécuter successivement trois traitements indépendants :
JSON
│
├──► génération PDF
│
├──► génération XML CII
│
└──► fusion Factur-X
Chaque étape possède son propre script spécialisé.
L'orchestrateur ne connaît pas le détail de leur implémentation.
Il se contente de leur fournir les données et de récupérer les fichiers produits.
Cette architecture facilite les évolutions futures.
Par exemple, il serait possible de remplacer complètement le moteur PDF sans modifier le générateur XML.
Génération du PDF lisible
La première étape consiste à produire une facture lisible par un utilisateur.
Cette partie est réalisée avec ReportLab.
Le moteur effectue plusieurs traitements successifs.
Normalisation des données
Les adresses sont restructurées afin d'obtenir systématiquement :
• rue ;
• code postal ;
• ville ;
• pays.
Cette étape évite de propager des formats différents dans le reste de l'application.
Recalcul complet des montants
Le serveur ne fait jamais confiance aux calculs effectués dans le navigateur.
Toutes les lignes sont recalculées à partir des données brutes.
Les calculs utilisent systématiquement Decimal afin d'éviter les erreurs liées aux nombres flottants.
Les montants sont arrondis selon les règles comptables (ROUND_HALF_UP).
Le moteur calcule ensuite :
• total HT ;
• TVA par taux ;
• total TTC.
Construction du document
Le PDF est entièrement construit par Python.
Chaque bloc de la facture possède sa propre fonction :
• coordonnées ;
• informations générales ;
• tableau des lignes ;
• TVA ;
• mentions légales ;
• paiement.
Avant chaque généraion de page, le moteur estime la hauteur nécessaire.
S'il ne reste plus suffisamment d'espace sur la page, une nouvelle page est automatiquement créée et l'en-tête est redessiné.
Le tableau des lignes utilise les composants de ReportLab capables de gérer automatiquement le retour à la ligne des descriptions longues.
Le résultat est un PDF classique, destiné uniquement à la lecture humaine.
Génération du XML CII
Le second traitement produit les données structurées conformément au standard Factur-X.
Contrairement au PDF, il ne s'agit plus de mise en page mais uniquement de données métier.
Le générateur construit un document XML conforme au modèle : CrossIndustryInvoice défini par UN/CEFACT et le profil EN16931.
Le document est organisé autour de plusieurs sections :
• contexte du document ;
• informations générales ;
• lignes de facture ;
• vendeur ;
• acheteur ;
• taxes ;
• totaux ;
• paiement.
Le générateur utilise les espaces de noms XML officiels (rsm, ram, udt) afin de produire un document directement exploitable par les validateurs et les plateformes de dématérialisation.
Enrichissement métier
Avant la génération du XML, certaines informations sont enrichies automatiquement.
Pour la sandbox SuperPDP, le générateur complète notamment :
• SIREN ;
• endpoint électronique ;
• identifiant légal ;
• identifiant global.
Cette logique est actuellement limitée aux entreprises de démonstration mais prépare le futur raccordement à un véritable annuaire PDP.
Normalisation des données
Le générateur convertit également plusieurs informations vers les codes normalisés attendus par EN16931.
Par exemple :
• unités UN/CEFACT ;
• catégories de TVA ;
• quantités ;
• montants.
Le XML obtenu est totalement indépendant de la présentation graphique.
Construction du document Factur-X
Une fois le PDF et le XML produits, le dernier traitement consiste à créer un véritable document Factur-X.
Cette étape est volontairement déléguée à la bibliothèque spécialisée factur-x.
Le projet ne réimplémente donc pas les mécanismes complexes liés au standard PDF/A-3.
La bibliothèque prend en charge :
• la conversion en PDF/A-3 ;
• l'intégration du XML dans le PDF ;
• les métadonnées XMP ;
• la création du document Factur-X final.
Le résultat reste un fichier PDF parfaitement lisible tout en contenant l'ensemble des données structurées destinées aux traitements automatiques.
Une architecture fondée sur la séparation des responsabilités
L'application repose sur un principe simple :
• le navigateur construit les données ;
• l'API valide les données ;
• l'orchestrateur pilote les traitements ;
• un moteur produit le PDF ;
• un moteur produit le XML ;
• une bibliothèque assemble le document Factur-X.
Chaque composant possède une responsabilité unique.
Cette organisation présente plusieurs avantages :
• facilité de maintenance ;
• faible couplage entre les composants ;
• possibilité de remplacer un moteur sans modifier le reste de l'application ;
• meilleure testabilité ;
• préparation aux évolutions futures (nouveaux moteurs PDF, autres formats XML, intégration de plusieurs PDP).
# merci pour vos commentaires
Posté par sebastien67 . En réponse au journal Je développe un facturier électronique libre pour les artisans. Évalué à 1 (+5/-4).
Bonjour,
Merci pour vos commentaires. Vous êtes tous ultra éfficaces.
Voici une synthèse de vos remarques :
A. Numérotation automatique des factures
B. Gestion des clients
C. Catalogue de prestations
D. Historique
E. Version smartphone
Les remarques juridiques
Les remarques d'architecture. → ajouter les mentions légales
Canvas → PDF pas top
Version Desktop
IA ou pas IA ?
Oui ma landing page est faite avec l"IA. Dans la vie, je fais du support technique. Je sais lire des logs interminables d’un serveur RADIUS et vous dire pourquoi la connexion VPN plante. Je n'aime pas coder du HTML. Beaucoup de personnes à qui j’ai montré mon projet m'ont fait la remarque qu’il manquait une landing page qui expliquait le projet. Alors oui, j’ai pris l’IA pour faire la landing page. Parce que sinon ça allé prendre trop de temps.
L’application est codée par moi-même quand j’ai le temps. C’est pour ça qu’il n’y a que 3 commits.
Voici un petit topo technique
Architecture du facturier : du formulaire HTML au document Factur-X
Le principe de l'application est volontairement simple pour l'utilisateur : remplir un formulaire, cliquer sur « Générer » et obtenir une facture électronique conforme.
En interne, le traitement est découpé en plusieurs étapes indépendantes afin de séparer explicitement les responsabilités.
L'architecture générale est la suivante :
Interface HTML/JavaScript
│
▼
JSON métier
│
▼
API FastAPI
│
▼
Orchestrateur Python
│
┌──────┴────────┐
▼ ▼
PDF lisible XML CII EN16931
└──────┬────────┘
▼
Fusion Factur-X (PDF/A-3)
▼
Facture électronique finale
L'ensemble du pipeline repose sur un modèle de données unique. Le formulaire HTML ne génère pas directement un PDF ou un XML : il produit un objet JSON représentant la facture. Toutes les étapes suivantes travaillent sur cette même structure de données, ce qui garantit la cohérence entre le document visible par l'utilisateur et les données structurées destinées aux plateformes de dématérialisation (PDP)
Pour faciliter la compréhension de l’application, la partie JavaScript pré-remplit automatiquement certains identifiants techniques propres à la sandbox SuperPDP (endpoint_id, SIREN, etc.) pour deux entreprises fictives. J’ai initialement basé mon projet sur superPDP. C’est un PDP qui propose une API avec une documentation détaillée. Un compte gratuit si on ne dépose pas plus de 1000 factures par mois. L’entreprise Burgeer Queen et Tricatel sont les entreprises de leur Sandbox.
Le navigateur ne produit donc aucun document final.
Il ne fait qu'envoyer un modèle de facture normalisé au serveur.
L'API FastAPI
L'API constitue le point d'entrée de toute l'application.
La route :
POST /api/generate-facturx
reçoit le JSON transmis par le navigateur.
Avant tout traitement :
• le payload est validé par Pydantic ;
• les types sont contrôlés ;
• les champs obligatoires sont vérifiés.
Une fois ces contrôles effectués, l'API ne réalise aucun traitement métier.
Son rôle est simplement de transmettre le modèle de facture à l'orchestrateur principal.
Cette séparation permet de conserver une API très légère.
L'orchestrateur
Le cœur de l'application est la fonction :
generate_all_from_json()
Elle coordonne l'ensemble du pipeline.
Son rôle consiste à exécuter successivement trois traitements indépendants :
JSON
│
├──► génération PDF
│
├──► génération XML CII
│
└──► fusion Factur-X
Chaque étape possède son propre script spécialisé.
L'orchestrateur ne connaît pas le détail de leur implémentation.
Il se contente de leur fournir les données et de récupérer les fichiers produits.
Cette architecture facilite les évolutions futures.
Par exemple, il serait possible de remplacer complètement le moteur PDF sans modifier le générateur XML.
Les adresses sont restructurées afin d'obtenir systématiquement :
• rue ;
• code postal ;
• ville ;
• pays.
Cette étape évite de propager des formats différents dans le reste de l'application.
Recalcul complet des montants
Le serveur ne fait jamais confiance aux calculs effectués dans le navigateur.
Toutes les lignes sont recalculées à partir des données brutes.
Les calculs utilisent systématiquement Decimal afin d'éviter les erreurs liées aux nombres flottants.
Les montants sont arrondis selon les règles comptables (ROUND_HALF_UP).
Le moteur calcule ensuite :
• total HT ;
• TVA par taux ;
• total TTC.
Construction du document
Le PDF est entièrement construit par Python.
Chaque bloc de la facture possède sa propre fonction :
• coordonnées ;
• informations générales ;
• tableau des lignes ;
• TVA ;
• mentions légales ;
• paiement.
Avant chaque généraion de page, le moteur estime la hauteur nécessaire.
S'il ne reste plus suffisamment d'espace sur la page, une nouvelle page est automatiquement créée et l'en-tête est redessiné.
Le tableau des lignes utilise les composants de ReportLab capables de gérer automatiquement le retour à la ligne des descriptions longues.
Le résultat est un PDF classique, destiné uniquement à la lecture humaine.
Le document est organisé autour de plusieurs sections :
• contexte du document ;
• informations générales ;
• lignes de facture ;
• vendeur ;
• acheteur ;
• taxes ;
• totaux ;
• paiement.
Le générateur utilise les espaces de noms XML officiels (rsm, ram, udt) afin de produire un document directement exploitable par les validateurs et les plateformes de dématérialisation.
Enrichissement métier
Avant la génération du XML, certaines informations sont enrichies automatiquement.
Pour la sandbox SuperPDP, le générateur complète notamment :
• SIREN ;
• endpoint électronique ;
• identifiant légal ;
• identifiant global.
Cette logique est actuellement limitée aux entreprises de démonstration mais prépare le futur raccordement à un véritable annuaire PDP.
Normalisation des données
Le générateur convertit également plusieurs informations vers les codes normalisés attendus par EN16931.
Par exemple :
• unités UN/CEFACT ;
• catégories de TVA ;
• quantités ;
• montants.
Le XML obtenu est totalement indépendant de la présentation graphique.
Cette étape est volontairement déléguée à la bibliothèque spécialisée factur-x.
Le projet ne réimplémente donc pas les mécanismes complexes liés au standard PDF/A-3.
La bibliothèque prend en charge :
• la conversion en PDF/A-3 ;
• l'intégration du XML dans le PDF ;
• les métadonnées XMP ;
• la création du document Factur-X final.
Le résultat reste un fichier PDF parfaitement lisible tout en contenant l'ensemble des données structurées destinées aux traitements automatiques.
Une architecture fondée sur la séparation des responsabilités
L'application repose sur un principe simple :
• le navigateur construit les données ;
• l'API valide les données ;
• l'orchestrateur pilote les traitements ;
• un moteur produit le PDF ;
• un moteur produit le XML ;
• une bibliothèque assemble le document Factur-X.
Chaque composant possède une responsabilité unique.
Cette organisation présente plusieurs avantages :
• facilité de maintenance ;
• faible couplage entre les composants ;
• possibilité de remplacer un moteur sans modifier le reste de l'application ;
• meilleure testabilité ;
• préparation aux évolutions futures (nouveaux moteurs PDF, autres formats XML, intégration de plusieurs PDP).