Organisme qui remonte sans adresse

[FlavieSauvebois]

Le SIRET 88977538300017 arrive dans le référentiel sans adresse alors qu’il a bien une adresse sur la base INSEE (5 Horizon Pinel, 97150 Saint Martin). Est-ce que le problème est aussi lié au passage des adresses dans la BAN ?

Cela pose problème car comme cet OF n’est relié à aucune académie ou région, on ne peut pas utiliser de lien magique pour l’expertiser et seule une intervention en dur dans le code peut résoudre le problème.

Il faudrait donc saisir l'UAI en dur dans le code pour ce SIRET. Voici l'UAI : 9711303P

[gasilber]

Oui, le problème d'adresse est lié à l'impossibilité de géolocaliser cette dernière dans la BAN:

> coll.findOne({"siret":"88977538300017"})
{
    "_id" : ObjectId("61bcd44d92e138e87efe8cdb"),
    "siret" : "88977538300017",
    "_meta" : {
        "anomalies" : [
            {
                "key" : "adresse_5 HORIZON PINEL 97150 SAINT MARTIN",
                "type" : "etablissement_geoloc_impossible",
                "details" : "Pas de résultats pour l'adresse 5 HORIZON PINEL 97150 SAINT MARTIN",
...

Par contre, je ne sais pas trop quel mécanisme utiliser pour fixer en dur le code UAI 9711303P pour cet organisme, je ne vois pas dans le code de procédure permettant de faire ça.

[FlavieSauvebois]

Proposition de Georges-André

Pour #117: je peux éventuellement bricoler une insertion en base “forcée”, imitant une intervention humaine via l’interface utilisateur, mais ce n’est pas super propre et cela disparaitra si on reconstruit une base “from scratch”. Cela repose la question de l’utilisation de la BAN: fondamentalement je ne vois pas pourquoi on n’utilise pas juste les codes postaux / insee qui sont dans toutes les adresses pour définir la région et l’académie. La base INSEE me paraît être "une source de vérité” (même si elle se trompe), donc je ne vois pas pourquoi on repasse derrière…

Réponse Flavie : Pour l'issue 117 : nous avons besoin de rapprocher ce SIRET et cet UAI au sein du référentiel mais également pour les différents consommateurs. Si tu peux donc forcer l'insertion de cet UAI pour résoudre temporairement le pb, ca serait parfait.

Concernant la BAN il faut effectivement que l'on se requestionne sur son utilité. Si la base INSEE nous permet également de ventiler les OF par académies alors on pourrait certainement s'en passer. Il faut que l'on fasse des tests pour s'assurer que sa suppression n'a pas d'autres effets de bord. => Est-ce que l'on peut prévoir ce test à mon retour ? C'est possible dans la configuration actuelle de l'application ? Ou alors voir avec l'autre solution que tu proposais : "stocker l'adresse originale dans un nouvel attribut adresse_originale et afficher ce champ dans l'interface utilisateur" - issue 104

[gasilber]

Création d'une nouvelle commande permettant de faire une modification en ligne de commande:

yarn cli modify 88977538300017 9711303P

Résultat:

test> use referentiel
switched to db referentiel
referentiel> mods = db.modifications
referentiel.modifications
referentiel> mods.findOne({siret:"88977538300017"})
{
  _id: ObjectId("645373c58025f93f1856da39"),
  siret: '88977538300017',
  date: ISODate("2023-05-04T08:58:45.306Z"),
  auteur: 'commandline',
  changements: { uai: '9711303P' },
  original: {}
}

Faire suivre avec:

yarn cli consolidate --siret 88977538300017

[gasilber]

Appliqué en production: https://referentiel.apprentissage.onisep.fr/organismes/88977538300017