---
title: Unité enquêtée, lot et interrogation
---

# L'unité enquêtée (UE)

## Le concept
L'unité enquêtée est le concept qui représente l'unité qui fait l'objet d'une enquête.
Selon les cas, elle peut-être de nature :
* logement : où en général seront interrogés tous les personnes résidant le logement à la date de l'interrogation statistique;
* ex: dans l'ENL, un logement à une adresse donnée.
* individu : une personne interrogée,
* soit directement (une personne individu échantillonné depuis une base de sondage),
* ex: dans ???, l'individu Bob l'éponge.
* soit après un premier échange, du type "tirage kish", où de premières questions permettent d'identifier les personnes résidant à l'adresse visitée/contactée et un tirage aléatoire permet de sélectionner l'individu effectivement enquêté.
* ex: dans l'enquête TIC, l'individu John Doe (non déterminé avant la collecte) résidant à l'adresse donnée et dont l'identité sera déterminée après tirage kish.
* business : avec toutes les natures "d'entreprise", type établissement (=SIRET), entreprise (=SIREN), groupe (=plusieurs SIREN ?), etc.
* ex: l'entreprise Renaut, Apple, un établissement administratif, etc.

Une même unité enquêtée peut être interrogée plusieurs fois dans différentes opérations de collecte. On rattache donc à l'objet Unité Enquêtée toutes les propriétés que l'on souhaite partager entre les différentes opérations de collecte.

## La modélisation REM

* SurveyUnit : L'objet unité enquêtée avec les identifiants et/ou noms mobilisés dans les outils (des identifiants/noms métier, personnalisés pour l'affichage ou le post-collecte)
* ContactData : mail et numéro de téléphone d'une personne contact.

classDiagram
        
    class SurveyUnit {
    identifitants et noms métier
    adresse de l'UE
    } 
    
    class Contact {
    mail
    tel
    } 
    
    Contact "1..*" -- "1" SurveyUnit 
     
    

## Les "personnes contact"

Au niveau de REM ne sont gérées que les informations de contact d'une UE. C'est-à-dire, les éléments permettant d'entrer en contact avec une UE, que cela soit par le biais d'une communication (mail ou courrier) ou par le biais d'un enquêteur (mail ou numéro de téléphone).
La composition du ménage et les personnes devant être interrogées individuellement sont des "données questionnaire", c'est-à-dire qu'elles sont vues comme des réponses aux questions d'un questionnaire et relève des données collectées, non gérées dans REM.

Il persiste l'usage des fiche-adresse papier, qui nécessitent une description détaillée du ménage pour être correctement produites.
Ainsi, la description d'un ménage peut être fournie par la base de sondage et utilisée pour l'impression de fiche-adresse papier (comme pour la personnalisation d'un questionnaire, avec, par exemple, les prénoms des personnes à interroger), mais elles sont dès lors considérées comme des données externes, stockées comme telles, et ne sont pas mises à jour dans REM par des retours de collecte.

# Le lot

## Le concept

Il n'existe pas de manière standardisée de considérer les "opérations de collecte".
On s'appuie sur le concept abstrait de "lot", qui est un objet visant à regrouper des UE au sein d'une même "opération de collecte", le "regroupement" étant considéré comme "toutes les UE partageant les mêmes métadonnées pour une opération de collecte donnée".
Par exemple : Plusieurs lots pour l'ENL, tel que le lot pour la collecte de la séquence 1 web, celui pour la séquence 1 téléphone, celui pour la séquence 2 web, etc.
L'objet Lot est plus large que l'opération de collecte dans la mesure où peuvent être définis des "lots" de "lots", afin de caractériser la mutualisation d'un sous-ensemble de métadonnées entre des opérations de collecte différentes.
Par exemple : les différents lots de l'ENL partagent le même libellé d'enquête, les mêmes objectifs, les mêmes résultats précédents, etc. Ou encore, les différentes séquences d'interrogation de l'EEC (=différents lots) qui partagent également un certain nombre de métadonnées.
L'objet enquête n'est pas caractérisé en tant que tel (exemple : l'enquête nationale Logement) car le concept ne convient pas pour représenter tous les cas (par exemple, les enquêtes ménage de type filtre, comme VQS, qui débouche sur une autre enquête avec des UE pourtant partagées). On lui préfère celui de "séries d'opérations statistiques" couplés avec des lots voire des regroupement de lots (des lots de lots).

Le concept de lot ne représente pas une opération de collecte unitaire mais bien un regroupement au sens des métadonnées, ainsi dans le cas de collecte concurrentielle (EEC) ou assimilées (enquêtes à carnet EDT et BDF), à un même lot correspond les opérations de collecte web et enquêteur (qui partagent les mêmes métadonnées).

A l'inverse, ce qui pourrait être considérée comme une même opération de collecte peut être découpée en plusieurs lots distincts.
Par exemple : la collecte de l'enquête Famille est découpée en deux lots, un pour la collecte des hommes, un pour la collecte des femmes, les métadonnées de personnalisation des communications de ces deux lots étant différentes. Un "supra-lot" regroupant ces lots (Famille femme et Famille homme) peut être utiliser pour mutualiser les métadonnées partagées entre ces UE.

## La modélisation REM

* Lot : l'objet Lot, il ne contient que les métadonnées mobilisées par REM à savoir :
* le type des unités (Logement/Individu/Entreprise) : cette métadonnée sert à caractériser la manière dont sont chargées les UEs fournies par une base de sondage. Par exemple : pour une enquête logement aucune personne n'est "surveyed" au chargement, à l'inverse dans une enquête individu l'une des personnes du logement est "surveyed".

classDiagram

class Lot {
    TypeUnit typeUnit
    }

# L'interrogation

## Le concept

L'interrogation correspond à l'association d'une unité enquêtée (UE ou SurveyUnit) à une opération de collecte (instanciée dans un concept plus général de "lot").
*Par exemple : l'interrogation d'un logement donnée lors du lot "Séquence 1 web de l'ENL", ou l'interrogation pour un même logement lors du lot "Séquence 2 web de l'ENL" (qui constituent deux interrogations différentes pour une même Unité Enquêtée).*

L'interrogation sert à capter toutes les données liées à une opération de collecte donnée mais qui n'ont pas nécessairement vocation à être réutilisée lors d'une collecte suivante.
*Par exemple : les données de personnalisation de questionnaire ou de communication, le pôle de gestion de l'interrogation (qui peut changer pour une UE d'une collecte à l'autre) ou encore le commentaire laissé par l'enquêteur (qui n'a pas forcément vocation à passer d'un enquêteur à l'autre).*

Comme déjà défini dans le concept de lot, à une même interrogation peut correspondre "deux interrogations réelles différentes", par exemple dans le cas d'une collecte concurrentiel web et enquêteur (EEC), où la même interrogation sera collectée en concurrence sur une plateforme de collecte web et sur une plateforme de collecte enquêteur. Cette consolidation simplifiera les processus de communication (où une seule communication devra être envoyée, mais vaudra pour les deux interrogations) et de traitements post-collect (où les données multimode doivent être consolidées entre ces deux collectes "concurrentes" avant traitement post-collecte).

Cela implique qu'à une même interrogation, plusieurs questionnaires peuvent être associés. Si dans la majorité des cas, pour un même lot toutes les interrogations auront les mêmes questionnaires, il peut exister des cas où l'on souhaite avoir plusieurs modèles de questionnaire en fonction des caractéristiques de l'UE (par exemple, avoir un modèle de questionnaire entreprise de service et un autre entreprise de commerce, plutôt qu'un "gros questionnaire unique"), ce qui implique de gérer ce lien au niveau de l'interrogation, même si, une règle métier au chargement, quasi systématique, consistera à "recopier" les métadonnées "Modèle de questionnaire" d'un lot à toutes les interrogations qui lui sont ajoutés.

## Modélisation REM

* Interrogation : le concept central de REM qui sert à entreposer des interrogations avant le lancement d'une collecte (et ainsi distribuer dans les différents SI les "échantillons" à collecter) ou pour "préparer" une collecte ultérieure à partir d'un échantillon déjà collectée (en remobilisant les informations de contact éventuellement mises à jours par exemple). Au niveau de l'interrogation, on peut préciser quelques propriétés emblématiques :
* id Gestion : correspond un id "externe" (issu d'un SI externe) permettant d'identifier le gestionnaire ou le service de gestion en charge de l'interrogation
* sous-échantillon : un concept utilisé pour l'organisation de la collecte enquêteur qui permet de "découper" des lots en sous-ensembles sur lesquels prioriser des collectes ou sur lesquels faire porter des consignes spécifiques.
* commentaire : le commentaire d'un enquêteur sur une interrogation
* id connexion web : un identifiant particulier utilisé pour la connexion Platine par le répondant
* idCollector : l'id de l'enquêteur devant (avant une collecte) ou ayant (après une collecte) réalisé l'interrogation, utilisé pour la pré-affectation d'enquêteurs à partir de l'enquêteur ayant effectivement effectué l'interrogation précédente (la règle métier "interrogation précédente" est calculée au chargement de l'interrogation)
* Questionnaire : le concept représentant les différents questionnaires associés à une interrogation. L'objet permet notamment de "typer" les différentes données nécessaires à la personnalisation d'un questionnaire en fonction du questionnaire correspondant.
* Communication : le concept représentant les différentes communications qui sont prévues pour un lot d'interrogations. Comme pour le questionnaire, cet objet sert à "typer" les différentes données nécessaires à la personnalisation d'une communication en fonction du modèle de communication correspondant.

classDiagram

    class Interrogation {
    id Gestion
    sous-echantillon
    commentaire
    id de connexion web
    id collector
    }

    class Questionnaire {
    idModeleQuestionnaire
    }
    
    class Communication {
    idModeleCommunication
    }
    
    class Lot {
    }

    Lot "1" -- "0..*" Interrogation
    Interrogation "0..*" -- "1" SurveyUnit
    Interrogation "1" -- "1..*" Questionnaire
    Interrogation "1" -- "1..*" Communication

# [UE * Lot = Interrogation] dans les plateformes de collecte

## Sabiane
### Modélisation Sabiane

classDiagram

    class Campaign

    class SurveyUnit

    class Person

    SurveyUnit "0..*" -- "1" Campaign
    SurveyUnit "1" -- "1..*" Person

### Consolidation Platine/REM

L'objet Campaign de Sabiane correspond à un lot REM.
L'objet SurveyUnit de Sabiane **ne correspond pas à l'UE de REM** mais plutôt à l'**Interrogation**.
L'objet Person de Sabiane correspond au concept de Person de REM, même s'il n'est, aujourd'hui (juin 2024), qu'utilisé pour la gestion des informations de contact. Il pourra être étendu avec l'articulation de questionnaires et la nécessité de proposer un accès plus direct à des questionnaires individuels (aujourd'hui, un même questionnaire fait "tout" et les informations sur les personnes relèvent de "données de questionnaire" plus que de données d'Unité enquêtée).

## Platine
### Modélisation Platine

classDiagram

    class Campaign
    
    class Survey
    
    Class Partitionning
    
    Survey "1" -- "1..*" Campaign
    Campaign "1" -- "1..*" Partitionning

    Class Questionning
    
    Questionning "1..*" -- "1" Partitionning

    class SurveyUnit

    SurveyUnit "1" -- "1..*" Questionning

    class Contact

    Contact "1..*" -- "1..*" Questionning

### Consolidation Platine/REM

C'est l'objet Partitionning qui correspond au lot REM.
Les objets de plus haut niveau Campaign et Survey visent à mutualiser des métadonnées entre lot et doivent être consolidés avec la représentation métadonnées en série d'opérations ou en lot (métadonnées non stockées par REM).
L'objet Questionning correspond à l'interrogation REM.
L'objet SurveyUnit correspond à SurveyUnit côté REM.
> [name=EricS]Il faut checker l'usage qui est fait de cet objet côté Platine. En particulier, quand on charge une enquête entreprise, doit on créer ces objets ou au contraire référencer ceux déjà existants ?

L'objet Contact est à rapprocher des objets Person disposant de ContactData dans REM. Mais il ne recouvre pas le concept de Person à interroger (surveyed = true dans REM), des objets qui ne sont pas modélisés à ce niveau dans Platine et relèvent de données de questionnaires.

# Les externals

## Le concept

Chaque SI filière alimenté peut faire l'objet d'une "personnalisation spécifique", c'est-à-dire mobiliser des données "externes" au moment du transfert de données sur une interrogation. Ces données sont qualifiées "d'externe" au sens où elles sont fournies par un SI externe à la filière (MOA, base de sondage, SI d'enquêtes, etc.) et qu'elles ne font l'objet d'aucune mise à jour pendant une opération de collecte. Ce sont des données considérées comme "anonymes" (on en connait pas la structure précise) et "passives" (elles ne sont que transférées, ni lues, ni mises à jour) pour les outils Préparer.
Ainsi, un external est un lot de "données externes" (au sens défini ci-dessus) associé à un usage précis, afin d'être en mesure de mobiliser ce lot de donnée pour l'usage correspondant.
Ex : pouvoir charger des interrogations dans Platine et/ou Sabiane en fournissant les données externes nécessaires à la personnalisation du questionnaire, ou déclencher l'envoi d'une communication en fournissant les données externes nécessaires à la personnalisation des courriers ou mail envoyés.

## La modélisation REM

* external : classe abstraite qui modélise un ensemble de données au format Json (un json data) sans présupposé sur la structure. Cette classe abstraite se spécialise pour chacun des usages considérés :
* extQuestionningData : les données externes nécessaires pour la personnalisation d'un questionnaire donné;
* extFaData : les données externes nécessaires à la personnalisation des fiche-adresse papier imprimées;
* extPostCollectData : les données externes à mobiliser dans les processus post-collecte;
* extCommunicationData : les données externes nécessaire à la personnalisation d'une communication donnée;
* extCoverPageData : les données nécessaires à la personnalisation de la page de garde des questionnaires web (cet usage est distinct de celui de personnalisation du questionnaire car ce ne sont pas les mêmes SI qui sont concernés : questionnaire -> Stromae, page de garde -> Platine)

classDiagram
    class External {
        <<abstract>>
    }

    class ExtQuestioningData {
    json data
    }
    class ExtCommunicationData {
    json data
    }
    class ExtCoverPageData {
    json data
    }
    class ExtFaData {
    json data
    }
    class ExtPostCollectData {
    json data
    }

    External <|-- ExtQuestioningData : inherit 
    External <|-- ExtCommunicationData : inherit
    External <|-- ExtCoverPageData : inherit
    External <|-- ExtFaData : inherit
    External <|-- ExtPostCollectData : inherit

## Les différents usages d'Externals

### ExtFaData

Les données externes nécessaire à l'impression des fiche-adresse papier relève de l'unité enquêtée. Elles peuvent être fournies lors d'une première collecte ne mobilisant pas de FA papier et être nécessaire pour une interrogation ulérieur mobilisant ces supports papier.
Donc elles sont rattachées à l'unité enquêtée et sont uniques pour une UE (donc communes à toutes les interrogations de l'UE).

classDiagram
class SurveyUnit
class ExtFaData{
json data
} 

SurveyUnit"1" -- "0.1"ExtFaData

**Usages**
Elles sont mobilisées lors de l'export par Beattles d'interrogation pour Opale.

### ExtCoverPageData

Les données externes nécessaires à la personnalisation de la page de garde du questionnaire relève d'une interrogation. Elles dépendent du type d'interrogation (première, deuxième, web, carnet, etc.) et sont donc rattachées à l'interrogation. Une même interrogation n'a qu'un seul lot de données externes pour la page de garde. Elles ne concernent que les interrogations mobilisées dans une collecte web.

classDiagram
class Questionning
class ExtCoverPageData{
json data
} 

Questionning"1" -- "0.1"ExtCoverPageData

**Usages**
Elles sont mobilisées lors du chargement d'interrogation dans Platine.

**Remarque**
Les mêmes données peuvent être mobilisées pour une partie de la personnalisation de communication (variables externes "QuiRepond" identiques entre communication et page de garde). Si ces données reposent bien sur une même métadonnée initiale, le choix fait de les modéliser sous forme d'external implique qu'elles devront être dupliquées qui dans ExtCoverPageData, qui dans ExtCommunicationData lors du chargement de l'interrogation dans REM.

### ExtPostCollectData

Les données externes nécessaires à l'exécution de processus post-collecte relèvent de l'interrogation. Elles peuvent varier d'une interrogation à l'autre, mais reste unique pour une interrogation donnée.

classDiagram
class Questionning
class ExtPostCollectData{
json data
} 

Questionning"1" -- "0.1"ExtPostCollectData

**Usages**
Elles sont mobilisées lors de la livraison de données collectées en post-collect (*reste à préciser*)

### ExtQuestionningData

Les données externes nécessaires à la personnalisation de questionnaires relèvent des différents questionnaires associées à une interrogation. Si pour un questionnaire donné, il y a un unique ExtQuestionningData, une même interrogation peut cependant avoir plusieurs questionnaires associés (cf. Interrogation).

classDiagram
class Questionning
class Questionnaire{
idModelQuestionnaire
}
class ExtQuestionningData{
json data
} 

Questionning"1" -- "1.*"Questionnaire
Questionnaire"1" -- "0..1"ExtQuestionningData

### ExtCommunicationData

Les données externes nécesaires à la personnalisation de communication relèvent des différentes communications associées à une interrogation. Comme pour les données externes nécessaire à la personnalisation d'un questionnaire, il n'y a qu'un ExtCommunicationData pour une communication donnée, mais il peut y avoir plusieurs Communications associées à une interrogation donnée.

classDiagram
class Questionning
class Communication{
idModelCommunication
}
class ExtCommunicationData{
json data
} 

Questionning"1" -- "1.*"Communication
Communication"1" -- "0..1"ExtCommunicationData

[modélisation MB](https://mermaid.live/view#pako:eNp9Vm1v4jgQ_itRPp4KIiwLBa0qtYTby6mlHIGu7pQvJhmotcHOOU6vbNX_fn5LsBNaPoA9Hs_LM8-MefNTmoE_83u9XkI45jnMvIcw9NaLh4QoYULSHJVliNGBoWOz9-4p994S4onPPSUHL6c8yvR-cypgSzD3uFloccwZlopoB7kjKSv2AqclOkJC3s8eIsKBMXpAHFNS-9puo9DD9knt1Rg7IoIOcATCWwcpzXNIOWUteVlC-uxICP3OUNES3dNDy9xROnFk_8FuTgkRXqy4_iwpWQqUPXjlc_oCbCXiCxFH3eMVLYWKClMY0DoWIA9SzeDw7ZsHpDoC0-jc3Gix_sxvN5G7X7X2P5z9Sp1bnv6qoJR2CcIMpNu89msy_bejUKergjyKr256jVUiTFjZqSv9_gWv8lQSLfGDxPd6PbEY9Pu_ibVDDql2IWRxSyuri8GlWzrdWBFQUdamdNmIW5ShDB9wm3gZLoscGRrbRMH8NL-Ix-9IguAZFJquEUiInM_RNQefl_5uG0fLRRx7ehstw-gpCre390bwx6NU-F67s3JuQO31bgxQ1unMKxBTTE-I25LWvc61c_i3WcZA_LoEKjkD4MvquAPmHDAoQAwi2UAkg9cLlyQel2y1gUfacVwVRQ6dXpVl6Vz5hQtZKiFwdUFEcq6hLe2YKAtIMcpDLKLCu0oTzZkbFeHs1LWm5dKecm9141yMmorgVKF-qRvTjsLl4WNpWe3XLmrTaoEqbtd7hz52c8q1KXmHA8KUKUUrgV2F80wsHOE-p5S1Ci2aO0Wli1zWqN1RmgMiHuTwgnhbKiu-Ylg0Lz_p8qTcQFBz9MNUzpGfk1oBK9sPU6aFTnwHEER2E9ljVnYJK6x2hRni8Li_w4y7j9S-IumZXHWOemRB1uIP4SjlatiYaMULWg-sNSI_jbrJqIuCZSEhtrnuYF49UwJ1X3-sKteLI8KKTB_RyYzvGtMPw7P41hTnHEbDNVqxFLxS_biw7dGLpIWLPDFJWEiqiD-xZ26CTkxjagUiJntstLUlS9C8Rdrq57P-NnyIllG8WYuH_mmhZWG0Xsw3j-u_6_m_WayfosWPxVpF4l_5wozwmom_e8p64vNnQenEn4llhtjPxBeaQg9VnMYnkvozziq48qtCktD8A6yFBSL_UGpv_dmb_-rPvo5G_WA0CgajweDLdDAeXvknfxZcT_rj8dfrYDIcDyaj4fD9yv-l7gf9SRCMp4Pp8Ho8nY6_TK7f_wfmgIhH)