A P P L I C A T I O N A. C. T. E. S. : A I D E A U C O N T R O L E D E L E G A L I T E D E M A T E R I A L I S E

Transcription

1 DIRECTION GENERALE DES COLLECTIVITES LOCALES SOUS DIRECTION DES COMPETENCES ET DES INSTITUTIONS LOCALES DIRECTION DES SYSTEMES D INFORMATION ET DE COMMUNICATION SOUS DIRECTION DES ETUDES ET DES LOGICIELS Bureau des projets de l administration centrale et des SGAP Place Beauvau Paris cedex 08 A P P L I C A T I O N A. C. T. E. S. : A I D E A U C O N T R O L E D E L E G A L I T E D E M A T E R I A L I S E NORME D ECHANGE ENTRE LES COLLECTIVITES LOCALES ET LE MINISTERE DE L INTERIEUR, DE LA SECURITE INTERIEURE, ET DES LIBERTES LOCALES Version 1.3 du 03 mai 2004 Le présent document comporte 19 feuillets numérotés de 2 à 19

2 SOMMAIRE SOMMAIRE...2 SUIVI DES VERSIONS CONTEXTE Le contrôle de légalité Le projet «ACTES» Répartition en domaines Norme d échange FLUX DE DONNEES ORGANISATION DES FICHIERS TRANSMIS FORMAT DES DOCUMENTS JOINTS Précisions sur les formats utilisés Nommage des fichiers échangés PROTOCOLES UTILISES Des collectivités vers le ministère Du ministère vers les collectivités SECURISATION Principes Dispositifs mis en place Eléments fournis pour l ouverture des échanges MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 2

3 SUIVI DES VERSIONS Numéro Date Motif de mise à jour octobre 2003 Création du document janvier 2004 Finalisation et notification aux acteurs de la sphère «collectivités locales» avril 2004 Correction sur le nommage des fichiers concernant les mises à jour de la classification des actes mai 2004 Correction d une incohérence dans le nommage des fichiers (caractère précédent le numéro d ordre) MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 3

4 0 CONTEXTE 0.1 LE CONTROLE DE LEGALITE Le contrôle de légalité est prévu par l article 72 de la Constitution. Il porte sur les actes créés par les trois niveaux de collectivités territoriales (communes, départements, régions) et leurs établissements publics et notamment les établissements publics de coopération intercommunale. Il est effectué, selon la localisation et la nature des collectivités, par des agents spécialisés dans les préfectures, les sous-préfectures, et les SGAR (Secrétariat Général de l Administration Régionale), soit environ 350 sites en France. Les collectivités transmettent leurs actes en préfecture (ou sous-préfecture ou SGAR), afin que les agents du ministère puissent vérifier qu ils sont conformes au droit. Si des actes sont incomplets, non conformes au droit, ou s il y a doute sur la portée de l acte un dialogue s organise entre le représentant de l Etat et la collectivité se traduisant par exemple par des demandes de pièces complémentaires, lettres d observation, et se concluant éventuellement par un déféré devant le juge administratif. Les actes budgétaires nécessitent, le cas échant l intervention de la Chambre régionale des comptes saisie par le représentant de l Etat. Ces procédures s inscrivent dans des délais précis, fixés par la loi. 0.2 LE PROJET «ACTES» Dans le cadre de l évolution et de la modernisation des rapports entre l Etat et les collectivités locales et de la réforme de l Etat, le ministère de l intérieur, de la sécurité intérieure et des libertés locales a lancé, depuis le premier semestre 2001, une démarche d étude, d expérimentation et de prototypage de la transmission sous forme numérique des actes des collectivités locales soumis au contrôle de légalité du préfet, sur quelques sites pilotes. Le retour d expérience sur ces travaux a permis de définir le contour et les fonctionnalités d un projet baptisé «ACTES» (Aide au Contrôle de légalité dématerialisé), dont les objectifs sont : - L allégement des tâches matérielles de rédaction, de reproduction, d expédition et de conservation des actes. - La rationalisation des tâches de contrôle par l automatisation des tâches répétitives d enregistrement et de délivrance des accusés de réception, le calcul automatique des délais de recours et la mise en œuvre de dispositifs d alerte signalant les échéances des délais de recours. - Un renforcement de la capacité d expertise des actes, une détection plus efficace des illégalités, et un meilleur service rendu aux collectivités en termes de sécurité juridique des actes et de conseil aux élus - Une vue plus synthétique du contrôle de légalité permettant un meilleur pilotage national et local de cette fonction régalienne exercée par les représentants de l Etat. MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 4

5 Ce projet doit déboucher sur la mise en place en 2004, dans quelques départements, d une première version d un système permettant l échange dématérialisé, entre les collectivités locales et les préfectures, des actes et des courriers relatifs à ces actes. A partir de 2005, le système sera progressivement diffusé dans les autres départements. 0.3 REPARTITION EN DOMAINES Le futur système associera d une part le ministère de l intérieur, d autre part les collectivités locales. Les représentants des deux parties se sont entendus sur une division de l architecture en deux sphères, chacun étant responsable de la mise en place de l infrastructure et des composants applicatifs dans sa sphère. Une norme d échange est définie pour formaliser les modalités de transfert d information entre les deux sphères Sphère Collectivité Sphère MI Une fois arrivés sur les serveurs du ministère, les actes sont acheminés vers le représentant de l Etat territorialement compétent pour chaque collectivité. Il a également été décidé que les collectivités ne communiqueraient pas directement avec le ministère de l intérieur, mais utiliseraient des opérateurs, baptisés «tiers de confiance»,comme intermédiaires pour déposer les actes et recevoir les informations renvoyées par le ministère. Les tiers de confiance pourraient être soit des opérateurs privés (ou un ensemble d opérateurs privés), soit de grosses collectivités jouant le rôle de tiers de confiance pour elles-mêmes voire pour d autres collectivités. Par extension, dans toute la suite de cette norme, on désignera par «tiers de confiance» aussi bien les tiers opérateurs privés que les collectivités raccordement directement, qu elles envoient des actes seulement pour elles-mêmes ou également pour le compte d autres collectivités. MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 5

6 0.4 NORME D ECHANGE Les composantes de la norme d échange, objet du présent document et définie par le ministère, sont les suivantes : - Formulaires signalétiques décrivant les données métier échangées dans les flux d information, et qui seront interprétées par les systèmes automatisés. - La nature et l organisation des fichiers télétransmis. A cette partie sont joints en annexe les schémas XML qui sont la traduction technique des formulaires signalétiques décrits plus haut. - La spécification du format des fichiers transmis (nommage des fichiers, et formats utilisés pour les pièces jointes aux fichiers XML). - Les protocoles d échange qui seront utilisés pour la transmission des fichiers échangés. - Les modalités de sécurisation du système. MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 6

7 1 FLUX DE DONNEES Les échanges de données entre les collectivités locales le ministère de l intérieur, de la sécurité intérieure et des libertés locales sont identifiés et répartis dans plusieurs «transactions», chaque transaction se décomposant en plusieurs «messages» se faisant suite. Le document «formulaires signalétiques» (annexé aux schémas XML publiés dans le référentiel de l ADAE : détaille l ensemble des transactions, des messages les composant, et pour chacun des messages précise le «formulaire signalétique», c est à dire la liste des données devant être présentes dans chaque message. MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 7

8 2 ORGANISATION DES FICHIERS TRANSMIS Les données structurées identifiées dans les formulaires signalétiques sont modélisées dans des fichiers XML, devant respecter plusieurs schémas XML. Les schémas XML et des exemples de fichiers XML sont disponibles sur le référentiel des schémas XML de l administration, sur le site de l ADAE : Conformément à ce qui est décrit dans les formulaires signalétiques, un envoi sera décrit dans un fichier «enveloppe», qui est modélisé en XML. Ce fichier enveloppe pointe vers les fichiers XML modélisant les «messages métier» (par exemple : transmission d un acte, réponse à une lettre d observations ). Ces fichiers XML pointent eux-mêmes vers les «documents joints» aux «messages métier» (par exemple : actes et leurs annexes, lettres de demandes de pièces complémentaires). Enfin, uniquement dans le cas des flux d information des collectivités vers le ministère, un fichier XML «enveloppe» et tous les autres fichiers XML et documents joints en dépendant, doivent être regroupés dans un fichier compressé au format.tar.gz. La structure des fichiers transmis pour un envoi (ici un exemple fictif) peut être représentée ainsi (les flèches doivent être interprétées ainsi : le nom du fichier indiqué par la flèche est contenu dans le fichier d où part la flèche) : Fichier compressé.tar.gz (uniquement pour les flux arrivant au MISILL) Fichier XML «enveloppe» Fichier XML «réponse lettre d observation» (flux 4.4) Fichier XML «transmission acte A» (flux 1.1) Fichier XML «annulation de transmission d un acte» (flux 6.1) Fichier XML «transmission acte B» (flux 1.1) Document PDF «Lettre de réponse à la lettre d observation» Document PDF «Acte B» Document PDF «Acte A» Document JPG «Plan joint à l acte A» MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 8

9 3 FORMAT DES DOCUMENTS JOINTS 3.1 PRECISIONS SUR LES FORMATS UTILISES DONNEES STRUCTUREES : XML Le format XML est le format utilisé pour modéliser toutes les données structurées échangées (enveloppes et messages métier). La version du langage XML utilisée est la version 1.0. Le jeu de caractère utilisé est ISO , afin de permettre l utilisation de caractères accentués DOCUMENTS JOINTS : PDF, JPG, PNG Pour les pièces jointes, les formats PDF (version au moins 3.0 mais devant pouvoir être lu par Acrobat Reader version 5) pour les fichiers textes, et JPG et PNG pour les images seront utilisés. Toute transmission accompagnée de pièces jointes sous d autres formats ne sera pas prise en compte, et fera l objet d un message d anomalie en retour. A terme, le format PDF pour les documents joints pourra être supplanté par le XML, lorsque les technologies de modélisation de documents en XML seront suffisamment matures, accessibles et diffusées FICHIERS COMPRESSES : TAR.GZ Les fichiers télétransmis par les collectivités et devant être traités conjointement (c est à dire le fichier XML «enveloppes» et tous les autres fichiers, XML et pièces jointes, qui en dépendent) devront être regroupés dans un fichier unique compressés au format.tar.gz. Ce dispositif ne concerne pas les envois de fichiers du ministère vers la sphère collectivités locales. 3.2 NOMMAGE DES FICHIERS ECHANGES REGLES DE NOMMAGE DES FICHIERS XML «ENVELOPPES» REGLES GENERALES Les fichiers XML «enveloppes» échangés entre les deux sphères seront nommés selon la norme suivante : APPLI-INFO_APPLI-EMETTEUR DATE NUMERO.xml MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 9

10 Identifiant de l application sous la forme FAAA, où : - F est le type d échange sur une lettre (F : formation, APPLI Q : qualification, E : exploitation, T : test, D : 4 caractères, obligatoire développement) - AAA est un code identifiant de l application INFO_APPLI Informations utiles dans le cadre de l application 0 à? caractères, facultatif EMETTEUR Identifiant de l émetteur 0 à? caractères, facultatif DESTINATAIRE Identifiant du destinataire 0 à? caractères, facultatif DATE date de l'envoi sous format AAAAMMJJ 8 chiffres, obligatoire NUMERO Numéro séquentiel (remis à zéro chaque jour) 1 à 4 caractères, obligatoire Pour les champs dont la présence est optionnelle (INFO_APPLI, EMETTEUR et DESTINATAIRE), leur absence sera repérable par la présence des séparateurs "-" qui sont quant à eux obligatoires. Ce système assure que deux fichiers «enveloppe» ne porteront jamais le même nom. Il est de la responsabilité des émetteurs de respecter ces conventions, en particulier d incrémenter systématiquement le numéro d envoi séquentiel, qui permet de distinguer les courriers envoyés par un même émetteur à une même date FICHIERS ENVELOPPES EMIS PAR LES COLLECTIVITES Les fichiers XML «enveloppes» véhiculant des données depuis la «sphère collectivités» vers la «sphère intérieur» seront nommés de la façon suivante (qui est une déclinaison des règles générales énoncées plus haut) : EACT--SIREN--DATE-NUMERO.xml APPLI EACT Identifiant de l application «contrôle de légalité» 4 caractères INFOS_APPLI 0 caractère EMETTEUR SIREN Numéro SIREN de la collectivité émettrice 9 chiffres DESTINATAIRE 0 caractère DATE DATE date de l'envoi sous format AAAAMMJJ 8 chiffres NUMERO NUMERO Numéro séquentiel (remis à zéro chaque jour) 1 à 4 caractères Exemples : EACT xml Envoi n 1 du 31/12/2002 L application EACT Emetteur (SIREN collectivité) La date de l envoi Numéro d envoi séquentiel 1 EACT xml Envoi n 2 du 31/12/2002 L application EACT Emetteur (SIREN collectivité) La date de l envoi Numéro d envoi séquentiel 2 MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 10

11 FICHIERS ENVELOPPES EMIS PAR LE MINISTERE Les fichiers XML «enveloppes» véhiculant des données depuis la «sphère intérieur» vers la «sphère collectivités» seront nommés de la façon suivante (qui est une déclinaison des règles générales énoncées plus haut) : EACT--SERVICE-SIREN-DATE-NUMERO.xml APPLI EACT Identifiant de l application «contrôle de légalité» 4 caractères INFOS_APPLI 0 caractère EMETTEUR Service en charge du contrôle de légalité des actes SERVICE 9 caractères concernés : cf. liste plus loin. Numéro SIREN de la collectivité concernée par les DESTINATAIRE SIREN 9 caractères courriers. DATE DATE date de l'envoi sous format AAAAMMJJ 8 chiffres NUMERO NUMERO Numéro séquentiel (remis à zéro chaque jour) 1 à 4 caractères Codification du service exerçant le contrôle de légalité : Pour les préfectures : PREFNNN (7 caractères) Pour les sous-préfectures : SPREFNNNM (9 caractères) Pour les SGAR : SGARNNN (7 caractères) Avec : - NNN : numéro sur 3 caractères du département - M : numéro sur un chiffre de l arrondissement Pour constituer les identifiants de départements et arrondissements, on se référera au COG (code officiel géographique) 2003 ( Pour les départements dont le numéro comporte deux caractères sur le COG, on rajoutera un zéro avant le code du COG. On obtient donc, à titre d exemple : 001 Ain 002 Aisne 02A Corse du sud 02B Haute Corse 095 Val d Oise 971 Guadeloupe Pour les arrondissements, en prenant le département 19 comme exemple : 1 Brive-la-Gaillarde 2 Tulle 3 Ussel Exemples : EACT--PREF xml L application EACT Collectivité destinataire (SIREN) Service exerçant le contrôle Préfecture du Nord La date de l envoi Numéro d envoi séquentiel 1 MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 11

12 EACT--SPREF xml L application EACT Emetteur (SIREN collectivité) Service exerçant le contrôle Sous-préfecture de Lodève La date de l envoi Numéro d envoi séquentiel FICHIERS DE MESSAGES D ANOMALIE SUR LES «ENVELOPPES» Le nommage des fichiers XML, envoyés par le MISILL lorsque ce dernier reçoit une transmission pour laquelle le fichier XML «enveloppe» contient des anomalies, portera le même nom que le fichier XML enveloppe, avec comme préfixe «ANO_». Par exemple, si le MISILL reçoit un fichier «enveloppe» nommée : EACT xml et que ce fichier comporte des anomalies, le fichier XML renvoyé par le MISILL suite à cette anomalie sera nommé : ANO_ EACT xml REGLES DE NOMMAGE DES FICHIERS «MESSAGES METIER» ET DE LEURS PIECES JOINTES CAS GENERAL Quelque soit le type et la nature du fichier, les fichiers télétransmis (hors fichiers XML décrivant les «enveloppes», et les anomalies sur des fichiers enveloppes) devront comporter dans leur nom les informations suivantes : DEPT - NUM_COLL - DATE_ACTE_INVERSEE - NUM_ACTE - TYPE_ABREGE- TRANSACTION_NUMERO DEPT département sur 3 caractères NUM_COLL numéro SIREN collectivité DATE_ACTE_INVERSEE date de l'acte collectivité sous format AAAAMMJJ NUM_ACTE numéro de l'acte interne à la collectivité (alphanumérique, 15 car. maximum) TYPE_ABREGE DE, AR, AI, représente le type d acte Représente le numéro de la transaction suivi du numéro d ordre dans la TRANSACTION transaction (cf. codification plus bas) NUMERO Numéro séquentiel Codification des transactions : I - Transaction 1 : la transmission d un acte. Action Acteur Transaction Transmission de l acte Collectivité 1-1 Transmission de l accusé réception MI 1-2 Anomalie dans le formulaire signalétique MI 1-3 II Transaction 2 : courrier simple. Action Acteur Transaction Envoi de courrier simple MI 2-1 Réponse au courrier simple Collectivité 2-2 MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 12

13 III Transaction 3 : demande de pièces complémentaires. Action Acteur Transaction Demande MI 3-1 Transmission de l AR Collectivité 3-2 Refus explicite d envoi pièces complémentaires Collectivité 3-3 Transmission pièces complémentaires Collectivité 3-4 Transmission de l AR MI 3-5 IV Transaction 4 : lettre d observations. Action Acteur Transaction Transmission de la lettre d observations MI 4-1 Transmission de l AR Collectivité 4-2 Refus explicite réponse lettre d observations Collectivité 4-3 Réponse lettre d observations Collectivité 4-4 Transmission de l AR MI 4-5 V Transaction 5 : déféré TA. Action Acteur Transaction Transmission information déféré TA MI 5-1 VI Transaction 6 : annulation de transmission d un acte. Action Acteur Transaction Annulation de transmission d un acte Collectivité 6-1 Transmission de l AR MI 6-2 VII Transaction 7 : demande de classification. Action Acteur Transaction Demande Collectivité 7-1 Envoi de la classification MI 7-2 Envoi de la classification à jour MI 7-3 Par exemple dans les cas suivant (transmission d un acte comportant 2 annexes) : XYZ-AR-1-1_0.xml Message métier Le département 069 Le SIREN La date de l acte Le numéro de l acte 4586 Le type de l acte AR La transaction et son numéro d ordre 1.1 (transmission d un acte) Numéro de fichier séquentiel XYZ-AR-1-1_1.pdf ACTE Le département 069 Le SIREN La date de l acte Le numéro de l acte 4586 Le type de l acte AR La transaction et son numéro d ordre 1.1 (transmission d un acte) Numéro de fichier séquentiel XYZ-AR-1-1_2.pdf ANNEXE 1 Le département 069 Le SIREN La date de l acte MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 13

14 Le numéro de l acte 4586 Le type de l acte AR La transaction et son numéro d ordre 1.1 (transmission d un acte) Numéro de fichier séquentiel XYZ-AR-1-1_3.pdf ANNEXE 2 Le département 069 Le SIREN La date de l acte Le numéro de l acte 4586 Le type de l acte AR La transaction et son numéro d ordre 1.1 (transmission d un acte) Numéro de fichier séquentiel CAS PARTICULIER DE LA TRANSACTION 7 (DEMANDE DE CLASSIFICATION) La règle générale qui précède n est pas applicable aux flux de la transaction 7 (flux 7-1, 7-2, et 7-3). Ces flux ne concernant pas un acte en particulier, le nommage des fichiers transmis omettra les informations relatives à l acte. Les fichiers seront donc de la forme : DEPT - NUM_COLL ----TRANSACTION_NUMERO DEPT NUM_COLL TRANSACTION NUMERO département sur 3 caractères numéro SIREN collectivité Représente le numéro de la transaction suivi du numéro d ordre dans la transaction (cf. codification plus bas) Numéro séquentiel Par exemple : _0.pdf ANNEXE 2 Le département 069 Le SIREN La transaction et son numéro d ordre 7.1 (demande de classification) Numéro de fichier séquentiel REGLES DE NOMMAGE DES FICHIERS COMPRESSES Ces règles sont spécifiques à la dématérialisation du contrôle de légalité, et dans le cas des transferts d information de la «sphère collectivités» vers la sphère «intérieur», où les fichiers envoyés sont compressés dans une archive.tar.gz. Un fichier compressé.tar.gz contient un et un seul fichier XML «enveloppe», et le nom du fichier.tar.gz sera basé sur le nom du fichier XML «enveloppe», selon le modèle suivant : ITC NOM_FICHIER_ENVELOPPE.tar.gz Avec : Identifiant à 3 caractères du tiers de confiance, donné par le ministère à ITC chaque tiers de confiance au moment de son raccordement NOM_FICHIER_ENVELOPPE Nom du fichier XML «enveloppe», tel que décrit au paragraphe MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 14

15 Par exemple, si le fichier XML «enveloppe» transmis par une collectivité est nommé : EACT xml et que le tiers de confiance utilisé par la collectivité a pour identifiant ITC «abc», le fichier compressé sera nommé : abc- EACT tar.gz A noter que l ajout, dans le nom du fichier.tar.gz, du préfixe avec l identifiant du tiers de confiance peut être effectué par le tiers de confiance, sur la base du fichier compressé sans le préfixe, envoyé par la collectivité. En effet, cette opération complètement réversible ne modifie absolument pas les données métier transmises, ni les signatures, ni les éléments de sécurisation. MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 15

16 4 PROTOCOLES UTILISES 4.1 DES COLLECTIVITES VERS LE MINISTERE Deux protocoles de transport sont supportés: HTTP et FTP, sécurisés grâce à la couche SSL/TLS (Secure Sockets Layer). Le ministère met en zone Internet un serveur HTTPs/FTPs appelé SAS-GW sur lequel les tiers de confiance viennent déposer les fichiers tar.gz contenant les actes et courriers à destination des préfectures, sous-préfectures et SGAR. Les éléments permettant la connexion à ce serveur seront fournis lors du raccordement de chaque tiers de confiance, une fois l habilitation obtenue. Le ministère recommande l utilisation de FTPs, nettement plus économe que HTTPs en volume de données transmis pour un même fichier.tar.gz. HTTPs présente de son côté l avantage d utiliser des technologies et standards plus stabilisés et plus faciles à automatiser que FTPs VERSION DES PROTOCOLE HTTP ET FTP SUR SSL SUPPORTEE Pour les upload de fichiers HTTPs, les RFC concernées sont les suivantes : RFC1945 : Hypertext Transfer Protocol HTTP/1.0 RFC2616 : Hypertext Transfer Protocol HTTP/1.1 RFC2617 : HTTP Authentication RFC2965 : HTTP State Management Mechanism ( Cookies) RFC2246 : TLS Transport Layer Security SSL Protocol version 3 (spécification Netscape) RFC2818 : HTTP over TLS Pour l'aspect FTP sur SSL/TLS dont les standards ne sont pas totalement stabilisés, le serveur SAS-GW implémente les RFC et les draft suivants : RFC959 : FTP File Transfer Protocol RFC2246 : TLS Transport Layer Security SSL Protocol version 3 (spécification Netscape) RFC2577 : FTP security consideration support ders commandes MDTM, REST, SIZE, TVFS (Draft ietf-ftpext-mlst-16.txt extensions FTP ) RFC2228 : FTP security extension conformément aux spécifications du Draft Murray V11. le Draft Murray version 11 «Securing FTP with TLS».en cours d agrément par l IETF Par ailleurs, le serveur supporte le mode implicite définit dans les Draft Murray version 0 à 6 et formellement rejeté par l IETF à partir de la version 7. Ce mode est encore supporté et assure la compatibilité avec certains clients CLIENTS HTTPS COMPATIBLES La fonction de transfert sous HTTPS fonctionne avec les versions des navigateurs supportant les RFC indiqués au paragraphe Elle a été validée avec IE5.5 et IE6 et différents autres navigateurs dont Konqueror et Netscape 7.0. MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 16

17 Le développement de clients batch fonctionnant en Java, Perl ou d autres langages est également possible. Le dépôt de fichier s effectue par une méthode POST dont les paramètres seront fournis aux tiers de confiances habilités par l équipe de support du MISILL CLIENTS FTP SSL COMPATIBLES Les clients doivent être compatibles avec les standards décrits au cf , notamment le draft Murray V11. Toutefois, la technologie FTP sur SSL/TLS n est pas totalement stabilisée, ce draft est en cours de validation par l IETF et prorogé jusqu en février 2004 (V12). Toutes les informations sur les clients et le protocole FTP SSL sont disponibles sur le site Les RFC laissent une marge d appréciation, les différentes implémentations de clients FTPs se conformant à ces standards peuvent malgré tout se révéler incompatibles. Le ministère pourra fournir sur demande la liste de clients dont la compatibilité a été vérifiée. Les tiers de confiance habilités choisissant de réaliser les transferts en FTPs devront tenir le MISILL informé la version de client utilisé TAILLE LIMITE D'UN FICHIER TAR.GZ TRANSMIS PAR LES TIERS DE CONFIANCE La taille maximum d'un fichier tar.gz ne devra pas dépasser 20 Mo. 4.2 DU MINISTERE VERS LES COLLECTIVITES Le protocole utilisé est SMTP (Simple Mail Transfer Protocol, cf. RFC2821 et RFC2822). Lors de la transmission d'un acte, la collectivité met dans le formulaire signalétique correspondant la ou les adresses SMTP auxquelles le ministère doit envoyer tout courrier concernant cet acte. Les messages envoyés par le ministère respecteront le format MIME v1.0 (Multipurpose Internet Mail Extensions, cf. RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) ou S/MIME (Secure Multipurpose Internet Mail Extensions, cf. RFC2311, RFC2312). Le texte, l'objet du message seront en simple texte iso Ils ne contiendront néanmoins aucune information destinée à être prise en compte par les applications de la "sphère collectivités locales", qui ne devront exploiter que les pièces jointes. Les pièces jointes seront attachées aux messages conformément au format MIME. La taille totale des pièces jointes ne dépassera pas 2 Mo. Elles seront aux formats décrits dans la partie de la présente norme consacrée à ce sujet. MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 17

18 5 SECURISATION 5.1 PRINCIPES La sécurisation de la télétransmission vise deux objectifs : - Authentification réciproque : s assurer qu un message (acte, courrier ) vient bien de celui qui dit l avoir envoyé, et qu il a bien été remis à son destinataire et non à un usurpateur. - Intégrité : s assurer que l acte n a pas été altéré lors du transfert. 5.2 DISPOSITIFS MIS EN PLACE Différents dispositifs participent à l atteinte de ces objectifs : - L utilisation de SSL/TLS avec FTP ou HTTP dans le cas des transmissions des collectivités locales vers le ministère - Pour le tiers de confiance, le serveur du ministère est authentifié par le certificat serveur présenté lors de la négociation SSL. - Pour le MISILL, le tiers de confiance émetteur d une transmission est authentifié au moyen du couple login/mot de passe qui lui est attribué après son habilitation. - Pour obtenir l accès, le tiers de confiance doit disposer d une adresse IP fixe contrôlée par les équipements de sécurité du MISILL. - Le tiers de confiance doit obligatoirement renouveler son mot de passe à périodicité minimum et respecter la norme de complexité, définies par le MISILL, faute de quoi l accès est refusé. - L utilisation d accusés de réception «métier» pour les envois sensibles de la sphère intérieur vers la sphère collectivités. Cela permet de détecter toute perte de transmission, ou toute transmission venant d une origine tierce non habilitée. - L utilisation de S/MIME en remplacement de MIME pour certains envois de la sphère intérieur vers la sphère collectivités permet l authentification de l émetteur de ces envois. Ces dispositifs d ordre technique sont complétés par ceux mis en place dans la sphère collectivités (par exemple pour sécuriser la liaison entre les collectivités et leurs tiers de confiance), par des conventions qui engagent la responsabilité de chacun des partenaires de la transmission dématérialisée, et enfin par les vérifications par des contacts téléphoniques que doivent effectuer les agents du ministère et des collectivités en cas de doute. Ces dispositifs pourront à terme être enrichis par l utilisation de la signature électronique, dans une version future de la norme d échange. Les modalités d utilisation de la signature sont à définir (formats, normes, politique de certification et de contrôle). Il est néanmoins envisagé de définir plusieurs niveaux de signature, en distinguant la signature des actes et courriers et la signature des envois et des méta données. Les schémas XML décrivant les échanges métier incluent déjà les espaces où seront insérées les signatures des fichiers. Les signatures qui pourraient arriver par ce biais dans fichiers envoyés aux préfectures ne seront pas prises en compte, et donc ne sont pas obligatoires. MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 18

19 5.3 ELEMENTS FOURNIS POUR L OUVERTURE DES ECHANGES PAR LE MISILL AUX TIERS DE CONFIANCE Identifiant de tiers de confiance ( ITC) Compte de connexion (FTP ou HTTP) Password de connexion initial ( à changer à la première utilisation) Certificat racine de l'ac (autorité de certification) ayant émis les certificats. Certificat du serveur du ministère. Le numéro du port et l'adresse IP du SAS-GW URL et paramètre de connexion HTTPs Périodicité minimum de changement de mot de passe Le numéro du centre d appel PAR LES TIERS DE CONFIANCE AU MISILL Adresse IP Internet présentée par le client FTPs ou HTTPs du tiers de confiance pour les échanges. MISILL/DGCL-DSIC Norme d échange pour l application A.C.T.E.S. 19