35_Documentation_Onboarding #39

Merged
teddy.morel merged 10 commits from 35_Documentation_Onboarding into main 2026-03-17 20:57:52 +01:00
Member
Q A
Branche? 35_Documentation_Onboarding
Correction? non
Nouvelle feature? oui
Ticket Fix #35
Licence GPL-3.0-or-later

Description

Ajout du parcours d'onboarding pour les nouveaux contributeurs du projet PA Communautaire. Deux profils sont
adressés :

  • DEV : développeur avec compétences techniques générales, objectif d'autonomie sur le poste
  • METIER : expert facturation électronique, objectif de rédaction de tests BDD par brique

Le parcours est structuré en 12 blocs avec un tronc commun (blocs 1-5), une bifurcation par profil (DEV: 7-9,
METIER: 6+12) et une finalisation commune (10-11).

Fichiers

  • docs/00_onboarding/scenario.md : parcours en 12 blocs pour profils DEV et METIER
  • docs/00_onboarding/onboarding.pptx : présentation 40 slides basée sur le template
  • docs/00_onboarding/architecture_PA.md : schéma mermaid de l'architecture
  • docs/00_onboarding/Architecture_Plateforme_Factures_Electroniques_v03.png : schéma archi
| Q | A | ------------- | --- | Branche? | 35_Documentation_Onboarding | Correction? | non | Nouvelle feature? | oui | Ticket | Fix #35 | Licence | GPL-3.0-or-later ### Description Ajout du parcours d'onboarding pour les nouveaux contributeurs du projet PA Communautaire. Deux profils sont adressés : - **DEV** : développeur avec compétences techniques générales, objectif d'autonomie sur le poste - **METIER** : expert facturation électronique, objectif de rédaction de tests BDD par brique Le parcours est structuré en 12 blocs avec un tronc commun (blocs 1-5), une bifurcation par profil (DEV: 7-9, METIER: 6+12) et une finalisation commune (10-11). ### Fichiers - `docs/00_onboarding/scenario.md` : parcours en 12 blocs pour profils DEV et METIER - `docs/00_onboarding/onboarding.pptx` : présentation 40 slides basée sur le template - `docs/00_onboarding/architecture_PA.md` : schéma mermaid de l'architecture - `docs/00_onboarding/Architecture_Plateforme_Factures_Electroniques_v03.png` : schéma archi
- scenario.md : parcours en 12 blocs pour profils DEV et METIER
- onboarding.pptx : presentation 40 slides basee sur le template
- architecture_PA.md : schema mermaid de l architecture
- Architecture_Plateforme_Factures_Electroniques_v03.png : schema archi
bruno.d2b changed title from WIP: Documentation onboarding contributeur to WIP: 35_Documentation_Onboarding 2026-02-12 18:21:03 +01:00
Member

@bruno.d2b
Est ce que certaines parties que tu a rédigées ne font pas doublons avec certaines doc existante ?

Par exemple Contribuer et Architecture

Comment veux tu procéder ?

@bruno.d2b Est ce que certaines parties que tu a rédigées ne font pas doublons avec certaines doc existante ? Par exemple [Contribuer](https://git.pdplibre.org/Construction_PA/PA_Communautaire/src/branch/main/docs/developpement/Contribuer.md) et [Architecture](https://git.pdplibre.org/Construction_PA/PA_Communautaire/src/branch/main/docs/developpement/Architecture.md) Comment veux tu procéder ?

@bruno.d2b , ta présentation était vraiment bien !

@f.piccinali , difficile d'avoir une doc suffisamment complète et sans trop de recouvrement. Il y a du travail de ce côté

@bruno.d2b , ta présentation était vraiment bien ! @f.piccinali , difficile d'avoir une doc suffisamment complète et sans *trop* de recouvrement. Il y a du travail de ce côté
Author
Member

Oui l'objectif était d'avoir un doc autoporteur, je me suis fait aidé par l'IA ce qui l'a rendu verbeux. J'ai simplifié et complété hier.
@f.piccinali : en fait c'est redondant avec les docs par principe car c'est pour une vue de départ qui contient les index vers les docs. Mais ce sont les docs qui prennent la suite.
@philippe.entzmann : merci
Je refais une passe et passe la pres en PDF avant de merger.

Oui l'objectif était d'avoir un doc autoporteur, je me suis fait aidé par l'IA ce qui l'a rendu verbeux. J'ai simplifié et complété hier. @f.piccinali : en fait c'est redondant avec les docs par principe car c'est pour une vue de départ qui contient les index vers les docs. Mais ce sont les docs qui prennent la suite. @philippe.entzmann : merci Je refais une passe et passe la pres en PDF avant de merger.
Author
Member
  • Mise en avant des liens vers la doc du repo
  • Ajout de deux paragraphes sur les valeurs du projet pour faire echo aux remarques lors de la présentation dans la slide du projet
Ce projet open source est porté par des bénévoles avec comme objectif d’accompagnement pour les contributeurs, l’acquisition de compétences dans la facturation électronique

L’objectif cible est produire tout ou partie du code d’une Plateforme Agrée candidat à être exploité par l’association PDF Libre ou toute entité qui le déciderait
  • Remplacement du ppt par une version PDF dans l'optique d'une publication sur le main et github.
  • J'enleve le tag WIP de la PR
- Mise en avant des liens vers la doc du repo - Ajout de deux paragraphes sur les valeurs du projet pour faire echo aux remarques lors de la présentation dans la slide du projet ``` Ce projet open source est porté par des bénévoles avec comme objectif d’accompagnement pour les contributeurs, l’acquisition de compétences dans la facturation électronique L’objectif cible est produire tout ou partie du code d’une Plateforme Agrée candidat à être exploité par l’association PDF Libre ou toute entité qui le déciderait ``` - Remplacement du ppt par une version PDF dans l'optique d'une publication sur le main et github. - J'enleve le tag WIP de la PR
bruno.d2b changed title from WIP: 35_Documentation_Onboarding to 35_Documentation_Onboarding 2026-02-18 07:32:36 +01:00
Owner

yes bravo encore à vous 2 @bruno.d2b et @philippe.entzmann !

@bruno.d2b , je vais prendre le temps de relire tout ça demain et de regarder les PR.
en attendant est ce que tu peux corriger la coquille stp : "à être exploité par l’association PDF Libre"

yes bravo encore à vous 2 @bruno.d2b et @philippe.entzmann ! @bruno.d2b , je vais prendre le temps de relire tout ça demain et de regarder les PR. en attendant est ce que tu peux corriger la coquille stp : "à être exploité par l’association **PDF** Libre"
teddy.morel changed title from 35_Documentation_Onboarding to WIP: 35_Documentation_Onboarding 2026-02-19 23:12:32 +01:00
Owner

@bruno.d2b , je ne peux pas modifié le pdf. je propose de conserver le fichier source (pptx) dans le dépot pour pouvoir le modifier si besoin ou partire sur du full text. on pourrait remplacer le pptx par un https://sli.dev/ ou https://marp.app/

@bruno.d2b , je ne peux pas modifié le pdf. je propose de conserver le fichier source (pptx) dans le dépot pour pouvoir le modifier si besoin ou partire sur du full text. on pourrait remplacer le pptx par un https://sli.dev/ ou https://marp.app/
Author
Member

@teddy.morel J'ai rajouté le pptx.

Pour la coquille, j'ai voulu dire que c'était le code qui était exploité. Peut être que "utilisé" au lieu d'exploité aurait mieux convenu. Car derrière, il y avait la possibilité que le code de notre projet ne suffise pas à faire une PA en totalité.

Pour les slides, très bonne idée j'avais commencé en Markdown via le fichier scenario.md mais il est plus synchro avec le ppt tout en étant dans le repo.

Tu peux revoir le ppt et je le convertirai avec sli.dev que je ne connaissais pas.

@teddy.morel J'ai rajouté le pptx. Pour la coquille, j'ai voulu dire que c'était le code qui était exploité. Peut être que "utilisé" au lieu d'exploité aurait mieux convenu. Car derrière, il y avait la possibilité que le code de notre projet ne suffise pas à faire une PA en totalité. Pour les slides, très bonne idée j'avais commencé en Markdown via le fichier scenario.md mais il est plus synchro avec le ppt tout en étant dans le repo. Tu peux revoir le ppt et je le convertirai avec sli.dev que je ne connaissais pas.

@teddy.morel wrote in #39 (comment):

@bruno.d2b , je ne peux pas modifié le pdf. je propose de conserver le fichier source (pptx) dans le dépot pour pouvoir le modifier si besoin ou partire sur du full text. on pourrait remplacer le pptx par un https://sli.dev/ ou https://marp.app/

+1 pour https://sli.dev/

ou au format .odp libreoffice

@teddy.morel wrote in https://git.pdplibre.org/Construction_PA/PA_Communautaire/pulls/39#issuecomment-381: > @bruno.d2b , je ne peux pas modifié le pdf. je propose de conserver le fichier source (pptx) dans le dépot pour pouvoir le modifier si besoin ou partire sur du full text. on pourrait remplacer le pptx par un https://sli.dev/ ou https://marp.app/ +1 pour https://sli.dev/ ou au format `.odp` libreoffice
Owner

Salut @bruno.d2b ,
la coquille était sur le PDF au lieu de PDP 😄
le terme exploiter me va très bien.

j'ai modifié le pptx, je te laisse avancer sur la conversion avec sli.dev

Salut @bruno.d2b , la coquille était sur le PDF au lieu de PDP 😄 le terme exploiter me va très bien. j'ai modifié le pptx, je te laisse avancer sur la conversion avec sli.dev
Author
Member

J'ai traduit le PPT en version md standard puis en slidev.
slidev demande soit une install en local comme composant node soit l'utilisation d'un serveur distant. Cela me parait surdimensionné pour une seule presentation.
Voir si on garde uniquement : le texte md standard avec les 3 images.

J'ai traduit le PPT en version md standard puis en slidev. slidev demande soit une install en local comme composant node soit l'utilisation d'un serveur distant. Cela me parait surdimensionné pour une seule presentation. Voir si on garde uniquement : le texte md standard avec les 3 images.
bruno.d2b changed title from WIP: 35_Documentation_Onboarding to 35_Documentation_Onboarding 2026-03-05 13:02:25 +01:00
Member

J'ai quelques questions en lisant la documentation.

  1. Je vois très bien le cycle de vie d'envoi des factures depuis le logiciel de facturation vers les clients en tant que fournisseur, mais je ne trouve nulle part où ni comment je vais recevoir/aller chercher les factures qui m'ont été envoyées en tant que client, pour qu'elles finissent dans mon logiciel de facturation. Je comprends bien que la PA va recevoir les factures une fois l'entreprise répertoriée dans l'annuaire, mais je ne retrouve ni le traitement et/ou le stockage, ni l'API pour aller les chercher, ni le service pour les envoyer vers le logiciel de facturation. De plus, la première obligation à partir de septembre est d'avoir la capacité de recevoir les factures. Est-ce que l'interface du cycle de vie de la facture permet également de la récupérer, ce qui résoudrait la question ? Ou ai-je raté quelque chose ?
  2. Il semble y avoir une incohérence dans la documentation concernant la version de Python. Le README Docker indique que l'infrastructure est basée sur python3.12-bookworm-slim, tandis que le README d'onboarding mentionne Python 3.13+. Quelle est la version de référence à utiliser ?

Si non, le docker compose se lance très bien, en attendant de test uv et lancer les services de manière individuel.

J'ai quelques questions en lisant la documentation. 1. Je vois très bien le cycle de vie d'envoi des factures depuis le logiciel de facturation vers les clients en tant que fournisseur, mais je ne trouve nulle part où ni comment je vais recevoir/aller chercher les factures qui m'ont été envoyées en tant que client, pour qu'elles finissent dans mon logiciel de facturation. Je comprends bien que la PA va recevoir les factures une fois l'entreprise répertoriée dans l'annuaire, mais je ne retrouve ni le traitement et/ou le stockage, ni l'API pour aller les chercher, ni le service pour les envoyer vers le logiciel de facturation. De plus, la première obligation à partir de septembre est d'avoir la capacité de recevoir les factures. Est-ce que l'interface du cycle de vie de la facture permet également de la récupérer, ce qui résoudrait la question ? Ou ai-je raté quelque chose ? 2. Il semble y avoir une incohérence dans la documentation concernant la version de Python. Le README Docker indique que l'infrastructure est basée sur python3.12-bookworm-slim, tandis que le README d'onboarding mentionne Python 3.13+. Quelle est la version de référence à utiliser ? Si non, le docker compose se lance très bien, en attendant de test uv et lancer les services de manière individuel.
Author
Member

@hisie : bien vu sur la version. J'ai modifié. Prendre la version des docker file donc 3.12.

Pour la question de fond, je ne suis pas le plus savant sur le sujet mais c'est au logiciel front de mettre à disposition les factures reçues pour lui. C'est hors champ de la norme et donc à chaque PA de voir comment elle fait : intégration dans le logiciel qui utilise ses services ou présentation dans le composant portail de la PA si elle a décidé de proposer ce service...

@hisie : bien vu sur la version. J'ai modifié. Prendre la version des docker file donc 3.12. Pour la question de fond, je ne suis pas le plus savant sur le sujet mais c'est au logiciel front de mettre à disposition les factures reçues pour lui. C'est hors champ de la norme et donc à chaque PA de voir comment elle fait : intégration dans le logiciel qui utilise ses services ou présentation dans le composant portail de la PA si elle a décidé de proposer ce service...
Owner

Bonjour @hisie je ne suis pas sur que cette issue soit le bon endroit pour répondre à la question de la réception des factures fournisseurs. Je mets ma réponse ici cependant.

La réception des factures passe par votre PA (Plateforme Agréée), qui joue le rôle de PA-R (plateforme de réception).
Le mécanisme est le suivant :

  1. Vous inscrivez votre entreprise dans l'annuaire PPF avec une adresse électronique (ex: SIREN_SUFFIXE) et vous désignez votre PA-R
  2. Quand un fournisseur vous envoie une facture, sa plateforme consulte l'annuaire, trouve votre PA-R, et lui transmet la facture
  3. Votre PA-R la valide et la met à votre disposition
  4. Votre logiciel de facturation va chercher les factures en attente via l'API normalisée (AFNOR Flow Service) — typiquement un job automatique toutes les heures qui appelle POST /flows/search puis GET /flows/{flowId} pour récupérer le document

Références : XP Z12-013 (norme AFNOR) — définit l'API Flow Service (envoi ET réception) et l'API Directory Service (annuaire)

Attention cette API n'est pas obligatoire. il faut voir PA par PA. En son absence ce sont donc des API spécifique à la PA qui est proposée ou pas d'API....

Bonjour @hisie je ne suis pas sur que cette issue soit le bon endroit pour répondre à la question de la réception des factures fournisseurs. Je mets ma réponse ici cependant. La réception des factures passe par votre PA (Plateforme Agréée), qui joue le rôle de PA-R (plateforme de réception). Le mécanisme est le suivant : 1. Vous inscrivez votre entreprise dans l'annuaire PPF avec une adresse électronique (ex: SIREN_SUFFIXE) et vous désignez votre PA-R 2. Quand un fournisseur vous envoie une facture, sa plateforme consulte l'annuaire, trouve votre PA-R, et lui transmet la facture 3. Votre PA-R la valide et la met à votre disposition 4. Votre logiciel de facturation va chercher les factures en attente via l'API normalisée (AFNOR Flow Service) — typiquement un job automatique toutes les heures qui appelle POST /flows/search puis GET /flows/{flowId} pour récupérer le document Références : XP Z12-013 (norme AFNOR) — définit l'API Flow Service (envoi ET réception) et l'API Directory Service (annuaire) Attention cette API n'est pas obligatoire. il faut voir PA par PA. En son absence ce sont donc des API spécifique à la PA qui est proposée ou pas d'API....
teddy.morel left a comment

ok pour moi

ok pour moi
Owner

@f.piccinali est ce qu'on ajoute dans le document Contribuer.md le template ou de format structuré (titre, body, checklist) pour créer une PR ?

@f.piccinali est ce qu'on ajoute dans le document Contribuer.md le template ou de format structuré (titre, body, checklist) pour créer une PR ?
Sign in to join this conversation.
No description provided.