Service public numérique 🇫🇷 qui a pour objectif de faciliter la coordination des échanges entre acteurs et de simplifier la lecture des parcours d’insertion.
ETQ gestionnaire de structure je peux récupérer les données saisies par mes accompagnateurs afin de les réintégrer dans mon système d'information pour éviter la double saisie #908
Aujourd'hui, le groupe VitamineT, demain Mairie de Paris.
Le groupe VitamineT 4 accompagnateurs, xxx bénéficiaires du RSA.
Urgence = VitamineT ont accepté de jouer le jeu de la saisie alors qu'ils ont déjà un outil. Si on ne leur facilite pas la vie, on devra consommer leur API. Cette demande provient de beaucoup de gestionnaire de structure. Être proactif, nous permettra de prendre la main et limitera la quantité de connecteurs à faire. Usagers > Partenaires (ici) > Sponsors > Equipe.
VitamineT très implanté dans les IAE (quart nord-est de la France).
🚀 Solution
On aimerait prendre le temps de mieux penser la solution (API, etc.) dans une future version.
Mais pour avancer et vérifier le besoin / l'usage, on propose de partir au plus simple, i.e. un export CSV ou un JSON.
Un format normé JSON peut convenir.
Dans le futur, le risque d'être un impératif (ils pourraient utiliser un service en ligne de conversion JSON to CSV ?).
En v0, on expose toutes les données.
Ça permet d'avoir du feedback et d'affiner éventuellement les données / requêtes dans le futur.
🛠 Détails techniques / opérationnels
Combien de champs exportés : .
Nombre de valeurs : 400.
On part d'un bénéficiaire et on regarde toutes les données qui lui sont rattachées et à son carnet :
référent(s) qui lui est rattaché
signature de contrat
etc.
C'est pas les gestionnaires de structure.
On élimine GraphQL pour le trop fort couplage, qui rendrait VitamineT trop dépendant de notre schéma.
On décide de faire côté back-end. Draft API JSON / modèles Pydantic.
Dans cette US, on se base sur les modèles de données déjà réalisés pour Pôle Emploi. L'export de toutes les données et donc la réalisation des autres modèles Pydantic sera faite dans une autre US.
✅ Pour tester
en tant que développeur, je peux exporter via un terminal les données dans un fichier JSON
la nature de l'output est un fichier JSON
je ne vois que les données des BRSA de mes accompagnateurs #sécurité
lkouad
commented
2 years ago
🍣 Contexte / problème
Aujourd'hui, le groupe VitamineT, demain Mairie de Paris.
Le groupe VitamineT 4 accompagnateurs, xxx bénéficiaires du RSA.
Urgence = VitamineT ont accepté de jouer le jeu de la saisie alors qu'ils ont déjà un outil. Si on ne leur facilite pas la vie, on devra consommer leur API. Cette demande provient de beaucoup de gestionnaire de structure. Être proactif, nous permettra de prendre la main et limitera la quantité de connecteurs à faire. Usagers > Partenaires (ici) > Sponsors > Equipe.
VitamineT très implanté dans les IAE (quart nord-est de la France).
🚀 Solution
On aimerait prendre le temps de mieux penser la solution (API, etc.) dans une future version. Mais pour avancer et vérifier le besoin / l'usage, on propose de partir au plus simple, i.e. un export CSV ou un JSON. Un format normé JSON peut convenir. Dans le futur, le risque d'être un impératif (ils pourraient utiliser un service en ligne de conversion JSON to CSV ?).
En v0, on expose toutes les données. Ça permet d'avoir du feedback et d'affiner éventuellement les données / requêtes dans le futur.
🛠 Détails techniques / opérationnels
Combien de champs exportés : . Nombre de valeurs : 400.
On part d'un bénéficiaire et on regarde toutes les données qui lui sont rattachées et à son carnet :
C'est pas les gestionnaires de structure.
On élimine GraphQL pour le trop fort couplage, qui rendrait VitamineT trop dépendant de notre schéma. On décide de faire côté back-end. Draft API JSON / modèles Pydantic.
Dans cette US, on se base sur les modèles de données déjà réalisés pour Pôle Emploi. L'export de toutes les données et donc la réalisation des autres modèles Pydantic sera faite dans une autre US.
✅ Pour tester
Partie 1 : format de sortie #931