28/09/2012 STANDARDS TECHNIQUES ETNIC. Cadre de Spécifications techniques imposé dans les CSC CTAE

Transcription

1 28/09/2012 ETNIC STANDARDS TECHNIQUES Cadre de Spécifications techniques imposé dans les CSC CTAE

2 ATTENTION!!! Points à aborder dans le CSC en dehors de ce document!!! Critères : Les éléments suivants seront pris en considération dans l évaluation de la solution proposée : Le découplage des fonctionnalités, afin de les rendre utilisables indépendamment du reste de la solution ; La facilité d adaptation et d installation de la solution ; La qualité, la lisibilité et la documentation «du code source». Ces codes sources devront en effet permettre, à l expiration du présent marché, la maintenance de la solution par des techniciens qui pourraient, le cas échéant, ne pas être ceux de l adjudicataire ; L utilisation éventuelle de logiciels, librairies ou frameworks libres et stables ; Attention dans le cas de la maintenance!!! Engagement à long terme?? Évolution mineure => maintenance corrective Évolution majeure => maintenance évolutive mercredi 28 septembre 2012 Page 1

3 1 Exigences techniques 1.1 Remarque préalable Si un soumissionnaire estime qu'aucun fournisseur ne pourra répondre sans s'écarter en tout ou partie des exigences techniques listées dans ce chapitre, il doit en apporter la justification. Toutefois l ETNIC ne peut pas garantir que les offres qui ne respectent pas ces exigences, ne pourront pas être écartées pour des raisons de non-conformité. De même en cours de réalisation du marché, toute dérogation à ce chapitre DOIT faire l'objet d'une demande au PA qui se réserve le droit de l'accepter ou de la refuser. La version des spécifications à respecter sera celle disponible à la date de publication du marché ou postérieure. Passé le délai de 10 jours calendrier avant la date limite de réception des offres, le PA ne garantit plus la transmission des mises à jour en temps utiles, sans que le soumissionnaire puisse s en prévaloir pour obtenir une quelconque prolongation de délai. 1.2 Respects des exigences techniques Quelle que soit la solution proposée (i.e. des composants standards : licences propriétaires ou libres), celle-ci DOIT respecter les standards définis dans ce chapitre au point «Environnement d'exploitation». Si la solution proposée se base uniquement sur des développements spécifiques, ceux-ci doivent respecter les standards définis dans ce chapitre au point «Environnement de développement». Si des développements spécifiques s ajoutent au(x) produit(s) proposé(s), deux cas de figures peuvent être rencontrés : Soit ces développements font partie intégrante du produit (par exemple repris dans une nouvelle version du produit ou un add-on) alors les standards à respecter sont les mêmes que ceux imposés pour le produit (standards définis dans ce chapitre au point «Environnement d'exploitation») ; Soit ces développements ne font pas partie intégrante du produit alors ces développements spécifiques doivent respecter les standards définis dans ce chapitre au point «Environnement de développement». Quel que soit la solution proposée, le soumissionnaire DOIT respecter les exigences du chapitre Architecture de la solution. 1.3 Respects des exigences non-fonctionnelles (Service Level Agreement-SLA) L'infrastructure proposée DOIT prendre en compte notamment les éléments suivants : La continuité du service devra être assurée, même en cas de défaillance d une partie du système ; La nécessité de pouvoir faire face à une charge de travail susceptible d augmenter sans pour autant que le service offert aux utilisateurs ne soit dégradé ; L utilisation optimale des ressources techniques de l ETNIC. Le soumissionnaire indiquera les moyens qu il recommande et qu il mettra en œuvre pour garantir un temps de réponse permettant l utilisation performante et confortable de la nouvelle solution dans une situation normale de fonctionnement en fonction des différents modes d'utilisation mercredi 28 septembre 2012 Page 2

4 conformes aux exigences fonctionnelles (usage intensif dans le cas d'un encodage en masse, usage courant dans le cas d'une consultation...). Le soumissionnaire détaillera en outre les spécifications hardware minimales qu il recommande pour chaque serveur utilisé dans l architecture proposée. Dans le cadre de son offre, le soumissionnaire s engagera sur un temps de réponse maximal en conformité avec les hypothèses et le cadre d utilisation formulés ci-avant. Ces temps de réponse devront être reproduits, dans 95% des cas, lors de l utilisation des diverses transactions de la solution (consultation, recherches, mise à jour des données, reporting, ). 1.4 Environnement d'exploitation Contraintes générales La solution proposée DOIT fonctionner dans un environnement utilisant des ressources mutualisées. Elle n'est donc pas autorisée à modifier le paramétrage d exploitation et de sécurité dans lequel elle s exécutera. Tout besoin identifié en la matière sera soumis aux services concernés de l ETNIC pour approbation. Aucune clé physique de type «dongle» ou équivalent ne pourra être utilisée Compatibilité VMware La solution DOIT être compatible avec l environnement VMware (ESX 3.5) de l ETNIC. La solution DOIT fournir les spécifications techniques des serveurs virtuels (instances VMware hors DB) en considérant que les instances des serveurs seront dédicacées à la solution. Remarque : Les caractéristiques des serveurs physiques utilisés par ces serveurs virtuels sont à la charge de l'etnic Systèmes d'exploitation Le système d exploitation des serveurs applicatifs et des bases de données est : soit Microsoft Windows 2003 server soit Red Hat Linux Enterprise 5.3 ou supérieur. La base de données DB2 (cf. point suivant) est hébergée sur l unité centrale IBM Z114 fonctionnant sur z/os. Les systèmes d exploitation utilisés au niveau des postes clients sont Microsoft Windows Bases de données La base de données à utiliser impérativement dans la nouvelle solution complète sera, au choix, de l un des types suivants : IBM DB2 v9 IBM UDB v9 ou ultérieure MySQL 5.0 ou version ultérieure Microsoft SQL Server Serveur d application Web Seuls, les serveurs d application suivants pourront être employés : IBM Websphere Application Server 6.1 Apache Tomcat 6.x mercredi 28 septembre 2012 Page 3

5 Les dernières versions à utiliser seront confirmées avant tout développement et/ou déploiement Serveurs web Seul le serveur Apache 2.2 sera utilisé Navigateurs La solution devra être compatible avec les navigateurs de type MS Internet Explorer 7.0 (et ultérieurs) et Mozilla Firefox 3.x (et ultérieurs). La version de la Java Virtual Machine utilisée sur les postes clients par défaut est la JRE Suites bureautiques Microsoft Office 2003 French est installé sur l'ensemble des postes de l'administration. Afin de permettre aux utilisateurs de lire des fichiers créés à partir de Microsoft Office 2007, le pack compatibilité Microsoft Office 2007 y a été également installé. Les utilisateurs ont également la possibilité de travailler avec des fichiers ODF (en lecture et en écriture) grâce au plugin «odf-converter» ( 2 ) Format de fichiers L interfaçage des applications avec les outils bureautiques est réalisé de façon à garantir l'indépendance des développements vis à vis des outils bureautiques et de leur version, même pour un usage strictement interne à l Administration. Les principaux formats de fichiers à respecter par l adjudicataire sont : Fichiers XML pour un usage applicatif ; DOC ou ODF pour les fichiers qui doivent être repris par un traitement de texte ; CSV pour les fichiers qui doivent être repris par un tableur ; PDF pour les documents en lecture seule. Dans le cas d'utilisation de ce format, il est nécessaire de se limiter aux fonctions d affichage de base Monitoring Un outil de monitoring d'infrastructure sera utilisé mais n'aura aucun impact sur la solution à développer. Il s'agit de l'outil SiteScope Espace de stockage Le système de stockage centralisé de l ETNIC est basé sur les technologies SAN fibres optique (NetApp filers) en cluster Réseau Le réseau est basé sur les protocoles et services TCP/IP, DHCP, DNS, HTTP(S). Tout trafic applicatif de type web amené à circuler dans des zones non sécurisées DOIT impérativement être chiffré. Les services administratifs centraux sont reliés par des lignes à haut débit. Tous les centres locaux (max 20 pers.) sont reliés soit par des lignes SDSL soit par ADSL. 1 La version sera confirmée avant tout développement. 2 La version sera confirmée avant tout développement. mercredi 28 septembre 2012 Page 4

6 Gestion des sauvegardes A titre indicatif, la solution de l'etnic dans le cadre des sauvegardes de serveurs ou d'applications s'exécutant sur serveur (en ce compris les DB sauf DB2) est aujourd hui composée de 2 robots dont les caractéristiques sont : un robot ADIC Scalar d'une capacité de 40 cassettes de 160Gb et un robot DELL PowerVault Ml6000 d'une capacité de 80 cassettes de 800Gb. La gestion des sauvegardes est décrite dans le document relatif à la «Gestion des Sauvegardes et des Restaurations de données informatiques au sein de l'one_version4.1», repris en annexe. Ce document a été écrit dans le cadre de projets ONE. Il correspond toutefois à la politique de sauvegarde que l'etnic applique pour ses projets. mercredi 28 septembre 2012 Page 5

7 1.5 Environnement de développement Langage et frameworks Le cas échéant, les développements de nouveaux modules applicatifs nécessaires à la réalisation de la solution proposée devront impérativement être effectués : en Enterprise Generation Language (EGL), à l aide de la plateforme de développement IBM Rational Business Developer version 7.1 ou ultérieure. Dans l hypothèse de ce choix, le soumissionnaire sera tenu de respecter les standards de développement en vigueur au sein de l ETNIC. ou en Java. Dans l hypothèse de ce choix, les frameworks (ou équivalents) suivants devront être utilisés : Partie écran : o Web : JSF et/ou Ajax (sans Flash) o Lourd : Swing (les applets Java sont interdites) Partie Web Services : o Axis ou Cxf Partie métier : o Springframework Partie accès base de données : o «Hibernate» ou «Springframework JDBC» sont recommandés. Toutefois, si le soumissionnaire désire choisir «JDBC», il devra justifier son choix dans son offre. Ce choix devra en tout état de cause être validé par le PA. Système de journalisation des évènements : o Log4j 3 Contrôle du code : o Findbugs 4 Installation et gestion des mises à jour automatiques sur un poste de travail : o Java Web Start (uniquement pour client Lourd) Base de données Le soumissionnaire est tenu de respecter les standards de l ETNIC en matière de normalisation des bases de données opérationnelles à l ETNIC Gestion des sources Le gestionnaire des sources «Subversion» (SVN) de l ETNIC devra être utilisé. En cas de prestation autre qu à l ETNIC, une copie des sources devra être importée dans le repository SVN du PA de manière régulière (par exemple après chaque acceptation du projet) Outils collaboratifs L emploi de «Mantis» comme outil collaboratif pour la gestion des demandes évolutives et correctives est imposé. 3 Si le soumissionnaire se trouve dans l obligation de proposer d utiliser un autre système de journalisation, il devra alors s engager à respecter les interfaces «commons-logging» d Apache. 4 Cfr mercredi 28 septembre 2012 Page 6

8 1.5.5 Chartes graphiques et ergonomiques du MCF Trois chartes graphiques/ergonomiques ont été définies au MCF correspondant à divers champs d'application : Charte des applications grand public : Profil utilisateurs : nombre indéterminé d'utilisateurs non formés. Caractéristique : plusieurs fonctionnalités simples. Charte des applications métier : Profil utilisateurs : nombre déterminé d'utilisateurs formés. Caractéristique : plusieurs fonctionnalités simples ou complexes. Charte des formulaires intelligents : Profil utilisateurs : nombre indéterminé d'utilisateurs non formés. Caractéristique : une fonctionnalité linéaire de type formulaire. mercredi 28 septembre 2012 Page 7

9 1.6 Architecture de la solution Si la solution proposée est un développement spécifique, l'architecture de la solution DOIT respecter les règles énoncées dans le document «architecture des applications métiers». Si la solution proposée est un développement spécifique, le soumissionnaire DOIT présenter l architecture générale de la solution en décomposant les différents modules de la solution suivant les différentes couches (présentation, métier et accès aux données). Quel que soit la solution proposée, le soumissionnaire DOIT présenter le positionnement de sa solution en rapport avec les points suivants : 1. Positionnement métier (vue métier) : La solution sera décrite en fonction des exigences Métier afin d indiquer sa couverture fonctionnelle (les éléments informatiques qui automatisent tout ou partie des exigences Métier). Idéalement un processus sera présenté, il indiquera les composants applicatifs de la solution qui interagissent avec le processus. 2. Positionnement de l application (vue SI) : La solution sera décrite par une découpe en composants (basés sur les concepts informatiques utilisés dans la vue Métier) afin d indiquer les flux d informations gérées au sein de la solution. Les relations extérieures de la solution (via des interfaces) seront également indiquées. 3. Positionnement technologique (vue Technologique) : La solution sera décrite par un positionnement technologique des différents composants (de la vue SI) afin d indiquer comment les flux de la vue SI sont réalisés d un point de vue technique et supportés par quel produit. Cette description pourra s appuyer sur les schémas présentés au «Intégration avec les solutions mises en œuvre par l ETNIC» Utilisation de librairies et de frameworks libres existants Le soumissionnaire est encouragé à utiliser des frameworks libres, basés sur des standards ouverts, stables, pérennes et existants. Si une solution proche de qualité, existe en logiciel libre, le soumissionnaire doit envisager la possibilité d apporter une amélioration à ce framework, plutôt que de développer sa propre solution. Lors de la phase d analyse de l'architecture technique, pour chaque composant identifié, l adjudicataire doit étudier les solutions libres existantes, susceptibles de rencontrer les exigences de l'architecture. Une fois l analyse détaillée réceptionnée, l adjudicataire doit, en phase de développement, prendre toutes les mesures voulues pour en assurer la pérennité et également la transmission des modifications aux communautés impactées Modularité et découplage des fonctionnalités L implémentation des fonctionnalités doit être modulaire. Les modules (composants applicatifs) implémentant les fonctionnalités doivent être faiblement couplés entre eux pour augmenter la robustesse Interopérabilité Un accent tout particulier est mis sur la capacité d interopérabilité et d intégration de la solution. Elle DOIT se baser sur des standards ouverts et/ou spécifications ouvertes qui permettront de s intégrer facilement aux infrastructures informatiques existantes ou à venir. Les modules de la solution DOIVENT s intégrer à d autres applications via des protocoles ouverts comme SOAP (style Document/Liberal), JMS. mercredi 28 septembre 2012 Page 8

10 Le choix de l un de ces protocoles peut, le cas échéant, être imposé par le PA suivant les spécifications suivantes : 1. Tous les Web Services de la Communauté française exposés sur internet DOIVENT respecter les standards WS-I. 2. Tous les Web Services exposés sur internet DOIVENT respecter les standards de sécurité sur internet dans le cadre de communication entre applications. 3. L intégration avec notre Gestionnaire d identités et d accès (CERBERE) DOIT respecter les spécifications indiquées au Intégration de la solution avec Cerbère. 4. Dans le cadre de communication asynchrone entre applications back-end (entre couches métier ou, entre couche présentation et couche métier), la solution DOIT utiliser notre plateforme de notification. Celle-ci respecte entièrement le standard ws-notification. Pour plus d'information cfr «Intégration de la solution avec le service d échange de données» Intégration avec les solutions mises en œuvre par l ETNIC La solution DOIT s intégrer ou au moins s interfacer, chaque fois qu il est techniquement possible, avec les solutions mises en œuvre par l ETNIC. Dans ce chapitre le soumissionnaire découvrira les différents standards d intégration recommandés. Le soumissionnaire aura également une vue de comment ETNIC a déjà intégré certains de ses éléments comme son portail, ses nombreux formulaires électroniques, son CMS, son IAM (Cerbère) et donc de tout l intérêt pour ETNIC de les réutiliser Intégration de la solution avec le Service d échange de données Il est FORTEMENT recommandé d intégrer la solution avec le Service d échange de donnée afin de bénéficier des différents types d intégration avec les autres applications. Cette intégration avec ce service ne pourra se faire (en standard) que via le canal webservice. Un seul type de canal technique de communication est recommandé pour l intégration des applications du SI ETNIC. Il s agit du canal appelé webservice qui impose : l utilisation du protocole HTTP pour établir la connexion entre les applications ; le format du message en SOAP (version 1.1 ou 1.2) pour le transport de l information ; le contenu du message Métier (payload) en XML dans la partie Body (du message SOAP) pour la compréhension de manière électronique de l information ; la description du message dans un fichier (contrat) wsdl pour le développement du canal webservice ; la communication entre les applications en mode stateless (sans état) pour la performance des échanges. Les applications Métier communiquent entre elles en utilisant ce service d échange de données (implémenté principalement par le produit Apache Servicemix). Ce service a pour objectif de permettre des échanges d'information entre applications de la FWB. Ceci en proposant deux modes de communication : Le mode «requête - réponse» (en synchrone et en asynchrone) et, Le mode «événementiel». Enfin ces modes de communication sont utilisés dans trois types de services (les 3 rôles d un ESB) : 1. Service d'intégration : il gère les échanges synchrones et asynchrone entre les services application Métier et leur monde extérieur. L objectif est de cacher les aspects techniques mercredi 28 septembre 2012 Page 9

11 de la communication liés généralement à la complexité du transport du message (protocole) et à l intégration du message (format) dans l application cible. 2. Service de médiation : Le service de médiation gère les échanges d'information entre le monde extérieur et les services application Métier. Ils interviennent également dans les échanges d'information entre les services application Métier. La particularité de ce service est de toujours intégrer un workflow applicatif (appelé orchestration) qui permet de créer un dialogue entre deux (voire plus) applications. Ce service crée un flux à forte valeur ajoutée dans le SI ETNIC. 3. Service de notification : Le service de notification gère l'ensemble des notifications du SI ETNIC entre les services Présentation (Front-Office) et tous les services application Métier. C'est à dire qu'il gère tous les abonnements à des sujets (topics) et les publications / notifications des différents services intervenants dans un flux applicatif. Ce service est une des solutions à la mise en place d'une communication asynchrone entre services application Métier. Le scénario ci-dessous montre la manière dont deux applications Métier communiquent entre elles en utilisant soit le service d intégration seule, soit le service de médiation couplé au service d intégration. Le scénario ci-dessous montre l intégration d une application Métier avec un Ordonnanceur en utilisant le service de notification. Le principe est qu une application Métier émet (publie) un événement (notification) que l ordonnanceur reçoit parce qu il s est abandonné à un sujet. Sur base de l évènement et du sujet (topic) l ordonnanceur peut prendre une action telle qu exécuter un programme Batch. mercredi 28 septembre 2012 Page 10

12 Intégration de la solution avec le Front-Office Il est FORTEMENT recommandé d intégrer la solution avec le Front-Office. Les raisons de cette intégration se feront en fonction de modes de fonctionnement identifiés lors de l analyse fonctionnelle. De manière générale, voici les définitions des 3 modes de fonctionnement appliqués au sein du SI ETNIC : Collecte de l information : Le mode de fonctionnement Collecte de l'information est un service de collecte de données soit de masse soit de manière spécifique - c'est à dire à la demande (ou occasionnellement) mais toujours disponible dans le temps. La relation avec l'utilisateur portera sur une demande d'information provenant de l'utilisateur. Les informations affichées par le service de collecte seront uniquement dans un but d'aide à l'encodage. Traitement de l information : Le mode de fonctionnement Traitement de l'information est un service de traitement qui nécessite une interaction avec un utilisateur. L'interaction sera principalement concernée par un échange d'information de part et d'autre. Publication de l information : Le mode de fonctionnement Publication de l'information est un service de publication fournissant de l'information vers les utilisateurs. De manière plus spécifique, les modes de fonctionnement appliqués au Front-Office sont appelés des cas d utilisation et nommés respectivement C1, T1 et P1. Voici leur définition : C1 : (Cas d utilisation Front-Office - Collecte d information) Ce cas d'utilisation doit être composé d'outil de présentation pour utilisateur non-professionnel. Ce qui signifie, afin de d'assurer une qualité suffisante de la récolte, qu'il est nécessaire de mettre les moyens suffisants d'aide à l'encodage pour guider l'utilisateur et qu'il est obligatoire de s'adapter (autant que possible) avec son environnement informatique. T1 : (Cas d utilisation Front-Office - Traitement de l information) Ce cas d'utilisation pourrait être comparé à un guichet. Par exemple une personne qui travaille au guichet d'une banque a besoin d'accéder aux données du compte d'un client mais cette même personne n'est pas habilitée (parce qu'elle n'est pas formée) à le gérer. Il est donc nécessaire de lui mercredi 28 septembre 2012 Page 11

13 fournir un outil de travail adapté à ces compétences par de l'aide à l'encodage et des outils intégrés à son environnement bureautique. P1 : (Cas d utilisation Front-Office Publication de l information) Ce cas d'utilisation permet de fournir de l'information à un utilisateur, à un groupe d'utilisateur ou à tous les utilisateurs. Son rôle est de transformer l'information pour l'adapter à l'environnement informatique de l'utilisateur. Il peut également servir à adapter l'information au contexte de l'utilisateur (citoyen, fonctionnaire...). L intégration dépendra donc de C1, T1 et P1 car ils établiront la manière dont les flux d information seront implémentés au sein du SI ETNIC et surtout de la manière dont ils seront gérés dans la solution. Il va de soi que l intégration se fera par l intermédiaire du service d échange de données (cfr précédent). Ci-dessous le schéma global de l intégration d une application Métier (Back-Office) avec le Front-Office, en utilisant le Middle-Office-Middleware (architecture qui implémente le service d échange de données). L'architecture du Front-Office correspond à la mise en place d'au moins 5 outils principaux : Un portail Un coordinateur de flux Utilisateur Un composant de gestion des formulaires électroniques Un composant de gestion de contenu Une boîte aux lettres électroniques; Cette architecture peut s appuyer sur les outils suivants: Un moteur de recherche; Un service de signature électronique. mercredi 28 septembre 2012 Page 12

14 Le principe est de positionner le portail comme un composant qui utilise tous les autres composants. Par "utiliser", on entend l'action de ce composant sur les autres. Le portail utilise des services et uniquement des services. Eux-mêmes sont réalisés par des composants applicatifs (par exemple : Coordinateur, formulaires électronique, CMS) Ensuite ce sont ces mêmes composants qui : envoient des informations au monitoring des flux d'informations s'intègrent avec la couche MO soit via les processus du FO (donc utilisation du service notification ou intégration) soit via des processus transversaux MO (donc utilisation du service de médiation). Pour ce dernier cas l'intégration ne pourra être réalisée qu'à partir du coordinateur de flux Utilisateur - garant de la bonne exécution du processus FO. Dernier point sur le FO, il s'intègre fortement avec l'architecture Sécurité. C'est à dire que tout utilisateur est authentifié et autorisé par le Contrôle d'accès mais également identifié par le GIA. D un point de vue technologique, l intégration avec le Front-Office se réalise de la même manière qu une autre application Métier, c'est-à-dire en s intégrant avec le service d échange de données. Voici un scénario d intégration, ci-dessous, entre une application Métier et le Front-Office mercredi 28 septembre 2012 Page 13

15 Intégration de la solution avec CERBERE La solution DOIT être intégrée à Cerbère. La solution DOIT impérativement être interfacée à CERBERE avant sa mise en production. Avant toute analyse liée à l application, une entrevue DOIT avoir lieu avec l équipe Cerbère afin de garantir la prise en compte des impératifs de mise en œuvre liés à Cerbère. L ETNIC dispose d une infrastructure logicielle de gestion et de contrôle des identités et des accès, appelé Cerbère, qui se décompose en deux parties : un Gestionnaire des Identités et des Autorisations (GIA) un Contrôleur d Accès pour applications (CAW-UI) et Web Services (CAW-S). Elle permet : la maîtrise de la gestion des utilisateurs et de leurs droits d accès : o centralisation des données d identification et d autorisation dans un référentiel unique permettant la visibilité et donc facilitant l audit de ces données ; o enregistrement des mouvements concernant ces données, permettant a posteriori des analyses en cas d incidents ; de réduire les risques : o suppression des opportunités d abus par l utilisation de droits indus du fait du retrait de manière aussi systématique que l octroi, des droits d accès ; o limitation des risques de non conformité par rapport aux dispositions légales ; une meilleure efficacité de l administration des utilisateurs : o diminution des efforts consacrés à l administration des utilisateurs par l automatisation partielle des procédures d attribution et de suppression des droits ainsi que par la délégation de la gestion de ces droits vers des acteurs métiers proches des utilisateurs finaux ; une meilleure efficacité opérationnelle des utilisateurs : o réduction des pertes de temps lors d une entrée en fonction ou d un changement de fonction d une personne identifiée par la mise en place d une gestion des droits d accès basée sur le concept de rôle ; La solution DOIT utiliser le GIA de Cerbère pour la gestion des identités et des autorisations de ses utilisateurs. L authentification de l utilisateur, via le CAW, DOIT être déléguée à l extérieur de la solution. Pour ce faire, la nouvelle solution intégrera le système de sécurité développée par l'etnic telle que décrite dans le document «Standards Sécurité - web» (fichier en annexe : Externe_Standards Sécurité web). Les spécifications des interfaces applicatives de ce système sont fournies dans le document «Standards Sécurité Gestion des Accès» (fichier en annexe : Externe_StandardsSécurité CAW) Intégration de la solution avec le module de signature électronique L intégration de la solution avec esignbox est FORTEMENT recommandée pour assurer le contrôle des «signatures électroniques». Dans l hypothèse d une intégration de la solution avec le Front-Office (cfr précédent) et l utilisation des formulaires électroniques (sous-composant du Front-Office), celle-ci bénéficiera par défaut de la signature électronique. mercredi 28 septembre 2012 Page 14

16 La Région wallonne et la Communauté française ont développé une «boîte à outils de signature électronique», dénommée «esignbox» qui permet : d apposer une signature électronique sur des fichiers électroniques en utilisant la carte d identité électronique belge (eid) ou d autres cartes à puces fournissant un pilote PKCS11 ou un certificat de type PKCS12 / PFX ; de vérifier la validité de la signature d un «fichier signé» appelé «archive signée» (.zip) ; de vérifier la validité d un certificat employé pour signer un fichier. Le module esignbox est disponible en 2 versions : Via portail de signature : Le citoyen se connecte au portail de signature et peut signer électroniquement ces fichiers locaux, il peut aussi valider la signature d un document signé électroniquement. Via un portail appelant le portail de signature : Le citoyen se connecte à un portail appelant qui va gérer le processus de signature entre le citoyen et le portail de signature (cas des formulaires par exemple). Cette application est accessible à l adresse Éléments transversaux réutilisables Le SI ETNIC est composé d outils transversaux qui peuvent être utilisés (en cohérence avec leur rôle au sein du SI) en soutien des différentes architectures Front-Office, Middle-Office et Back- Office. Une vue globale de ces outils transversaux est disponible dans le document «Glossaire des outils transversaux». mercredi 28 septembre 2012 Page 15

17 Les annexes Architecture des applications métiers Standards Sécurité - WEB Standards Sécurité gestion des accès Gestion des sauvegardes Glossaire des outils transversaux mercredi 28 septembre 2012 Page 16