Services : Import des données data·inclusion et DORA

[rsebille]

🤔 Pourquoi ?

https://www.notion.so/gip-inclusion/Import-des-services-et-structures-d-i-DORA-31a5f321b60480a4a74bdded378b87af?v=28e5f321b604809f9e2e000cb57fc84b&source=copy_link

PR qui dépendent de celle-ci :

• Insertion : Ajout d'une page de visualisation d'une structure d'insertion #7838
• Insertion : Ajouter la fiche service #7810

L'app a été nommée insertion pour coller à la racine URL choisie, le nom pourrais créer une ambiguïté un jour (l'insertion c'est large) mais faute de mieux on est partis sur ça, surtout que le futur de l'intégration des fonctionnalités DORA dans les emplois est incertain donc faisons simple.

🏝️ Comment tester ?

1. Configurer les variables d'env pour les emplois :

   export DORA_API_BASE_URL="https://api.staging.dora.inclusion.gouv.fr"
   export DORA_API_TOKEN="IT.S-A-SECRET"

2. Avoir configurer API_DATA_INCLUSION_TOKEN avec token de prod d·i (sinon modifier API_DATA_INCLUSION_BASE_URL)
3. Lancer le script d'import

   ❯ ./manage.py import_structures_and_services --help

[dmc1985]

je continue à lire mais voici quelques commentaires pour débuter

[rsebille]

Petite passe rapide suite à tes retours, je rajoute les tests et corrige ce que je vais avoir cassé demain ! 😁

[dmc1985]

@rsebille même avec tes modifs pour que l'import marche sans Dora, j'ai toujours le même souci quand je lance la commande avec --data {references,structures,services} dans le conteneur clevercloud. Au moment qu'on arrive à

{"message": "HTTP Request: GET https://api.data.inclusion.gouv.fr/api/v1/structures?page=9&size=5000 \"HTTP/1.1 200 OK\"", "logger.name": "httpx", "logger.thread_name": "MainThread", "logger.method_name": "_send_single_request", "date": "2026-04-08T16:18:55.335190+00:00", "status": "INFO", "command.run_uid": "a00d9aea-9d60-4c44-8329-9b50438f6954", "command.name": "itou.dora.management.commands.import_structures_and_services", "command.wet_run": false}

l'import s'arrête sans aucun message d'erreur et ça reste comme ça jusqu'il y a un timeout.

[rsebille]

grmbl, j'avais pas validé mes réponses avant les congés... 🤦

[dmc1985]

je ne vois pas une façon pour trouver le slug Dora d'un service dont la valeur de is_orientable_with_form égal true. ma compréhension est que les services qui sont is_orientable_with_form == True vont permettre la redirection vers la page d'orientation dans Dora. Donc si la source n'est pas Dora, je vois pas comment faire ce lien.

[rsebille]

je ne vois pas une façon pour trouver le slug Dora d'un service dont la valeur de is_orientable_with_form égal true. ma compréhension est que les services qui sont is_orientable_with_form == True vont permettre la redirection vers la page d'orientation dans Dora. Donc si la source n'est pas Dora, je vois pas comment faire ce lien.

Je ne suis pas sûr de comprendre, actuellement la logique de création d'URL vers DORA est dans le templatetag dora_service_url de itou/utils/templatetags/dora.py, celui-ci étant fortement modifié dans #7523 afin de prendre en compte le paramètre op.
Est-ce que c'est à ça que tu faisais références ou rien à voir ?

[dmc1985]

je ne vois pas une façon pour trouver le slug Dora d'un service dont la valeur de is_orientable_with_form égal true. ma compréhension est que les services qui sont is_orientable_with_form == True vont permettre la redirection vers la page d'orientation dans Dora. Donc si la source n'est pas Dora, je vois pas comment faire ce lien.

Je ne suis pas sûr de comprendre, actuellement la logique de création d'URL vers DORA est dans le templatetag dora_service_url de itou/utils/templatetags/dora.py, celui-ci étant fortement modifié dans #7523 afin de prendre en compte le paramètre op. Est-ce que c'est à ça que tu faisais références ou rien à voir ?

je ne vois pas une façon pour trouver le slug Dora d'un service dont la valeur de is_orientable_with_form égal true. ma compréhension est que les services qui sont is_orientable_with_form == True vont permettre la redirection vers la page d'orientation dans Dora. Donc si la source n'est pas Dora, je vois pas comment faire ce lien.

Je ne suis pas sûr de comprendre, actuellement la logique de création d'URL vers DORA est dans le templatetag dora_service_url de itou/utils/templatetags/dora.py, celui-ci étant fortement modifié dans #7523 afin de prendre en compte le paramètre op. Est-ce que c'est à ça que tu faisais références ou rien à voir ?

oui c'est ça, merci de me l'avoir fait remarquer. pour la fiche service, j'aurai besoin du lien vers la page d'orientation qui est très semblable sauf qu'il y a un ajout de /orientation/. il faudrait que j'ajoute un nouveau tag ou c'est possible de parametriser les tags ?

[rsebille]

oui c'est ça, merci de me l'avoir fait remarquer. pour la fiche service, j'aurai besoin du lien vers la page d'orientation qui est très semblable sauf qu'il y a un ajout de /orientation/. il faudrait que j'ajoute un nouveau tag ou c'est possible de parametriser les tags ?

Parfait que ça soit ça :).
On peux paramétriser le templatetag (c'est déjà un peu ce qu'on fait fait actuellement et dans la PR op), mais je dirais de plutôt faire un nouveau tag (dora_service_orientation_url ?) et de mettre en commun ce qui peux être mis en commun entre les deux templatetags dans une fonction purement python dans le module :

• Il y a de forte chance qu'on ne veuille pas le même mtm_kwd.
• Ça se rapproche plus de la gestion classique des URL Django (url("dora:service"), url("dora:service_orientation")) et donc devrais simplifier les remplacements quand les URL seront dans les emplois aussi.
• Ça permet d'identifier plus facilement (car visible en début de ligne) vers quoi on veux diriger plutôt que de "cacher" ça via un paramètre.

[vperron]

@ggounot ou @dmc1985 je veux bien une relecture rapide à deux pour voir si on se dit qu'on tente un premier jet de cette PR ou pas. C'est extrêmement long à lire dans les détails, j'ai envie qu'on se jette à l'eau et qu'on teste ?

[ggounot]

@ggounot ou @dmc1985 je veux bien une relecture rapide à deux pour voir si on se dit qu'on tente un premier jet de cette PR ou pas. C'est extrêmement long à lire dans les détails, j'ai envie qu'on se jette à l'eau et qu'on teste ?

@vperron Bien sûr, on peut faire ça ensemble.

[vperron]

Screenshots de l'admin

[xavfernandez]

Cela me semble bien (modulo ma non-connaissance des modèles de données DORA/DI évidemment 😅 )

[vperron]

Le souci avec le fichier parquet est que on ne l'a pas "encore" côté DI.
On a un fichier parquet entre la datawarehouse et l'API data⋅inclusion.
Ce fichier contient des données potentiellement sensibles (personnelles de contact, données soliguide non exposables, etc) et est "brut", il passe une seconde passe de validation coté API data⋅inclusion au moment de son import et interprète des colonnes pour en sortir le schéma final validé.

Il faudrait prioriser un chantier côté data⋅inclusion qui serait de proposer un export parquet complet de l'API, incluant Soliguide par exemple, pour le cas spécifique des Emplois. Or actuellement l'API a le mérite d'exister et d'etre déjà assez lourdement utilisée; elle permet de filtrer des données par token, et propose des choses avancées (comme ne pas sélectionner les données des Emplois par exemple)

Mais elle a ses limitations: sa lourdeur et l'offset pagination par exemple. Bref, on s'est dit que ça pourrait commencer comme ça et le jour où l'on priorise des exports parquet (qui doivent donc etre sectorisés en accès à soliguide ou non a minima, sans oublier les coordonnées perso & autres petits aspects juridiques) ou la CursorPagination, on y passera.