Profil pour l`archivage des données du revenu minimum d`insertion

Standard d'échange de données pour l'archivage
Profil pour l’archivage des données du Revenu minimum d’insertion V.2 (2010)
1
CONTEXTE
2
2
OBJECTIF
3
3
CYCLE DE VIE DES DONNÉES
4
3.1
Ouverture d’un dossier RMI
4
3.2
Motifs de clôture
5
3.3
Durée d’utilité administrative
6
3.4
Sélection des données
7
3.5
Données à verser
8
3.6
Données à éliminer
10
4
5
6
FONCTIONS D’EXPORT SOUHAITÉES
11
4.1
Définition
11
4.2
Déclenchement
11
4.3
Contenu de l’export
11
4.4
Traçabilité de l’export
13
EXPORT DES DONNÉES À VERSER
14
5.1
Structure des données à verser pour les bénéficiaires du RMI
14
5.2
Structure du bordereau de versement
15
5.3
Forme du contenu de données
34
DONNÉES À ÉLIMINER
37
6.1
Nature des données à détruire
35
6.2
Bordereaux d’élimination
38
1
1
Contexte
Aux termes des articles L 211-1 et L 211-4 du code du patrimoine, les archives publiques comprennent l’ensemble des documents qui, quels qu’en soient la
date, la forme ou le support, procèdent de l’activité de l’Etat, des collectivités territoriales, des établissements et entreprises publiques, et des organismes de
droit privé chargés de la gestion des services publics ou d’une mission de service public, ainsi que les minutes et répertoires des officiers publics et
ministériels.
" A l’expiration de leur période d’utilisation courante par les services et organismes qui les ont produits ou reçus, les documents font l’objet d’un tri pour
séparer les documents à conserver et les documents dépourvus d’intérêt administratif et historique, destinés à l’élimination " (article L 212-3).
Les documents à conserver doivent être transférés (versés) dans un service public d’archives ; lors de leur versement, les documents doivent être
accompagnés d’un bordereau descriptif (bordereau de versement). De même, lorsque les services, établissements et organismes souhaitent éliminer des
documents, ils doivent en aviser le service public d’archives territorialement compétent en soumettant à son visa un bordereau d’élimination ; toute
élimination est interdite sans ce visa (article 16 du décret n°79-1037 du 3 décembre 1979).
Cet ensemble de règles s’applique aussi bien aux documents papier qu’aux documents électroniques.
Lorsqu’il s’agit de dossiers papier référencés dans des bases de données, voire de dossiers entièrement électroniques, les données électroniques à conserver
ou à détruire doivent être transmises ou signalées au service public d’archives territorialement compétent sous forme électronique, conformément au
standard d’échange de données pour l’archivage, dont la version 0.1 a été publiée par la DAF et la DGME en mars 2006, mise à jour dans une version 0.2 en
2010. Les services publics d’archives seront ainsi en mesure d’inclure ces données dans leur propre système d’information, en vue d’en assurer la bonne
conservation.
Le standard d’échange de données pour l’archivage spécifie les messages nécessaires aux différents échanges entre le service versant (service à l’origine du
versement des données ou de la demande de visa d’élimination) et le service public d’archives. Sont en particulier décrits les bordereaux de versement et
d’élimination eux-mêmes, mais aussi d’autres messages nécessaires au cas où le dialogue entre le service versant et le service public d’archives se poursuit
sous forme électronique (accusés de réception, messages d’anomalie, etc.). Tous ces messages prennent la forme de fichiers XML, conformes aux règles de
l’UN/CEFACT, organisme des Nations Unies compétent pour l’harmonisation du commerce électronique et des échanges électroniques en général.
Lorsque les données électroniques à archiver sont gérées dans une application, le standard d’échange doit être mis en œuvre par cette application.
2
2
Objectif
Le présent profil concerne la manière dont les progiciels qui assurent la fonction de gestion des dossiers générés dans le cadre du Revenu minimum
d’insertion [RMI] doivent sélectionner et exporter les données à verser ou à éliminer, conformément au standard d’échange de données pour l’archivage.
Les données sélectionnées seront ensuite soumises au service public d’archives territorialement compétent par le(s) service(s) en charge du RMI au Conseil
général concerné pour versement ou élimination.
Elles comportent :
- la sélection des données à verser et à conserver par le service public d’archives territorialement compétent à l’issue de leur durée d’utilité administrative,
établie en conformité avec le code de l’action sociale et des familles (art. L.262-40) et, le cas échéant, avec la charte d’archivage établie avec le(s) service(s)
en charge du RMI ;
- la structure du bordereau de versement électronique (description des données à verser) ;
- la structure des données et métadonnées à verser ;
- la nature des données à détruire à l’issue de leur durée d’utilité administrative, établie en conformité avec la charte d’archivage conclue entre le(s)
service(s) en charge du RMI et le service d’archives territorialement compétent ;
- la structure du bordereau d’élimination électronique (description des données à détruire) ;
- les fonctions d’export souhaitées (mode de déclenchement, paramètres...).
Les messages autres que le bordereau de versement et le bordereau d’élimination décrits par le standard d’échange (accusés de réception...) n’ont pas été
retenus dans le présent profil car il n’est pas prévu, dans un premier temps, que les échanges entre le(s) service(s) en charge du RMI et le service public
d’archives territorialement compétent se déroulent sous forme entièrement dématérialisée.
Le profil a été établi par un groupe d’archivistes départementaux et d’informaticiens des conseils généraux, animé par Emilie Goubin et Gwénaëlle Morvan
(Archives départementales et Direction des systèmes d’information du Finistère) et par Nathalie Regagnon et Elise Manuelian (Archives départementales de
la Haute-Garonne), avec l’appui des Archives de France (Françoise Banat-Berger et Michel Jacobson).
3
3
Cycle de vie des données
L’organisation de l’action sociale n’est pas uniforme d’un Conseil général [CG] à l’autre ; deux " schémas " d’organisation peuvent néanmoins être identifiés :
des directions thématiques centrales et des structures de proximité (centre médico-social, centre départemental d’action sociale,… il existe différentes
terminologies), chapeautées par une ou deux directions, qui centralisent les décisions,
des directions thématiques centrales et deux niveaux territoriaux : des structures de proximités (ex : centre médico-social, centre départemental d’action
sociale) et des structures intermédiaires (ex : unités territoriales, territoires d’action sociale).
Chaque département a réparti librement les compétences entre ces différents niveaux hiérarchiques : la décision d’accord de l’aide peut, selon les
départements, être prise au niveau central ou au niveau territorialement le plus proche de l'usager. On ne peut visiblement pas généraliser les procédures
de gestion des dossiers.
Concernant le RMI, l’organisation mise en place, et les niveaux de décision peuvent donc être très différents d’un CG à l’autre1.
3.1
Ouverture d’un dossier RMI
Le dispositif RMI se caractérise par la multiplicité des acteurs présents, ce qui engendre de fait une multiplicité des dossiers papier, voire électroniques,
existants. On peut ainsi trouver jusqu’à 5 dossiers papier individuels, en fonction de l’organisation mise en place par le Conseil général et du suivi assuré
auprès du bénéficiaire par :
- l’organisme instructeur de la demande : structure territoriale du CG, CCAS, associations, missions locales…(en fonction des conventions existantes), dont la
mission consiste à identifier le public qui s’adresse à lui et à l’orienter, en fonction des critères fixés par la loi, vers le dispositif RMI,
- la commission locale décisionnaire, émanation du Conseil général (CLI, CLLE),
- l’organisme payeur (CAF/MSA),
- la structure territoriale du CG (centres médico-sociaux, centres départementaux d’action sociale…), qui assure le suivi du bénéficiaire au sein du dispositif
(désignation d’un travailleur social référent, rédaction du contrat d’insertion…),
- la direction thématique centrale du CG, pour les cas plus complexes.
1cf Tableau comparatif des procédures RMI des départements du Finistère, de la Haute-Garonne et de l’Eure, annexe 1
4
Ces différents dossiers papier ne font pas systématiquement l’objet d’un regroupement une fois le dossier clos.
Les demandes rejetées au stade de l’instruction peuvent ne pas être intégrées dans le logiciel, en fonction de l’organisation mise en place par le CG. La
création d’un dossier de bénéficiaire dans les progiciels de gestion RMI utilisés par les Conseils généraux peut en effet résulter de l’intégration de données
transmises par l’organisme payeur (Caisse des allocations familiales ou Mutuelle sociale agricole), une fois la décision d’ouverture des droits prise.
Cette intégration de données est automatique (exports XML) ou manuelle (disquettes).
Un dossier de bénéficiaire peut être relatif à une seule personne (RMI isolé) ou à deux personnes vivant sous le même toit (RMI couple). Dans ce dernier
cas, le n° de bénéficiaire est le même.
Chaque action relative à un bénéficiaire est enregistrée dans la base de données, que ce soit directement par les services du Conseil général ou par
intégration de données en provenance de l’organisme payeur ; les interventions des différents services en charge du RMI au Conseil général (commission
locale d’insertion, structure territoriale, direction thématique centrale…) sont enregistrées dans le même progiciel.
La CNIL a fixé de façon générique une durée de conservation, sur support électronique, des données à caractère personnel relative aux bénéficiaires d’aide
sociale à vingt-quatre mois après la dernière aide accordée2 : un dossier électronique de bénéficiaire peut donc être ré-activé dans un délai de 24 mois à
compter de sa clôture.
Le parcours d’un individu dans le dispositif n’étant pas linéaire, les données relatives à chaque bénéficiaire sont historisées : une même personne peut ainsi
faire l’objet de plusieurs présences (attribution du RMI, puis reprise d’emploi pour 10 mois, puis chômage, puis retour dans le dispositif…). De même, une
même personne peut avoir signé différents contrats d’insertion, soit au sein de la même présence, soit au cours de ses différentes présences, sachant que la
souscription d’un contrat d’insertion est normalement une obligation pour bénéficier du dispositif.
3.2
Motifs de clôture
Il existe plusieurs modalités de sortie du dispositif :
suspension des droits, soit sur impulsion du CG (non signature du contrat d’insertion par exemple), soit sur impulsion de l’organisme payeur (déclaration
trimestrielle de ressources, obstacle à contrôle…). Dans ce cas, un délai de plusieurs mois (4 pour le Finistère par exemple) est appliqué entre la date de
suspension des droits et la radiation du dispositif : il arrive en effet régulièrement que les droits d’un bénéficiaire soit suspendus, par exemple s’il a perçu
une rémunération pour du travail intérimaire, puis réactivés un à deux mois plus tard,
radiation directe (fraude, bénéfice à tort, contrôle CAF…),
2
CNIL, guide « Les collectivités locales », http://www.cnil.fr/fileadmin/documents/La_CNIL/publications/CNIL_Guide_CollLocales.pdf
5
déménagement du bénéficiaire dans un autre département : dans ce cas, le dossier est considéré comme clos dans le département d’origine ; le dossier
papier est transmis dans le département dont dépend le bénéficiaire, a contrario des données électroniques,
retour à l’emploi.
Un traitement automatique permet de détecter les dossiers sujets à radiation dans la base de données de production. Cette liste est alors validée par le
Conseil général, puis transmise à l’organisme payeur, soit automatiquement (export XML), soit manuellement (disquettes, CD-Rom).
L’organisme payeur transmet le courrier de radiation à l’allocataire.
3.3
Durée d’utilité administrative
La Durée d’utilité administrative des dossiers RMI papier a été fixée par la circulaire AD99-1 à 3 ans à compter de la clôture du dossier.
Cela étant, comme vu ci-dessus, plusieurs dossiers existent au sein du Conseil général : le dossier d’instruction, le dossier de l’organe décisionnaire
(Commission locale d’insertion), le dossier de suivi du parcours du bénéficiaire au sein de l’organisme, le dossier de la direction thématique, qui peuvent être
assimilés à des dossiers opérationnels, dans le sens où ils sont constitués par les services chargés du suivi du parcours des bénéficiaires.
Il existe par ailleurs un dossier chez l’organisme payeur (CAF, MSA) : en effet, l’ordonnateur de la dépense « individuelle », en direction du bénéficiaire, est,
dans le cas du RMI, l’organisme payeur, par conventionnement avec le Conseil général, le Conseil général étant dans ce cas précis ordonnateur d’une
dépense globale, reversée à l’organisme payeur à échéances régulières, suivant les conventions passées entre les différents organismes.
La définition de la DUA des documents comptables a été précisée par l’instruction DPACI/RES/2008/008 du 5 mai 2008 portant sur la DUA des documents
comptables détenus par les ordonnateurs. Cette instruction fixe la DUA à 10 ans, délai qui correspond à la prescription pour gestion de fait. Ce délai peut
être réduit, naturellement, en cas de quitus.
Il en ressort donc les DUA suivantes, calculées à compter de la sortie du dispositif :
- dossier d’instruction = 3 ans,
- dossier de l’organe décisionnaire = 6 ans,
- dossier comptable = 10 ans.
6
3.4.
Sélection des données
Rappel pour les dossiers papier : la circulaire AD 99-1 préconise un échantillonnage de 20 % des dossiers papier. Cela étant, dès lors que l’archivage
d’une partie des données électroniques, au moins égale voire supérieure à ces 20 %, est assuré, une réduction de l’archivage des dossiers papier peut être
appliquée ; à noter que plusieurs départements très peuplés se sont vu accorder des autorisations de réduction d’échantillon sur ce type de dossiers (2 %
par exemple pour Paris et les Bouches-du-Rhône).
Pour les données électroniques, deux niveaux de tri sont distingués :
- entre les dossiers électroniques : échantillonnage des dossiers clos les années 0 et 5 (l'échantillonnage proposé est un minimum : il est possible
pour les services d'archives d'opter pour le versement des données sélectionnées pour l'ensemble des dossiers clos, ce quelle que soit l'année, afin de
conserver une trace de l'intégralité des bénéficiaires du dispositif).
Identification du dossier
DUA papier
Sort final papier
DUA électronique
Sort final
-dossier d’instruction CCAS, associations conventionnées,
missions locales
3 ans à/c de la sortie
du dispositif
Tri : 20 % des
dossiers clos les
années 0 et 5, soit 5
%
2 ans à/c de la sortie du
dispositif
Conservation ou
-dossier d’instruction et de suivi du service territorial du
Conseil général (= dossier classé dans le dossier social du
bénéficiaire, dans lequel se retrouvent également toutes
les autres interventions du service auprès du foyer)
6 ans à/c de la sortie
du dispositif
Suit le sort final du
dossier
de
suivi
social constitué au
niveau
des
structures
territoriales du CG
-dossier de la commission locale décisionnaire ou de la
direction thématique centralisée, suivant l’organe de
décision
6 ans à/c de la sortie
du dispositif
Tri : 20 % des
dossiers clos les
années 0 et 5, soit 5
%
2 ans à/c de la sortie du
dispositif
Conservation ou
-dossier comptable
10 ans à/c de la sortie
du dispositif
Tri : 20 % des
dossiers clos les
années 0 et 5, soit 5
%
2 ans à/c de la sortie du
dispositif
Conservation ou
Revenu minimum d’insertion, allocataire :
Tri :
versement
des
dossiers clos les années
0 et 5
Tri :
versement
des
dossiers clos les années
0 et 5
Tri :
versement
des
dossiers clos les années
0 et 5
7
Nota : dans la mesure où la durée d’utilité administrative des dossiers papier est supérieure à celle des données électronique, il est nécessaire de
coordonner leur archivage, notamment lorsque les dossiers papier sont classés suivant les numéros de dossiers attribués par le progiciel, puisque la DUA
d’un dossier papier est de 3 à 6 ans, et la DUA des dossiers électroniques de 2 ans, suivant les recommandations de la CNIL : le bordereau de versement
pour les années 0 et 5 et les bordereaux d’élimination des dossiers non retenus récapitulent la liste des dossiers des clos (numéros, noms, prénoms, dates
de naissance des individus, et commission locale d’insertion décisionnaire), ce qui permet d’assurer l’archivage concomitant des dossiers papier. Il faut donc
permettre l’édition automatique à partir des applications métier, des bordereaux de versement et d’élimination dès la fin de la DUA électronique, même si on
ne procède pas encore à l’archivage des dossiers papier.
- entre les données d’un dossier : à l’intérieur des dossiers composant l’échantillon retenu pour conservation définitive, seule une sélection de données
sera conservée définitivement.
Plusieurs catégories de données ont été retenues pour conservation définitive. Elles permettent de connaître l’identité et l’environnement du bénéficiaire et
son parcours au sein du dispositif :
- données d’identification, dont l’état civil et les données relatives à la domiciliation,
- données " sociologiques " (formation initiale, profession, mode de transport, logement…) ,
- données relatives à la gestion du dispositif (montant, nombre et type de contrats d’insertion, nombre de présence…).
Dans tous les cas, la liste des données à conserver (§ 3.5) constitue un minimum, à affiner en fonction des enquêtes menées auprès du service producteur
car, d’un département à un autre, la structure d’origine de l’application de gestion, son paramétrage, ainsi que les pratiques de saisie, peuvent varier
fortement.
A noter que la sélection des données ne se fonde pas sur le taux de remplissage de chaque champs, les consignes de saisie données aux utilisateurs étant
très diverses d’un département à l’autre.
3.5.
Données à verser
Identification du dossier
n° de dossier
nom
nom de jeune fille
prénom
code individu (cas du RMI couple)
8
nom du conjoint (cas du RMI couple)
date et lieu de naissance
nationalité
contexte familial (mode de vie, composition du foyer, nombre de personnes à charge)
adresse
îlot IRIS (tranches 2000 hab., très utilisé dans les statistiques RMI)
Logement
statut logement
nombre de pièces
Situation financière
ressources : nature
charges
Transport
permis de conduire
mode de transport
Formation
niveau de formation
qualification
Activité :
profession
secteur
statut
catégorie socio-professionnelle
passé/période d’inactivité
9
RMI
organisme instructeur
organisme payeur
référent
CLLE/CLI
motif de la demande
présence : date de début, date de fin/date d’ouverture, date de fermeture des droits
montant
motif de radiation
Contrats
date de début/ date de fin
durée
type de contrat
3.6.
Données à éliminer
Un export de données à éliminer porte sur :
- le cas échéant, l’intégralité des données relatives aux dossiers des bénéficiaires hors échantillon (dossiers clos années 1, 2, 3 , 4, 6, 7, 8, 9),
- sur les données non sélectionnées relatives à l’ensemble des bénéficiaires,
- les dossiers rejetés.
10
4
4.1
Fonctions d’export souhaitées
Définition
Par export, on entend :
- soit l’export des données à verser dans un service public d’archives,
- soit l’export des données à éliminer dans le cadre d’une demande de visa d’élimination.
4.2
Déclenchement
L’export des données à verser et l’export des données à éliminer doivent pouvoir être déclenchés manuellement, à partir de l’interface du progiciel. Ils
doivent pouvoir être déclenchés indépendamment l’un de l’autre.
Ce déclenchement doit être possible pour un utilisateur métier disposant du rôle d’administrateur de données3.
4.3
Contenu de l’export
Il est prévu qu’un export porte sur un ensemble de dossiers des bénéficiaires clos dans un intervalle de dates spécifié. Les données destinées à l’élimination
(dossiers de demandes rejetées, demandes sans suite, et dossiers des bénéficiaires hors échantillon) ne seront pas transférées au service d’archives
territorialement compétent ; seuls les bordereaux d’élimination seront transmis.
Il est demandé aux éditeurs d’exporter un maximum de données en clair, c’est-à-dire de " traduire " les codes utilisés dans le progiciel au moment de
l’export (ex. : ne pas mettre " 1B " mais " Quimper " pour désigner une commune).
La fonction d’export doit proposer à l’utilisateur un certain nombre de paramètres, décrits ci-après (ils correspondent à des balises du standard d’échange) :
3 L’administrateur de données tel qu’on l’entend ici est le référent chargé de procéder concrètement aux versements et aux éliminations de données depuis
la base métier. Il dispose de droits spécifiques pour ce faire et est désigné en concertation avec le service informatique et le service d’archives
territorialement compétent.
11
Paramètres
Balises du standard
Caractéristiques
Objet de l’export
<Comment>
A saisir
Date de l’export
<Date>
Renseigné automatiquement
Intervalle de dates des dossiers à exporter
<OldestDate> ; <LatestDate>
A saisir
Identifiant de l’export
<TransferIdentifier> ; <DestructionRequestIdentifier>
Renseigné automatiquement
Nom et identifiant du service d’archives
<ArchivalAgency> ; <Identification> ; <Name>
Peut-être pré-paramétré
Nom et identifiant du service réalisant l’export
<TransferringAgency>; <Identification> ; <Name>
Peut-être pré-paramétré
Adresse du service d’archives et/ou du service
réalisant l’export
<Address> ; <BuildingNumber>;
<CityName> ;<Country> ; <Postcode> ;
<StreetName>
Nom, prénom, fonction, téléphone/courriel de la
personne qui réalise l’export/qui réceptionne l’export
<Contact> ; <PersonName> ; <Responsability> ;
<Communication>
A saisir en partie/Renseigné
automatiquement
Nom, identifiant du service qui a produit les données
<OriginatingAgency>
Peut-être pré-paramétré
Référence du contrat de service
<ArchivalAgreement>
Peut-être pré-paramétré
Référence du profil utilisé
<ArchivalProfil>
Peut-être pré-paramétré
Langue de description
<DescriptionLanguage> ; <Language>
Peut-être pré-paramétré
Niveaux de description
<DescriptionLevel>
Peut-être pré-paramétré
Intitulé de l’export
<Name>
A saisir
Description et communicabilité du contenu de
l’Archive
<Description> ; <AccessRestriction> ; <Code> ;
<StartDate>
A saisir pour la partie Description ; peut être
pré-paramétré pour la partie accessibilité
Historique de la conservation
<CustodialHistory>
Pourra être pré-rédigé en concertation avec
les archivistes
Mots clés ; communicabilité des mots-clés
<KeywordContent> ; <KeywordReference> ;
<KeywordType> ; <AccessRestriction>;<Code> ;
<StartDate>
Peut-être pré-paramétré
Communicabilité de l’Archive
<AccessRestriction> ; <Code> ; <StartDate>
Peut-être pré-paramétré
DUA et sort final
<Appraisal> ; <Code> ; <StartDate> ; <Duration>
Peut-être pré-paramétré
[cette liste est à affiner ou à compléter suivant les logiciels concernés et les discussions avec les éditeurs]
12
4.4
Traçabilité de l’export
Le progiciel doit comporter un historique des exports réalisés (nature de l’export : versement ou demande de visa d’élimination, date de l’export, date de
destruction des données à la suite du visa du service public d’archives territorialement compétent).
Les données du progiciel qui ont été exportées doivent être " marquées " dans la base (suppression logique), de manière à pouvoir être détruites facilement
de cette base une fois que l’autorisation du service public d’archives territorialement compétent a été obtenue (suppression physique).
13
5
5.1
Export des données à verser
Structure des données à verser pour les bénéficiaires du RMI
Le tableau ci-dessous présente la structure des données à verser et permet d’expliquer et de préparer les exports automatisés de données conformément au
standard d’échanges de données pour l’archivage :
la structure de la description du contenu de données est établie en amont des versements et est conforme aux règles de la norme internationale de
description des archives, l’ISAD(G)
les métadonnées, qui rassemblent toutes les informations permettant d’identifier, de gérer et de retrouver les données versées ou éliminées : elles se
répartissent en informations de pérennisation, de représentation et de description
le contenu de données, soit les dossiers numériques des bénéficiaires du RMI, équivalents des articles d’un versement.
Modélisation d’un export de données à verser :
Structure de la description
Archive
ArchiveObject
RMI : dossiers
individuels clos en xx
Métadonnées
Information de
pérennisation et
informations
descriptives
Contenu de données
Information de
représentation
Données versées en pièces jointes
N° bénéficiaire (individuel)
Format
Identification du dossier
(+ nom et prénom, date
de naissance le cas
échéant)
Jeux de caractère
n° de dossier
Les données codées
doivent être retranscrites
en clair
nom
Date de début : date
d’ouverture des droits par
l’organisme payeur
Date de fin : date de
clôture des droits
Bénéficiaire 1
nom de jeune fille
prénom
… (cf 3.5 Données à verser supra)
Bénéficiaire 2
14
5.2
Structure du bordereau de versement
Concernant la structure et le contenu du bordereau de versement, il convient de se reporter au standard d'échange de données pour l'archivage
publié par la DGME et la DAF (chapitres 3.6.19 pour les données d’en tête du bordereau de versement et 3.5.2 pour le détail des métadonnées de
pérennisation).
15
Message de transfert : en-tête du bordereau de versement :
BBIE (attribut)
Cardinalité
Type
Définition et commentaires
Comment
0…1
Text
ArchiveTransfer
Commentaires sur le transfert
Date
1…1
DateTime
Date du transfert
Exemple
Obligatoire(
O) /
Recommand
é ( R)
<Comment>Transfert de
dossiers individuels de
revenu minimum
d’insertion</Comment>
R
Date au format ISO 8601
O
<Date>aaaa-mmjjThh:mm:ssZ</Date>
TransferIdentifier*
1…1
Identifier
Identifiant du transfert pour le service versant ; précise la
table de référence utilisée (par exemple, n° attribué par la
plate-forme d’échanges dans le cadre de versements
automatisés)
<TransferIdentifier
O
SchemeAgencyName="Dir
ection de
l’insertion">2008-00025
</TransferIdentifier>
HashCode (sans objet)
Signature (sans objet)
16
On précise dans le message ci-dessous quels sont les services concernés par le transfert (service versant et service public d’archives) ainsi que les contacts
et adresses nécessaires :
BBIE (attribut)
Cardinalité
Type
Définition et commentaires
Exemple
Obligatoire(
O) /
Recommand
é ( R)
TransferringAgency
Identification
1…1
Identifier
Identifiant unique du service versant.
<Identification>86</iden O
tification>
Name
0…1
Text
Dénomination du service versant.
<Name>Direction de
l’insertion et de la lutte
contre les
exclusions</Name>
R
Nom sous lequel l’organisation exerce son activité
TransferringAgency.Contact
PersonName
0…1
Text
Nom de la personne ou du service à contacter
<PersonName>M.
Dupont</PersonName>
R
Responsability
0…1
Text
Description textuelle des responsabilités générales ou
spécifiques du contact.
<Responsability>Corresp
ondant archives. Chef de
service</Responsability>
R
TransferringAgency.Address
BuildingName
0…1
Text
Nom du bâtiment
<BuildingName>Cité
R
administrative</BuildingN
ame>
BuildingNumber
0…1
Text
Numéro d’un bâtiment sur la voie à cette adresse
<BuildingNumber>12</B
uildingNumber>
CityName
0…1
Text
Localité
<CityName>Quimper</Ci R
tyName>
Country
0…1
Text
Pays
<Country
listVersionID="second
edition 2006"
R
R
17
>FR</Country>
Postcode
0…1
Code
Code postal
<Poscode>29000</postc
ode>
R
StreetName
0…1
Text
Nom de la voie
<StreetName>Boulevard
du
Finistère</StreetName>
R
Channel
0…1
Code
Code spécifiant le canal ou la manière dont s’établit la
communication (téléphone, e-mail, etc.)
<Channel>XXXXX</Chan
nel>
R
CompleteNumber
0…1
Code
Numéro complet (téléphone, fax)
<CompleteNumber>05
62 45 45
21</CompleteNumber>
R
URI
0…1
Text
Uniform ressource identifier, adresse internet
<URI>[email protected]</UR R
I>
TransferringAgency. Communication.
ArchivalAgency
Identification
1…1
Identifier
Identifiant unique du service d’archives.
<Identification>FRAD029
</identification>
O
Name
0…1
Text
Dénomination du service d’archives.
<Name>Archives
départementales du
Finistère</Name>
R
R
ArchivalAgency.Contact
PersonName
0…1
Text
Nom de la personne ou du service à contacter
<PersonName>Mme
Dupont</PersonName>
Responsability
0…1
Text
Description textuelle des responsabilités générales ou
spécifiques du contact.
<Responsability>correspo R
ndant archives
électroniques.
Responsable des archives
contemporaines
</Responsability>
ArchivalAgency.Address
BuildingName
0…1
Text
Nom du bâtiment
<BuildingName>Cité
R
administrative</BuildingN
18
ame>
BuildingNumber
0…1
Text
Numéro d’un bâtiment sur la voie à cette adresse
<BuildingNumber>12</B
uildingNumber>
R
CityName
0…1
Text
Localité
<CityName>Quimper</Ci R
tyName>
Country
0…1
Text
Pays
<Country
listVersionID="second
edition 2006" >FR
</Country>
Postcode
0…1
Code
Code postal
<Postcode>29000</postc R
ode>
StreetName
0…1
Text
Nom de la voie
<StreetName>Boulevard
du
Finistère</StreetName>
R
R
ArchivalAgency. Communication.
Channel
0…1
Code
Code spécifiant le canal ou la manière dont s’établit la
communication (téléphone, e-mail, etc.)
<Channel>XXXXXr</Cha
nnel>
R
CompleteNumber
0…1
Code
Numéro complet (téléphone, fax)
<CompleteNumber>05
62 45 45
21</CompleteNumber>
R
URI
0…1
Text
Uniform ressource identifier, adresse internet
<URI>[email protected]</UR R
I>
19
Exemple de message de transfert
20
21
Description du contenu du bordereau de versement
Un bordereau de versement décrit une ou plusieurs Archive, sachant que dans le cas du RMI, on aura généralement qu’une seule Archive dans la mesure où
une <Archive> correspond à un versement de dossiers RMI clos dans un intervalle de dates donné (exemple : une année complète).
Dans la partie <Archive>, on trouvera l’équivalent du sommaire ou du résumé de versement : l’objet et l’intitulé du versement, les dates extrêmes des
données transférées, l’historique du versement, le service producteur, la durée d’utilité administrative des données transférées, leur sort final et leur
communicabilité.
L’ArchiveObject, contenu dans l’Archive, correspond alors :
- soit à un seul fichier global s'il a été fait le choix de générer un export regroupant tous les dossiers (première balise Document), et éventuellement le
fichier xsd pour contrôle (seconde balise Document avec comme type d’information le code ‘RI’ pour « Information de représentation »)
<Archive>
<Document>
Dossiers de RMI clos en 2004
= fichier d’export global
<ArchiveObject>
- soit à un fichier correspondant à un dossier individuel : il y a alors autant d’ArchiveObject que de dossiers archivés. Dans la partie <ArchiveObject>, on
trouvera alors la description de chaque dossier individuel ainsi éventuellement qu’un fichier xml joint, correspondant au contenu de données, si l'on a fait le
choix d'un export XML par dossier. La description de chaque dossier individuel peut être plus ou moins développée. Voici, sous forme de schéma un
exemple illustrant la structure de la partie descriptive d’un bordereau :
<Archive>
Dossiers de RMI clos en 2004
<ArchiveObject>
--- Dossier de l’individu 1
<Document>
<ArchiveObject>
<Document>
Contenu de données du dossier de l’individu 1
--- Dossier de l’individu 2
Contenu de données du dossier de l’individu 1
…
22
En tout état de cause, dans la mesure où il servira de base pour que le service versant puisse assurer le pré-archivage des dossiers papier, chaque dossier
doit être a minima identifié par le n° de bénéficiaire, le nom, le prénom et éventuellement la commission locale d’insertion, suivant le mode d’organisation
des services.
Comme dans les bordereaux papier de versement actuels, toutes les informations figurant dans le bordereau ne seront pas forcément communicables dès le
versement, notamment les noms et prénoms des bénéficiaires : il peut être fait le choix de ne donner qu’une information numérique dans la balise
<Name>, afin d’identifier chaque dossier de bénéficiaire, et de développer la description, notamment avec des informations nominatives dans la balise
<ContentDescription>, dont il est possible de restreindre l’accès aux seuls agents du service d’archives, via la balise <AccessRestriction>.
Le diagramme UML ci-dessous présente la structure et le contenu d’une archive complète et figure dans le standard d’échanges de données pour
l’archivage :
23
24
BBIE (attribut)
Cardinalité
Type
Définition et commentaires
Exemple
Obligatoire(
O) /
Recommand
é ( R)
Archive
ArchivalAgencyArchiveIdentifier
0…1
Identifier
Identifiant de l’archive attribué par le service d’archive.
Pourra être généré automatiquement dans le cadre de
transferts automatisés via une plate-forme d’archive.
<ArchivalAgencyArchiveI R
dentifier>
xxx</ArchivalAgencyArchi
veIdentifier>
ArchivalAgreement
0…1
Identifier
Indique la référence, la date et la version du contrat de
service à appliquer pour les données du RMI. Il a été
établi entre les différents services intervenant dans le
processus d’archivage (service des archives, service
informatique, service territorialisé, service central le cas
échéant – cf données sont saisies au niveau territorial)
<ArchivalAgreement>Con R
trat_xxx</ArchivalAgree
ment>
ArchivalProfile
0…1
Identifier
Précise quel profil du standard d’échange a été utilisé
<ArchiveProfile>Profil_R
MI</ArchiveProfile>
R
DescriptionLanguage
1…1
Code
Langue de description.
<DescriptionLanguage
listVersionID="edition
2009">fr</DescriptionLa
nguage>
O
<DescriptionLevel
listVersionID="edition
2009">subseries</Descri
ptionLevel>
O
O
Elle fait appel à une table incluse dans le standard
d’échange, elle-même compatible avec la norme ISO639-1
DescriptionLevel
1…1
Code
Niveau de description au sens de la norme ISAD(G):
Subseries. (sous-série)
Fait appel à une table incluse dans le standard d’échange.
Name
1…1
Text
Intitulé du contenu d’information.
<Name>Revenu
minimum d’insertion :
dossiers individuels clos
en 2004</Name>
TransferringAgencyArchiveIdentifier
0…1
Identifier
Identifiant de l’archive attribué par le service versant.
<TransferringAgencyArchi R
25
Pourra être généré automatiquement dans le cadre de
transferts automatisés via une plate-forme d’archive.
veIdentifier>
xxx</TransferringAgency
ArchiveIdentifier>
Archive.ContentDescription.
CustodialHistory
Description
Language
0…1
0…1
1…*
Text
On peut indiquer notamment comment s’est effectué le
passage de l’application d’origine au fichier archivable, le
nom, la version, la date du logiciel, l’éditeur du logiciel,
mais aussi les motifs de clôture des dossiers, etc.
<CustodialHistory>L’export R
a été réalisé à partir de la
version X du logiciel
Perceaval. L’outil XX a été
utilisé pour réaliser l’export
et sa mise en conformité
avec le standard
d’échanges. Les données
ont été gravées sur CDRom de type x, par la
Direction des systèmes de
l’information, avec le
graveur
y</CustodialHistory>
Text
Permet de donner des précisions sur le contenu de
<Description>Manuel des
l'Archive. Par exemple, qualifier et dater les reprises de
procédures RMI – mai
données (avec ou sans historique du parcours de l’individu, 2005. Se reporter au
etc.), indiquer l’existence d’une charte de saisie des
tableau de taux de
données, etc.
remplissage des
champs</Description>
Code
Langue du contenu de l’objet.
R
O
Fait appel à une table incluse dans le standard d’échange
<LanguageName
listVersionID="edition
2009">fr</LanguageName
>
LatestDate
0…1
Date
Date de fin du contenu : date sortie du dispositif la plus
récente
<LatestDate>2009-0121</LatestDate>
R
OldestDate
0…1
Date
Date de début du contenu : date de début d’ouverture des <OldestDate>2004-01droits la plus ancienne.
21</OldestDate>
R
Size
0…*
MeasureType
Taille de l’objet en octets, nombre d’enregistrements
R
<Size
unitCode= "AD">678</Siz
26
e>
<Size
unitCode=”NAR”>2800</si
ze>
Les codes d’unités doivent
être conformes à la table
de code
UNECE_MeasurementUnitC
ommonCode_5.xsd
Archive.Contentdescription.OriginatingAgency.
Identification
1…1
Identifier
Identifiant unique du service producteur des données.
<Identification>86</iden O
tification>
Name
0…1
Text
Dénomination du producteur.
<Name>Direction de
l’insertion et de la lutte
contre les
exclusions</Name>
R
Archive. ContentDescription.ContentDescriptive.
Les mot-clés retenus pour la partie Archive sont :
- insertion professionnelle
- insertion sociale
- aide sociale
Il faut être au maximum conforme au thésaurus W dans la valeur du mot-clé. Si certains services d'Archives utilisent un thésaurus interne, il faut le préciser et définir la valeur des
mots-clés dans le contrat de service.
Il existe autant d’éléments ContentDescriptive qu’il y a de mots-clés.
KeywordContent
1…1
Text
Valeur du mot-clé
<KeywordContent>inserti O
on
sociale</KeywordContent
>
KeywordReference
0…1
Code
Référence du thésaurus interne ou thésaurus 2009
<KeywordReference
schemeName
="Thesaurus pour la
description et l'indexation
des archives locales
27
R
anciennes, modernes et
contemporaines, 4e
édition, 2009 de la
Direction des Archives de
France">http://www.arch
ivesdefrance.culture.gouv
.fr/thesaurus/resource/T1
987</KeywordReference
>
KeywordType
0…1
Code
Type de mot-clé : les termes d’indexation référencés sont
aussi précis que possible ; pour tous ici : subject.
<KeywordType
R
listVersionID="edition
2009">subject</Keyword
Type>
Archive. Appraisal.
- Code
1…1
Code
Sort final de l’archive à l’issue de la durée d’utilité
administrative.
- Duration
1…1
Duration=Property Indique la durée à appliquer
Term
- StartDate
1…1
StartDate
La date de départ correspond toujours au 31 décembre de
la date de clôture des dossiers (LatestDate).
<Appraisal>
O
<Code
listVersionID="edition
2009">conserver</Code
>
O
<Duration
listVersionID= "edition20
09">P2Y</Duration>
<StartDate>2009-1231</StartDate>
O
</Appraisal>
Archive.AccessRestriction.
- Code
- StartDate
1…1
1…1
Code
Date
Restriction d’accès / communicabilité, soit 50 ans après
clôture du dossier (ou 120 ans à compter de la date de
naissance ou 25 ans à compter de la date de décès si des
renseignements à caractère médical sont saisis dans les
applications). Cet attribut s’applique à l’ensemble des
documents de l’Archive (c’est-à-dire à tous les dossiers
individuels clos en 2008).
<AccessRestriction>
O
<Code>
listVersionID="edition
2009"> AR048</Code>
O
<StartDate>2009-1231</StartDate>
</AccesRestriction>
28
La date de départ correspond toujours au 31 décembre de
la date de clôture des dossiers (LatestDate).
Archive.Document
Attachment
Description
Type
1…1
0…1
1…1
BinaryObject :
Pièce-jointe ou annexée.
format, mimecode (selon option d'export retenue)
et filename
Plusieurs options se présentent à l’éditeur : générer un
fichier XML par individu (dans ce cas, les rattacher à
ArchiveObject) ou un fichier XML regroupant tous les
dossiers individuels clos une année N par exemple. Ces
fichiers peuvent être placés à part comme fichiers joints et
désignés par un simple lien. Ce point est à négocier lors de
la mise au point des exports.
<Attachement_format= O
" fmt/101"
mimeCode="text/xml"
filename="Nomdufichier
"/>
Text
Description du document
<Description>Fichier XML R
contenant l'export des
données RMI de
l'ensemble des
bénéficiaires</Description
>
Code
Type de document
<Type
listVersionID="edition
2009">CDO</Type>
O
ArchiveObject
DescriptionLevel
1…1
Code
Niveau de description : dossier.
<DescriptionLevel
listVersionID="edition
2009">file</descriptionle
vel>
O
Name
1…1
Text
Intitulé du contenu d’information, tel qu’il apparaît dans le
logiciel : il équivaut au numéro de l’individu attribué par le
progiciel.
<Name>n°131</Name>
O
ArchiveObject. Content description
(facultatif : à retenir pour faciliter les recherches et la restitution aux usagers une fois le délai de communicabilité expiré)
Description
0…1
Text
Permet de fournir des précisions sur l’objet versé.
Cette description comportera les informations suivantes :
nom, prénom, date de naissance de l’individu, n° de
<description> Durand,
Paul, 1970-0224</description>
R
29
dossier
AccessRestriction
1…1
Code
Date
Language
1…*
Code
Permet d’indiquer que la description n’est pas
communicable pendant 50 ans après clôture du dossier (ou
120 ans à compter de la date de naissance ou 25 ans à
compter de la date de décès si des renseignements à
caractère médical sont saisis dans les applications).
La date de départ correspond toujours au 31 décembre de
la date de clôture des dossiers (LatestDate).
<AccessRestrictionCode>
AR048</AccessRestrictio
nCode>
Langage du contenu de l’objet
<LanguageName
O
listVersionID="edition
2009">fr</LanguageNam
e>
Fait appel à une table incluse dans le standard d’échange
Size (suivant option d’export retenue)
0…*
MeasureType
Indique la taille de l’objet en octet (pertinent à ce niveau
seulement si un fichier XML a été généré pour chaque
dossier càd un ArchiveObject.Document par dossier)
O
<StartDate>2009-1231</StardDate>
<Size
unitCode= "AD">8</size
>
R
Les codes d’unités
doivent être conformes à
la table de code
UNECE_MeasurementUnit
CommonCode_5.xsd
ArchiveObject.Document.
(suivant option d’export retenue ; ici = cas de génération d’un fichier xml par individu)
Attachment
1…1
BinaryObject :
Pièce-jointe ou annexée.
format, mimecode (selon option d'export retenue)
et filename
Plusieurs options se présentent à l’éditeur : générer un
fichier XML par individu ou un fichier XML regroupant tous
les dossiers individuels clos une année N par exemple. Ces
fichiers peuvent être placés à part comme fichiers joints et
désignés par un simple lien. Ce point est à négocier lors de
la mise au point des exports.
<Attachement_format="f O
mt/101
"mimeCode="text/xml"
filename="Nomdufichier"/
>
Description
0…1
Text
<Description>Fichier XML R
contenant l'export des
données RMI d'un
bénéficiaire</Description
Description du document
30
>
Type
1…1
Code
Type de document
<Type
listVersionID="edition
2009">CDO</Type>
O
31
Exemple de contenu de bordereau :
32
33
5.3
Forme du contenu de données
La structure XML du contenu de données est différente suivant les progiciels des éditeurs : il convient de l’adapter à chaque progiciel, à partir de la sélection
des données présentées ci-dessus (soit travail avec l’éditeur, soit travail en lien avec la Direction des systèmes d’information).
Exemple:
34
35
...
36
6
Données à éliminer
6.1
Nature des données à détruire
Il s’agit des données non retenues pour la conservation définitive. Cela concerne :
- les données issues des champs qui n’auront pas été retenus pour le versement,
- les dossiers non versés dans le cas où le service d’archives territorialement compétent décide de ne conserver qu’un échantillon de ces dossiers,
- les dossiers rejetés.
Comme pour le papier, les bordereaux d’élimination de données numériques doivent être le plus synthétique possible.
Structure de la description
Niveau 1 (<Archive>)
Niveau 2
(<ArchiveObject>)
RMI, dossiers clos les
années 0 et 5 : données
non transférées aux
Archives
4
départementales
Sans objet
RMI : dossiers clos les
autres années que les
années 0 et 5
Sans objet
Métadonnées
Contenu de données
Information de pérennisation et
de description
Information de
représentation
Date de début : date d’ouverture
des droits par l’organisme payeur
Sans objet
Sans objet
Sans objet
Sans objet
Date de fin : date de clôture des
droits
Date de début : date d’ouverture
des droits par l’organisme payeur
Date de fin : date de clôture des
droits
4 La liste des champs non retenus pour la conservation définitive ne sera pas établie de manière exhaustive ; il s’agira, par défaut, de tous les champs ne
faisant pas partie de la liste des données à transférer.
37
L’éditeur devra par ailleurs assurer la suppression logique et physique des doubles des données transférées aux Archives départementales, une fois la DUA
écoulée et le versement au service d’archives validé. Il n’est nul besoin de générer un bordereau d’élimination pour cela.
6.2
Bordereaux d’élimination
Concernant la structure et le contenu du bordereau d’élimination, il convient de se reporter au schéma UML publiés par la DGME et la DAF dans le standard
d’échanges de données pour l’archivage (chapitres 3.6.10).
38
Message de transfert : en-tête du bordereau d’élimination
BBIE (attribut)
Cardinalité
Type
Comment
0…1
Text
Date
1…1
DateTime
Définition et commentaires
ArchiveDestructionRequest
Commentaires sur le transfert
Date du transfert
Exemple
Obligatoire(
O) /
Recommand
é ( R)
<Comment>Demande de
destruction de données
RMI : dossiers clos
2005</Comment>
R
Date au format ISO 8601
O
<Date>aaaa-mmjjThh:mm:ssZ</Date>
DestructionRequestIdentifier
1…1
Identifier
Identifiant de la demande de destruction ou de la
demande d’autorisation de destruction (dans l’exemple
donné, 2ème demande d’élimination formulée par la
direction de l’insertion en 2008)
<TransferIdentifier
O
SchemeAgencyName="Dir
ection de
l’insertion">2008-0002
</TransferIdentifier>
HashCode (sans objet)
Signature (sans objet)
39
BBIE (attribut)
Cardinalité
Type
Définition et commentaires
Exemple
Obligatoire
(O) /
Recommand
é ( R)
<TransferingAgency>
O
OriginatingAgency
Identification
1…1
Identifier
Identifiant unique du service versant.
<Identification>86</iden
tification>
Name
0…1
Text
Dénomination du service versant.
Nom sous lequel l’organisation exerce son activité
<Name>Direction de
l’insertion et de la lutte
contre les
exclusions</Name>
R
OriginatingAgency.Contact
PersonName
0…1
Text
Nom de la personne ou du service à contacter
<PersonName>M.
Dupont</PersonName>
R
Responsability
0…1
Text
Description textuelle des responsabilités générales ou
spécifiques du contact.
<Responsability>Corresp
ondant archives. Chef de
service</Responsability>
R
OriginatingAgency.Address
BuildingName
0…1
Text
Nom du bâtiment
<BuildingName>Cité
R
administrative</BuildingN
ame>
BuildingNumber
0…1
Text
Numéro d’un bâtiment sur la voie à cette adresse
<BuildingNumber>12</B
uildingNumber>
CityName
0…1
Text
Localité
<CityName>Quimper</Ci R
tyName>
Country
0…1
Text
Pays
<Country
listVersionID="second
edition 2006"
>FR</Country>
R
R
40
Postcode
0…1
Code
Code postal
<Poscode>29000</postc
ode>
R
StreetName
0…1
Text
Nom de la voie
<StreetName>Boulevard
du
Finistère</StreetName>
R
OriginatingAgency. Communication.
Channel
0…1
Code
Code spécifiant le canal ou la manière dont s’établit la
communication (téléphone, e-mail, etc.)
<Channel>XXXXX</Chan
nel>
R
CompleteNumber
0…1
Code
Numéro complet (téléphone, fax)
<CompleteNumber>05
62 45 45
21</CompleteNumber>
R
URI
0…1
Text
Uniform ressource identifier, adresse internet
<URI>[email protected]</UR R
I>
ArchivalAgency
Identification
1…1
Identifier
Identifiant unique du service d’archives.
<Identification>FRAD029
</identification>
O
Name
0…1
Text
Dénomination du service d’archives.
<Name>Archives
départementales du
Finistère</Name>
R
R
ArchivalAgency.Contact
PersonName
0…1
Text
Nom de la personne ou du service à contacter
<PersonName>Mme
Dupont</PersonName>
Responsability
0…1
Text
Description textuelle des responsabilités générales ou
spécifiques du contact.
<Responsability>correspo R
ndant archives
électroniques.
Responsable des archives
contemporaines
</Responsability>
BuildingName
0…1
Text
ArchivalAgency.Address
Nom du bâtiment
<BuildingName>Cité
R
administrative</BuildingN
ame>
41
BuildingNumber
0…1
Text
Numéro d’un bâtiment sur la voie à cette adresse
<BuildingNumber>12</B
uildingNumber>
R
CityName
0…1
Text
Localité
<CityName>Quimper</Ci R
tyName>
Country
0…1
Text
Pays
<Country
listVersionID="second
edition 2006" >FR
</Country>
Postcode
0…1
Code
Code postal
<Postcode>29000</postc R
ode>
StreetName
0…1
Text
Nom de la voie
<StreetName>Boulevard
du
Finistère</StreetName>
R
R
ArchivalAgency. Communication.
Channel
0…1
Code
Code spécifiant le canal ou la manière dont s’établit la
communication (téléphone, e-mail, etc.)
<Channel>XXXXXr</Cha
nnel>
R
CompleteNumber
0…1
Code
Numéro complet (téléphone, fax)
<CompleteNumber>05
62 45 45
21</CompleteNumber>
R
URI
0…1
Text
Uniform ressource identifier, adresse internet
<URI>[email protected]</UR R
I>
42
Contenu des bordereaux d’élimination
Métadonnées de pérennisation pour l’élimination de données et de dossiers non transférés :
BBIE (attribut)
Cardinalité
Type
Définition et commentaires
Exemple
Obligatoire (O)
Facultatif (F)
Recommandé ( R)
Archive
Indique la référence, la date et la version du contrat de
service à appliquer pour les données du RMI. Il a été
établi entre les différents services intervenant dans le
processus d’archivage (service des archives, service
informatique, service territorialisé, service central le cas
échéant – cf. données sont saisies au niveau territorial)
ArchivalAgreement
0…1
Identifier
ArchivalProfile
0…1
Identifier
Précise quel profil du standard d'échange a été utilisé
<ArchivalProfile>Profil_R R
MI</ArchivalProfile>
DescriptionLanguag 1…1
e
Code
Langue de description.
<DescriptionLanguage
O
listVersionID="edition
2009">fr</DescriptionLa
nguage>
DescriptionLevel
1…1
Code
Name
1…1
Text
Elle fait appel à une table incluse dans le standard
d’échange, elle-même compatible avec la norme ISO639-2
Niveau de description : ici, subseries (sous-série)
Intitulé du contenu d’information :
- cas de données non transférées
- cas de dossiers non transférés
<ArchivalAgreement>Co
ntrat_xxx</ArchivalAgre
ement>
R
<DescriptionLevel
O
listVersionID="edition
2009">subseries</Descri
ptionLevel>
<Name>RMI : dossiers
clos en 2005, données
non
transférées</Name>
O
<Name>RMI : dossiers
clos en 2002</Name>
Archive.Contentdescription
CustodialHistory
0…1
Text
On peut indiquer notamment la façon dont s’est déroulée
l’élimination.
<CustodialHistory>Les
dossiers à exporter ont
été marqués dans la
43
base ; un export des
données à verser,
conforme au standard
d’échanges de données a
été réalisé, à partir du
module d’export x ; le
reste des données a été
éliminé dans la base de
données de production
avec le logiciel
Perceaval.</CustodialHis
tory>
Description
0…1
Text
- cas de données non transférées : donner la liste des
dossiers dans lesquels des données n'ont pas été retenues
(faire référence au bordereau de versement de données
correspondant par exemple)
- cas de dossiers non transférés : donner la liste des
dossiers concernés par la destruction, ainsi que des
éléments de description permettant aux services de gérer
leur pré-archivage papier
Language
1…*
Code
Langue du contenu de l’objet.
Fait appel à une table incluse dans le standard d’échange.
<Description>Les
données détruites
correspondent aux
données non retenues
pour les dossiers versés
sous la cote 1590
W</Description>
<Description>n°1551,
Durand, Paul, né le
19651025, CLLE
Audierne ; n°1360, Doe,
John, nél e 19680525,
CLLE
Pleyben…</Description>
<LanguageName
listVersionID="edition
2009">fr</LanguageNa
me>
LatestDate
0…1
Date
Date d’ouverture des droits la plus ancienne
<LatestDate>2005-0601</LatestDate>
OldestDate
0…1
Date
Date de clôture des droits la plus récente
<OldestDate>1996-0225</OldestDate>
44
Size
0…*
Measure
Taille en Mo de ce qui doit être éliminé.
<Size
unitCode= "4L">700</Si
ze>
Les codes d’unités
doivent être conformes à
la table de code
UNECE_MeasurementUni
tCommonCode_5.xsd
45
Annexe 1: Tableau comparatif des procédures RMI des départements du Finistère, de la Haute-Garonne et de l’Eure
Procédure/action
Finistère
Haute-Garonne
Eure
Demande d’allocation auprès d’un service
instructeur [SI] = Centre communal d’action
sociale, service territorial du CG (centre
médico-social par exemple), association sous
convention
accueil du demandeur, prévérification des droits, rédaction
du dossier
accueil du demandeur, rédaction du
dossier
Accueil du demandeur,
rédaction du dossier par le SI ; le
dossier de demande part vers
l'OP, une copie reste en SI, une
autre envoyée en Mission de lutte
contre les exclusions [MLCE].
pré-vérification des droits par la
Caisse d’allocation familiale [CAF]
désignation d’un référent par la
direction de l’insertion
la MLCE effectue la saisie de la
46
Procédure/action
Finistère
Haute-Garonne
Eure
demande dans IODAS.
Ouverture des droits
décision par l’organisme
payeur [OP] = CAF ou Mutuelle
sociale agricole [MSA]
OP enregistre le dossier dans
son système d’information et
émet mensuellement un fichier
de situation des droits
allocataires : le comparatif de ce
fichier avec Perceaval permet la
détection des nouveaux
allocataires
décision par le CG
OP enregistre le dossier dans son
système d’information, et transmets,
sur disquette, une partie des
informations au CG pour alimentation
d’Anis
Décision par l'OP, qui saisit la
demande dans son propre
système d'information, puis
envoie une notification
d'ouverture de droit au CG et au
SI.
Mise à jour ouverture de droit
dans IODAS à la MLCE.
"contrat administratif"5 .
état mensuel CAF transmis par
une interface informatique à la
Direction des systèmes
d’information [DSI] qui alimente
IODAS (mise à jour des
montants, de l'état de droit,
correction d'anomalies) ; la DSI
transmet aux UTAS les
informations sur les corrections
d'anomalies (fichier Excel).
Commission locale de lutte
contre les exclusions [CLLE]
transmet l’information au
responsable d’équipe ; celui-ci
affecte un référent ; édition et
envoi d’un courrier d’accueil à
l’allocataire, désignant le
référent
désignation du référent en
MLCE 6.
Elaboration du contrat d’insertion
référent : évaluation situation
globale allocataire, identification
référent : évaluation situation
globale allocataire, identification des
référent : évaluation situation
globale allocataire, identification
5 Etape propre à l'UTAS d'Evreux : après ouverture des droits, le demandeur reçoit une convocation à une réunion d'information collective, à l'issue de
laquelle est signé un "contrat administratif" ; ce contrat intermédiaire est destiné, dans l'attente de nomination du référent, à assurer notamment la
couverture des droits CMU du demandeur. En cas de non-réponse à trois convocations successives à la réunion d'information collective, l'allocataire reçoit
une convocation pour un entretien individuel : en cas d'absence, la suspension de l'allocation est demandée.
6 Pour la MLCE d'Evreux, désignation du référent dans une Commission d'Orientation : pas de trace papier (sauf le courrier de désignation), seulement un
suivi bureautique (Excel).
47
Procédure/action
Finistère
Haute-Garonne
Eure
des besoins, rédaction du projet
de contrat, rédaction fiche
statistique
référent emploi (personnel
ANPE) : reçoit l’allocataire, rentre
ses préconisations dans le logiciel
besoins, rédaction du projet de contrat,
rédaction fiche statistique
des besoins, rédaction du projet
de contrat, rédaction fiche
statistique.
Validation du contrat en
Commission de Validation des
Contrats et Bourses d'Insertion
validation du contrat
validation du contrat : passage
en instance technique et en
commission restreinte de la CLLE
Suspension des droits naturelle ou à la suite
d’une décision d’opportunité
_sur impulsion de la CLLE (non
validation du contrat d’insertion
par exemple)
en cas de non application ou
non signature, le SI signale à la
MLCE.
référent : information de la
CLLE
la commission locale
d’insertion se réunit à l'UTAS et
donne un avis motivé sur la
suspension :
CLLE : examen en commission
restreinte
cellule RMI (direction), au vu
du courrier et de la proposition
de suspension, examen de la
demande de suspension ; si
accord, courrier à l’OP et à
l’allocataire pour l’informer de ses
droits
la MLCE informe la Direction
Lutte Contre les Exclusions
(direction centrale) qui propose la
suspension et prépare l'arrêté du
PCG
_sur impulsion de l’organisme
payeur (en fonction de la
déclaration trimestrielle de
ressources, problème de
résidence administrative, obstacle
à contrôle…)
L'OP peut interrompre le droit,
mais pas le suspendre (la
suspension ne peut être
déléguée, droit propre au
président) : dans les faits
l'allocation cesse d'être versée
mais l'OP informe le CG pour que
interface
le PCG signe l'arrêté de
suspension, et en informe l'OP.
48
Procédure/action
Finistère
Haute-Garonne
Eure
la procédure de suspension soit
initiée.
Sortie du dispositif (les radiations interviennent
automatiquement 4 mois après la suspension
des droits ; cas de radiations directes : fraude,
bénéfice à tort, contrôle CAF…)
CLLE : détection, via le logiciel,
des dossiers à radier, liste des
radiations validées, et
transmission à l’OP
OP : courrier de radiation à
l’allocataire
Notification fin droit par l'OP.
OP : interface, intégration
automatique des radiations dans
le logiciel ; courrier de radiation à
l’allocataire
49