philippe.entzmann commented

Member

Description

L'association PDP libre souhaite fournir un service de PA via un partenaire sans attendre la version libre développée ici.

Ce ticket propose de créer un mode proxy où tous les appels API sont redirigés vers un autre PA.

Ce proxy PAC doit pouvoir:

rediriger tous les appels API vers un PA cible défini
définir le PA cible avec son URL et sa clé API
renvoyer le journal des appels API effectués sur une période
maintenir la liste des entreprises autorisées à déposer des factures

Les points listés sont à discuter/affiner.

### Description L'association PDP libre souhaite fournir un service de PA via un partenaire sans attendre la version libre développée ici. Ce ticket propose de créer un mode *proxy* où tous les appels API sont redirigés vers un autre PA. Ce `proxy PAC` doit pouvoir: - rediriger tous les appels API vers un PA cible défini - définir le PA cible avec son URL et sa clé API - renvoyer le journal des appels API effectués sur une période - maintenir la liste des entreprises autorisées à déposer des factures Les points listés sont à discuter/affiner.

philippe.entzmann added the

enhancement

label

2026-03-22 09:43:21 +01:00

philippe.entzmann commented

2026-03-22 09:45:25 +01:00

Author

Member

@teddy.morel : j'ai créé ce ticket car je n'ai pas trouvé de trace de ce sujet évoqué en réunion

👍 1

philippe.entzmann commented

2026-03-22 10:11:50 +01:00

Author

Member

Quelques idées en vrac:

puisque le proxy doit présenter les mêmes API que la brique 01, je propose qu'il soit développé dans la brique 01 comme un mode proxy à activer globalement
les appels API dédiées au proxy seraient pré-fixés /proxy
POST /proxy/target pour définir le PA cible avec {"api_endpoint":"https://api.extrapdp.fr", "api_key":"XXXXXX"}
la partie journalisation des appels sera aussi utile à pac0, je propose donc de pré-fixer par /user pour la gestion des entreprises et /report pour récupérer les journaux
POST /user pour ajouter une nouvelle entreprise (payload à définir)
GET /user/jwt pour obtenir un token JWT pour authentifier les appels API utilisateur
GET /report pour récupérer le journal brut des accès
GET /report/stat pour récupérer des stats sur les accès (plus simple pour comptabiliser/facturer)
les appels API /proxy, /user, /report sont protégés par une clé API majeure (token JWT) qui sera généré par le CLI
pour les factures déposées au format PDF factur-x on pourrait se dispenser d'authentification et s'appuyer sur la signature électronique du PDF

à discuter/affiner

Quelques idées en vrac: - puisque le proxy doit présenter les mêmes API que la brique 01, je propose qu'il soit développé dans la brique 01 comme un **mode proxy** à activer globalement - les appels API dédiées au proxy seraient pré-fixés `/proxy` - `POST /proxy/target` pour définir le PA cible avec `{"api_endpoint":"https://api.extrapdp.fr", "api_key":"XXXXXX"}` - la partie journalisation des appels sera aussi utile à `pac0`, je propose donc de pré-fixer par `/user` pour la gestion des entreprises et `/report` pour récupérer les journaux - `POST /user` pour ajouter une nouvelle entreprise (payload à définir) - `GET /user/jwt` pour obtenir un token JWT pour authentifier les appels API utilisateur - `GET /report` pour récupérer le journal brut des accès - `GET /report/stat` pour récupérer des stats sur les accès (plus simple pour comptabiliser/facturer) - les appels API `/proxy`, `/user`, `/report` sont protégés par une clé API majeure (token JWT) qui sera généré par le CLI - pour les factures déposées au format PDF factur-x on pourrait se dispenser d'authentification et s'appuyer sur la signature électronique du PDF à discuter/affiner

pscoffoni commented

2026-03-22 13:56:28 +01:00

Owner

Bonjour,
Merci @philippe.entzmann
Je complète avec une donnée technique importante. Ce proxy devra être en lien avec l'instance Dolibarr de l'association qui va gérer la facturation.
L'idées est effectivement de faire de ce proxy une première brique opérationnelle au 1er septembre pour le coup. Il va fallori savoir vite si c'est jouable ou pas et de quelle capacité de développement on disposera.
Je vais faire une spécification fonctionnelle de ce point.

Je rebondis aussi sur ce point "s'appuyer sur la signature électronique du PDF"
Il n'y a pas d'obligation de signature électronique des factures dans le cadre de la réforme. Avant la réforme, le droit fiscal français reconnaissait trois pistes d'audit pour les factures dématérialisées : la signature électronique qualifiée, l'EDI fiscal, ou la piste d'audit fiable. La réforme remplace ces mécanismes par le passage obligatoire via les plateformes certifiées.

Bonjour, Merci @philippe.entzmann Je complète avec une donnée technique importante. Ce proxy devra être en lien avec l'instance Dolibarr de l'association qui va gérer la facturation. L'idées est effectivement de faire de ce proxy une première brique opérationnelle au 1er septembre pour le coup. Il va fallori savoir vite si c'est jouable ou pas et de quelle capacité de développement on disposera. Je vais faire une spécification fonctionnelle de ce point. Je rebondis aussi sur ce point "s'appuyer sur la signature électronique du PDF" Il n'y a pas d'obligation de signature électronique des factures dans le cadre de la réforme. Avant la réforme, le droit fiscal français reconnaissait trois pistes d'audit pour les factures dématérialisées : la signature électronique qualifiée, l'EDI fiscal, ou la piste d'audit fiable. La réforme remplace ces mécanismes par le passage obligatoire via les plateformes certifiées.

👍 1

philippe.entzmann commented

2026-03-23 12:35:33 +01:00

Author

Member

Merci @pscoffoni pour la réponse ... et pour la spécification fonctionnelle à venir 😉

OK pour le lien avec Dolibarr.

Je suggère que cette passerelle proxy pac <--> dolibarr soit un outil qui grossièrement:

se connecte à Dolibarr via API
se connecte au proxy pac via API
récupère les clients Dolibarr éligibles et mettre à jour le proxy
récupérera les stats d'utilisation du proxy pour la période de facturation en cours
pour chaque client identifié dans ces stats (par son SIREN):
- crée une nouvelle facture dans Dolibarr si inexistante
- attache à la facture les stats d'utilisation (niveau de détail à définir)
crée ou met-à-jour un ticket/page wiki dans dolibarr pour un rapport final

C'est donc un outil externe qui va dialoguer avec les API Dolibarr et proxy.

A voir en fonction des ressources, des technos ... et du calendrier

Sur la base d'une première version des specs, je suggère de faire un POC en quelques jour pour voir si l'échéance de septembre est réaliste.

Merci également pour les précisions sur la signature électronique PDF. C'est un sujet qui m'intéresse beaucoup et j'aurai aimé qu'il soit bien plus mis en avant dans la réforme en cours.

Merci @pscoffoni pour la réponse ... et pour la spécification fonctionnelle à venir 😉 OK pour le lien avec Dolibarr. Je suggère que cette passerelle `proxy pac <--> dolibarr` soit un outil qui grossièrement: - se connecte à Dolibarr via API - se connecte au proxy pac via API - récupère les clients Dolibarr éligibles et mettre à jour le proxy - récupérera les stats d'utilisation du proxy pour la période de facturation en cours - pour chaque client identifié dans ces stats (par son SIREN): - crée une nouvelle facture dans Dolibarr si inexistante - attache à la facture les stats d'utilisation (niveau de détail à définir) - crée ou met-à-jour un ticket/page wiki dans dolibarr pour un rapport final C'est donc un outil *externe* qui va dialoguer avec les API Dolibarr et proxy. A voir en fonction des ressources, des technos ... et du calendrier Sur la base d'une première version des specs, je suggère de faire un POC en quelques jour pour voir si l'échéance de septembre est réaliste. Merci également pour les précisions sur la **signature électronique PDF**. C'est un sujet qui m'intéresse beaucoup et j'aurai aimé qu'il soit bien plus mis en avant dans la réforme en cours.

bruno.d2b commented

2026-03-24 08:45:57 +01:00

Member

Bonjour,

J'ai effectué quelques recherches sur la norme AFNOR (version février 2026).
Dans XP Z12-013, on décrit le cas d'un portail d'entreprise qui gère plusieurs PA et qui doit donner une vision consolidée notamment à sa comptabilité (voir schéma en PJ)

Est-ce que ce cas d'usage nous correspond ?

J'ai exploré le sujet et je vous joins le résultat (compilation de résultats de prompt).

Bonjour, J'ai effectué quelques recherches sur la norme AFNOR (version février 2026). Dans XP Z12-013, on décrit le cas d'un portail d'entreprise qui gère plusieurs PA et qui doit donner une vision consolidée notamment à sa comptabilité (voir schéma en PJ) Est-ce que ce cas d'usage nous correspond ? J'ai exploré le sujet et je vous joins le résultat (compilation de résultats de prompt).

extrait-norme-013-page-10.png

138 KiB

proxy-tiers.md

16 KiB

👍 1

bruno.d2b commented

2026-03-24 12:21:32 +01:00

Member

Je rebondis sur le message de @pscoffoni et de @philippe.entzmann plus haut que je n'avais pas compris complètement. Mais en le relisant après l'analyse de la norme, on veut que Dolibar ait un proxy pour ses clients hébergés. C'est le même cas d'usage que le Système Compatible pour un Organisme de Dématérialisation décrit dans la norme ?

philippe.entzmann commented

2026-03-24 14:22:28 +01:00

Author

Member

@bruno.d2b je ne saurai dire si ce que tu as trouvé couvre le besoin évoqué par @pscoffoni

A creuser.

Mais bravo pour la découverte ! (je suis preneur d'une démo de ton notebook 😉)

@bruno.d2b je ne saurai dire si ce que tu as trouvé couvre le besoin évoqué par @pscoffoni A creuser. Mais bravo pour la découverte ! (je suis preneur d'une démo de ton notebook 😉)

teddy.morel commented

2026-03-26 10:29:40 +01:00

Owner

Salut à tous
@philippe.entzmann , @pscoffoni , @bruno.d2b
Je suis encore bien pris cette semaine, et ne pourrais pas participer à la visio de ce midi, désolé.

Ce sujet est un des sujets à traiter en priorité à mon sens, il permet de montrer une avancée concrète et un positionnement de PDPLibre dans le cadre de cette réforme.

je vais lancé un sujet sur le forum pour tenter de trouver des renforts.
je vous propose de faire une visio (30m - 1h) dédié à ce sujet semaine prochaine. voici quelques propositions :

30/03/2026 entre 12h30 et 16h
31/03/2026 entre 17h et 18h
01/04/2026 entre 14h30 et 16h

j'attends vos retours pour lancer le sujet sur le forum et poser la date de la visio sur le sujet

Salut à tous @philippe.entzmann , @pscoffoni , @bruno.d2b Je suis encore bien pris cette semaine, et ne pourrais pas participer à la visio de ce midi, désolé. Ce sujet est un des sujets à traiter en priorité à mon sens, il permet de montrer une avancée concrète et un positionnement de PDPLibre dans le cadre de cette réforme. je vais lancé un sujet sur le forum pour tenter de trouver des renforts. je vous propose de faire une visio (30m - 1h) dédié à ce sujet semaine prochaine. voici quelques propositions : - 30/03/2026 entre 12h30 et 16h - 31/03/2026 entre 17h et 18h - 01/04/2026 entre 14h30 et 16h j'attends vos retours pour lancer le sujet sur le forum et poser la date de la visio sur le sujet

philippe.entzmann commented

2026-03-26 10:46:37 +01:00

Author

Member

Pour moi:

~~30/03/2026 entre 12h30 et 16h~~
31/03/2026 entre 17h et 18h
01/04/2026 entre 14h30 et 16h

Pour moi: - ~30/03/2026 entre 12h30 et 16h~ - 31/03/2026 entre 17h et 18h - 01/04/2026 entre 14h30 et 16h

pscoffoni commented

2026-03-26 12:28:13 +01:00

Owner

Ok 31/03/2026 entre 17h et 18h uniquement

bruno.d2b commented

2026-03-26 21:01:23 +01:00

Member

Ok également, 31/03/2026 entre 17h et 18h

Est-ce que la description du système décrit dans la norme XP Z12-013 et noté plus haut répond à la vision du proxy @pscoffoni ?

Ok également, 31/03/2026 entre 17h et 18h Est-ce que la description du système décrit dans la norme XP Z12-013 et noté plus haut répond à la vision du proxy @pscoffoni ?

pscoffoni commented

2026-03-26 21:08:28 +01:00

Owner

@bruno.d2b on va dire que oui :-)
EDIT 22h10 : j'avance sur mes spec mais là faut que je relise tout pour vérifier la cohérence... donc en début de semaine prochaine ou dans le week-end s'il ne fait pas beau :-)

@bruno.d2b on va dire que oui :-) EDIT 22h10 : j'avance sur mes spec mais là faut que je relise tout pour vérifier la cohérence... donc en début de semaine prochaine ou dans le week-end s'il ne fait pas beau :-)

👍 1

bruno.d2b commented

2026-03-26 22:15:28 +01:00

Member

Voici un premier jet du notebook que j'utilise sur les EPIC/US à traiter dans le proxy. A prendre comme tel.

Client = adhérant PDPLibre bénéficiant de la ou les PA partenaires
Système Compatible = proxy
Organisme de Dématérialisation = PDPLibre

Sortie du notebook :

EPIC 1 : Connectivité, Sécurité et Délégation (XP Z12-013)
Objectif : Garantir l'interopérabilité technique et le respect du mandat de tiers.

US 1.1 (Client) : En tant que Client, je souhaite m'authentifier auprès du Proxy pour déposer ou consulter mes factures en toute sécurité.
US 1.2 (Système Compatible) : En tant que Système Compatible, je souhaite gérer une connexion OAUTH2 unique avec chaque Plateforme Agréée (PA) en tant que Tiers référencé.
US 1.3 (Système Compatible) : En tant que Système Compatible, je souhaite injecter systématiquement la balise Organisation-Id (SIREN du client) dans le header HTTP de chaque appel vers la PA pour agir légitimement sur son périmètre.
US 1.4 (Système Compatible) : En tant que Système Compatible, je souhaite m'abonner aux Webhooks des PA pour relayer les notifications de nouveaux flux vers mes clients concernés.

EPIC 2 : Émission et Transmission des Flux (Flux 2 / Flux 10)
Objectif : Assurer le routage des factures de vente et du e-reporting.

US 2.1 (Client) : En tant que Client, je souhaite pousser mes factures de vente (UBL, CII ou Factur-X) vers le Proxy pour qu'elles atteignent ma PA-E.
US 2.2 (Système Compatible) : En tant que Système Compatible, je souhaite valider la recevabilité technique du flux (antivirus, XSD) avant de le transmettre à la PA via la route POST /flows.
US 2.3 (Système Compatible) : En tant que Système Compatible, je souhaite associer un trackingId à chaque envoi pour permettre au client de suivre sa facture dans son propre SI.
US 2.4 (Gestionnaire OD) : En tant que Gestionnaire OD, je souhaite que le Proxy trace chaque dépôt (type de flux, taille, SIREN émetteur) pour comptabiliser l'activité et facturer mon client.

EPIC 3 : Réception et Récupération des Factures (Flux 2)
Objectif : Gérer l'arrivée des factures d'achat et des documents lisibles.

US 3.1 (Système Compatible) : En tant que Système Compatible, je souhaite interroger périodiquement les PA (POST /flows/search) pour récupérer les factures d'achat reçues par mes clients.
US 3.2 (Client) : En tant que Client, je souhaite récupérer le fichier binaire d'une facture ou son lisible (PDF généré) depuis le Proxy pour traitement comptable.
US 3.3 (Gestionnaire OD) : En tant que Gestionnaire OD, je souhaite enregistrer le nombre de factures reçues par chaque client pour justifier les paiements collectés.

EPIC 4 : Suivi du Cycle de Vie et Statuts (Flux 6 - CDAR)
Objectif : Maîtriser la traçabilité métier et fiscale de bout en bout.

US 4.1 (Client) : En tant que Client, je souhaite émettre des statuts de traitement ("Refusée", "Approuvée", "Encaissée") via le Proxy pour informer mon partenaire et l'administration.
US 4.2 (Système Compatible) : En tant que Système Compatible, je souhaite traduire les actions du client en messages CDAR (Flux 6) conformes au socle minimal pour les transmettre à la PA.
US 4.3 (Client) : En tant que Client, je souhaite consulter l'historique des statuts d'une facture pour savoir si elle a été "Mise à disposition" ou "Rejetée" par la PA de réception.
US 4.4 (Gestionnaire OD) : En tant que Gestionnaire OD, je souhaite piloter les taux de rejets techniques pour améliorer la qualité de service fournie aux clients.

EPIC 5 : Annuaire et Adressage (Flux 11)
Objectif : Garantir l'acheminement des flux vers les bonnes destinations.

US 5.1 (Client) : En tant que Client, je souhaite vérifier l'existence et l'adresse électronique (SchemeID 0225) d'un destinataire avant de lui émettre une facture.
US 5.2 (Système Compatible) : En tant que Système Compatible, je souhaite router les demandes de recherche SIREN du client vers les API Annuaire des PA concernées.

EPIC 6 : Pilotage Financier et Consommation Groupée
Objectif : Assurer la rentabilité de l'organisme de dématérialisation.

US 6.1 (Gestionnaire OD) : En tant que Gestionnaire OD, je souhaite consolider mensuellement les volumes de flux (Ventes, Achats, CDAR, Reporting) par PA pour payer la consommation groupée à mes fournisseurs PA.
US 6.2 (Gestionnaire OD) : En tant que Gestionnaire OD, je souhaite éditer des rapports de consommation par client pour déclencher le recouvrement automatique de mes frais de service.

Voici un premier jet du notebook que j'utilise sur les EPIC/US à traiter dans le proxy. A prendre comme tel. - Client = adhérant PDPLibre bénéficiant de la ou les PA partenaires - Système Compatible = proxy - Organisme de Dématérialisation = PDPLibre Sortie du notebook : EPIC 1 : Connectivité, Sécurité et Délégation (XP Z12-013) Objectif : Garantir l'interopérabilité technique et le respect du mandat de tiers. US 1.1 (Client) : En tant que Client, je souhaite m'authentifier auprès du Proxy pour déposer ou consulter mes factures en toute sécurité. US 1.2 (Système Compatible) : En tant que Système Compatible, je souhaite gérer une connexion OAUTH2 unique avec chaque Plateforme Agréée (PA) en tant que Tiers référencé. US 1.3 (Système Compatible) : En tant que Système Compatible, je souhaite injecter systématiquement la balise Organisation-Id (SIREN du client) dans le header HTTP de chaque appel vers la PA pour agir légitimement sur son périmètre. US 1.4 (Système Compatible) : En tant que Système Compatible, je souhaite m'abonner aux Webhooks des PA pour relayer les notifications de nouveaux flux vers mes clients concernés. EPIC 2 : Émission et Transmission des Flux (Flux 2 / Flux 10) Objectif : Assurer le routage des factures de vente et du e-reporting. US 2.1 (Client) : En tant que Client, je souhaite pousser mes factures de vente (UBL, CII ou Factur-X) vers le Proxy pour qu'elles atteignent ma PA-E. US 2.2 (Système Compatible) : En tant que Système Compatible, je souhaite valider la recevabilité technique du flux (antivirus, XSD) avant de le transmettre à la PA via la route POST /flows. US 2.3 (Système Compatible) : En tant que Système Compatible, je souhaite associer un trackingId à chaque envoi pour permettre au client de suivre sa facture dans son propre SI. US 2.4 (Gestionnaire OD) : En tant que Gestionnaire OD, je souhaite que le Proxy trace chaque dépôt (type de flux, taille, SIREN émetteur) pour comptabiliser l'activité et facturer mon client. EPIC 3 : Réception et Récupération des Factures (Flux 2) Objectif : Gérer l'arrivée des factures d'achat et des documents lisibles. US 3.1 (Système Compatible) : En tant que Système Compatible, je souhaite interroger périodiquement les PA (POST /flows/search) pour récupérer les factures d'achat reçues par mes clients. US 3.2 (Client) : En tant que Client, je souhaite récupérer le fichier binaire d'une facture ou son lisible (PDF généré) depuis le Proxy pour traitement comptable. US 3.3 (Gestionnaire OD) : En tant que Gestionnaire OD, je souhaite enregistrer le nombre de factures reçues par chaque client pour justifier les paiements collectés. EPIC 4 : Suivi du Cycle de Vie et Statuts (Flux 6 - CDAR) Objectif : Maîtriser la traçabilité métier et fiscale de bout en bout. US 4.1 (Client) : En tant que Client, je souhaite émettre des statuts de traitement ("Refusée", "Approuvée", "Encaissée") via le Proxy pour informer mon partenaire et l'administration. US 4.2 (Système Compatible) : En tant que Système Compatible, je souhaite traduire les actions du client en messages CDAR (Flux 6) conformes au socle minimal pour les transmettre à la PA. US 4.3 (Client) : En tant que Client, je souhaite consulter l'historique des statuts d'une facture pour savoir si elle a été "Mise à disposition" ou "Rejetée" par la PA de réception. US 4.4 (Gestionnaire OD) : En tant que Gestionnaire OD, je souhaite piloter les taux de rejets techniques pour améliorer la qualité de service fournie aux clients. EPIC 5 : Annuaire et Adressage (Flux 11) Objectif : Garantir l'acheminement des flux vers les bonnes destinations. US 5.1 (Client) : En tant que Client, je souhaite vérifier l'existence et l'adresse électronique (SchemeID 0225) d'un destinataire avant de lui émettre une facture. US 5.2 (Système Compatible) : En tant que Système Compatible, je souhaite router les demandes de recherche SIREN du client vers les API Annuaire des PA concernées. EPIC 6 : Pilotage Financier et Consommation Groupée Objectif : Assurer la rentabilité de l'organisme de dématérialisation. US 6.1 (Gestionnaire OD) : En tant que Gestionnaire OD, je souhaite consolider mensuellement les volumes de flux (Ventes, Achats, CDAR, Reporting) par PA pour payer la consommation groupée à mes fournisseurs PA. US 6.2 (Gestionnaire OD) : En tant que Gestionnaire OD, je souhaite éditer des rapports de consommation par client pour déclencher le recouvrement automatique de mes frais de service.

👍 1

philippe.entzmann commented

2026-03-30 14:41:45 +02:00

Author

Member

Je crée une branche pour y placer les éléments de ce fil de discussion pour la réunion de demain

philippe.entzmann added reference 41_proxy

2026-03-30 14:51:22 +02:00

philippe.entzmann commented

2026-03-30 14:55:53 +02:00

Author

Member

Banche 41_proxy créée et associée à ce ticket. J'y ai mis les réflexions de fil dans la doc

Banche [41_proxy](https://git.pdplibre.org/Construction_PA/PA_Communautaire/src/branch/41_proxy) créée et associée à ce ticket. J'y ai mis les réflexions de fil dans [la doc](https://git.pdplibre.org/Construction_PA/PA_Communautaire/src/branch/41_proxy/docs/briques/11-proxy/index.md)

bruno.d2b commented

2026-03-31 09:01:43 +02:00

Member

J'ai fait tourner notebook et Claude pour réaliser une presentation pour la réunion de fin d'après-midi. A prendre comme pièce à casser, il y a certainement des points à corriger.

Si on l'utilise, il faudrait compléter la slide Pourquoi un ProxyPDPLibre ? ou le faire à l'oral.

@philippe.entzmann @teddy.morel @pscoffoni

J'ai fait tourner notebook et Claude pour réaliser une presentation pour la réunion de fin d'après-midi. A prendre comme pièce à casser, il y a certainement des points à corriger. Si on l'utilise, il faudrait compléter la slide Pourquoi un ProxyPDPLibre ? ou le faire à l'oral. @philippe.entzmann @teddy.morel @pscoffoni

ProxyPDPLibre-Atelier-1-V0-2.pptx

1.2 MiB

teddy.morel commented

2026-03-31 15:51:44 +02:00

Owner

@bruno.d2b que penses tu des infos du sujet ci dessous pour "pourquoi" :
https://forum.pdplibre.org/t/le-proxy-pdplibre-une-premiere-application-concrete-de-notre-pa-communautaire/987

L’idée est simple : dans le cadre du projet « Grossiste en Facturation » porté par l’association, nous souhaitons mutualiser les volumes de factures de nos adhérents pour bénéficier des meilleurs tarifs auprès des PA déjà immatriculées. Pour cela, nous avons besoin d’un composant technique qui se positionne comme intermédiaire (Tiers) entre nos adhérents et ces PA partenaires, conformément à la norme XP Z12-013.
Identifier les besoins d’une brique Back-Office (brique 11) — Pour savoir qui envoie quoi, il nous faut a minima une gestion des clients (ID client + adresse de facturation électronique) que l’on croisera avec les compteurs de flux du Cycle de Vie. Cette brique sera de toute façon indispensable pour la PA communautaire.

@bruno.d2b que penses tu des infos du sujet ci dessous pour "pourquoi" : https://forum.pdplibre.org/t/le-proxy-pdplibre-une-premiere-application-concrete-de-notre-pa-communautaire/987 L’idée est simple : dans le cadre du projet « Grossiste en Facturation » porté par l’association, nous souhaitons mutualiser les volumes de factures de nos adhérents pour bénéficier des meilleurs tarifs auprès des PA déjà immatriculées. Pour cela, nous avons besoin d’un composant technique qui se positionne comme intermédiaire (Tiers) entre nos adhérents et ces PA partenaires, conformément à la norme XP Z12-013. Identifier les besoins d’une brique Back-Office (brique 11) — Pour savoir qui envoie quoi, il nous faut a minima une gestion des clients (ID client + adresse de facturation électronique) que l’on croisera avec les compteurs de flux du Cycle de Vie. Cette brique sera de toute façon indispensable pour la PA communautaire.

bruno.d2b commented

2026-03-31 16:34:45 +02:00

Member

C'est très bien.
Et cela a déjà été partagé.
La discussion tournera autour de ces éléments.
Selon les échanges, on peut utiliser les slides mais ce n'est pas obligatoire pour

le proxy dans le cadre normatif
l'articulation avec les briques de l'architecture mais c'est très technique vous pouvez le faire autour du schéma et @philippe.entzmann saura le faire très bien
si on veut être concret en termes de fonctionnalités, il y a les EPIC/US mais formalisé pour les dev.

A tout de suite
@teddy.morel

C'est très bien. Et cela a déjà été partagé. La discussion tournera autour de ces éléments. Selon les échanges, on peut utiliser les slides mais ce n'est pas obligatoire pour - le proxy dans le cadre normatif - l'articulation avec les briques de l'architecture mais c'est très technique vous pouvez le faire autour du schéma et @philippe.entzmann saura le faire très bien - si on veut être concret en termes de fonctionnalités, il y a les EPIC/US mais formalisé pour les dev. A tout de suite @teddy.morel

bruno.d2b commented

2026-03-31 16:43:11 +02:00

Member

Pour complétude de la pres, slide mise à jour.
Après on pourra se servir de la pres en sélectionnant quelques slides pour diffusion ou pas.
@teddy.morel

Pour complétude de la pres, slide mise à jour. Après on pourra se servir de la pres en sélectionnant quelques slides pour diffusion ou pas. @teddy.morel

Pourquoi-proxyPDPLibre.png

250 KiB

philippe.entzmann commented

2026-03-31 18:44:59 +02:00

Author

Member

Shared note:

https://git.pdplibre.org/Construction_PA/PA_Communautaire/src/branch/13_boucle_metier/docs/briques/02-esb-central/persistence.md#sujets-streams-consumers

CR PoxyPDPLibre 20260331

1 token ESAlink PDPLibre unique ou un token ESAlink par client final ?

d'abord le mode mock / passe-plat et ensuite la gestion onborading

fonctionnement d'onboarding à creuser (onboardin PA et onboarding ProxyPDPLibre)

[ ] TMOREL -> mettre à jour le schema d'achitecture pour ajouter les briques 10 (stocage) et 11 (backoffice)

Quid de définir le taux de disponibilité du proxyPDPLibre vs SLA de la PA en face

scenario panne1 :

si l'api de la PA ne répond pas que fait on ? tampon ou pas ? A vérifier si l'api afnor est en synchrone et par conséquent le mode tampon ne pourrait pas être possible

schema politique conservation des messages : https://git.pdplibre.org/Construction_PA/PA_Communautaire/src/branch/13_boucle_metier/docs/briques/02-esb-central/persistence.md#sujets-streams-consumers

première version sans webhook en v1
pool d'appel pour proposer un webhook par client plus tard en v2

API AFNOR;
https://app.swaggerhub.com/apis/Generixgroup8/AFNOR-Flow_Service/1.2.0#/Flow/searchFlows

eslink un token par client

faire un slide vocabulaire

authentifier l'utilisateur (via JWT, SIREN) et si OK on transmets tel quelle la requête (non modifiée)

choix de la techno à planifier sur la conservation des messages

briques concernées :

01- api => ok
06- annuaire => "simple appel" 
07- routage => relai la requete
11- backoffice => gestion 
des clients  (api key + SIREN)

Epic 2 :
    US1: OK
    US2 et ES3 : KO
    US4 : au moment du report : si pas de reporting, c'est l'esb qui doit tracer. Stockage : A creuser
    
    Epic 3 :
        US1 : pas en V2, c'est le client qui doit interroger
            Initiative Client qui l'interrogation vers le proxy
            Le proxy fait le relai vers la PA
        US2 : passe par le proxy
        
    Epic 4 : Pas de traitement du proxy
    Mesurer la taille des pièces transmises pour traiter les problemes de facture en sus ou selon le seuil ou moyenne des tailles, règles par PA
    
    Epic 5 :
        US1 et US2 : OK
        Prévoir la base adhérents PDPLibre mais en interne
        
        Epic 6
        US : l'outil de facturation de l'association interroge le proxy
    
    API : On aura des API spécifiques et on renverra vers le PA

Shared note: https://git.pdplibre.org/Construction_PA/PA_Communautaire/src/branch/13_boucle_metier/docs/briques/02-esb-central/persistence.md#sujets-streams-consumers CR PoxyPDPLibre 20260331 1 token ESAlink PDPLibre unique ou un token ESAlink par client final ? d'abord le mode mock / passe-plat et ensuite la gestion onborading fonctionnement d'onboarding à creuser (onboardin PA et onboarding ProxyPDPLibre) [ ] TMOREL -> mettre à jour le schema d'achitecture pour ajouter les briques 10 (stocage) et 11 (backoffice) Quid de définir le taux de disponibilité du proxyPDPLibre vs SLA de la PA en face # scenario panne1 : si l'api de la PA ne répond pas que fait on ? tampon ou pas ? A vérifier si l'api afnor est en synchrone et par conséquent le mode tampon ne pourrait pas être possible # schema politique conservation des messages : https://git.pdplibre.org/Construction_PA/PA_Communautaire/src/branch/13_boucle_metier/docs/briques/02-esb-central/persistence.md#sujets-streams-consumers première version sans webhook en v1 pool d'appel pour proposer un webhook par client plus tard en v2 API AFNOR; https://app.swaggerhub.com/apis/Generixgroup8/AFNOR-Flow_Service/1.2.0#/Flow/searchFlows eslink un token par client faire un slide vocabulaire authentifier l'utilisateur (via JWT, SIREN) et si OK on transmets tel quelle la requête (non modifiée) choix de la techno à planifier sur la conservation des messages # briques concernées : 01- api => ok 06- annuaire => "simple appel" 07- routage => relai la requete 11- backoffice => gestion des clients (api key + SIREN) Epic 2 : US1: OK US2 et ES3 : KO US4 : au moment du report : si pas de reporting, c'est l'esb qui doit tracer. Stockage : A creuser Epic 3 : US1 : pas en V2, c'est le client qui doit interroger Initiative Client qui l'interrogation vers le proxy Le proxy fait le relai vers la PA US2 : passe par le proxy Epic 4 : Pas de traitement du proxy Mesurer la taille des pièces transmises pour traiter les problemes de facture en sus ou selon le seuil ou moyenne des tailles, règles par PA Epic 5 : US1 et US2 : OK Prévoir la base adhérents PDPLibre mais en interne Epic 6 US : l'outil de facturation de l'association interroge le proxy API : On aura des API spécifiques et on renverra vers le PA

philippe.entzmann commented

2026-04-01 15:04:36 +02:00

Author

Member

Première tentative de formulation des specs de la brique 11

à discuter demain

Première tentative de formulation des [specs de la brique 11](https://git.pdplibre.org/Construction_PA/PA_Communautaire/src/branch/41_proxy/docs/briques/11-proxy/index.md) à discuter demain

philippe.entzmann commented

2026-04-09 12:32:05 +02:00

Author

Member

Point d'avancement v0 : à discuter aujourd'hui

Point d'avancement v0 : [à discuter aujourd'hui](https://git.pdplibre.org/Construction_PA/PA_Communautaire/src/branch/41_proxy/docs/briques/11-backoffice/index.md) ![image](/attachments/e69db5e9-fd9d-4c60-aa44-e40205e5b9c4) ![image](/attachments/1e4afcbc-cf11-4bbf-8787-b188b945ae4d) ![image](/attachments/1e5725b5-1665-489f-855a-12624ddcca77)

image.png

71 KiB

image.png

16 KiB

image.png

269 KiB

Rows
Columns

[FEATURE]: proxy pa #41

Description

scenario panne1 :

schema politique conservation des messages : https://git.pdplibre.org/Construction_PA/PA_Communautaire/src/branch/13_boucle_metier/docs/briques/02-esb-central/persistence.md#sujets-streams-consumers

briques concernées :