CAHIER SPECIAL DES CHARGES MARCHE PUBLIC DE SERVICES MISE EN PLACE D UNE SOLUTION ESB APPEL D OFFRES GÉNÉRAL

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

CAHIER SPECIAL DES CHARGES MARCHE PUBLIC DE SERVICES “MISE EN PLACE D’UNE SOLUTION ESB”

APPEL D’OFFRES GÉNÉRAL

Modifications : Section I.17.3 Critères d’attribution Clarification Annexe E) a) ii) Annexe F Date de la séance d’ouverture des offres : le vendredi 23 septembre 2011 à 10 h

Date de la séance d'ouverture des offres : Le 16 septembre 2011 à 10 h

P. 1

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Table des matières I. DISPOSITIONS ADMINISTRATIVES .................................................................................................. 6 I.1 DESCRIPTION DU MARCHÉ .................................................................................................................. 6 I.1.1 Contexte du marché ................................................................................................................ 6 I.1.2 Problématiques ........................................................................................................................ 9 I.1.3 Objet du marché .................................................................................................................... 11 I.2 IDENTITÉ DU POUVOIR ADJUDICATEUR ............................................................................................... 12 I.3 UTILISATION PAR D’AUTRES POUVOIRS ADJUDICATEURS FEDERAUX .................................................... 12 I.4 DÉCLARATION DE CONFIDENTIALITÉ .................................................................................................. 13 I.5 MODE DE PASSATION ....................................................................................................................... 13 I.6 PROCÉDURE NÉGOCIÉE ULTÉRIEURE ................................................................................................ 13 I.7 DÉTERMINATION DES PRIX ................................................................................................................ 13 I.8 DURÉE DU MARCHÉ .......................................................................................................................... 14 I.9 SÉANCE D’INFORMATION .................................................................................................................. 14 I.10 FORME ET CONTENU DES OFFRES ................................................................................................... 15 I.11 ASSOCIATIONS MOMENTANÉES ....................................................................................................... 17 I.12 VARIANTES LIBRES ......................................................................................................................... 17 I.13 OPTIONS ....................................................................................................................................... 17 I.14 DÉLAI DE VALIDITÉ ......................................................................................................................... 17 I.15 DÉPÔT DES OFFRES ....................................................................................................................... 18 I.16 OUVERTURE DES OFFRES............................................................................................................... 19 I.17 PROCÉDURE D’ATTRIBUTION DU MARCHÉ ........................................................................................ 19 I.17.1 Critères de sélection qualitative ........................................................................................... 19 I.17.2 Régularité des offres ............................................................................................................ 22 I.17.3 Critères d’attribution ............................................................................................................. 22 II. DISPOSITIONS CONTRACTUELLES ............................................................................................. 24 II.1 NOTIFICATION DE L’ATTRIBUTION DU MARCHÉ ................................................................................... 24 II.2 LE BON DE COMMANDE ET SES MODALITÉS ....................................................................................... 25 II.3 FONCTIONNAIRE DIRIGEANT ............................................................................................................. 25 II.4 CAUTIONNEMENT ............................................................................................................................ 25 II.5 CARACTERE LIVRABLE DU SYSTEME PROPOSE .................................................................................. 27 II.6 EXÉCUTION DU MARCHÉ .................................................................................................................. 27 II.6.1 Clause d’évolution technologique......................................................................................... 27 II.6.2 Lieu d’exécution du marché et particularités ........................................................................ 27 II.6.3 Personnel de l’adjudicataire ................................................................................................. 28 II.6.4 Sous-traitants ....................................................................................................................... 29 II.6.5 Moyens mis à disposition par le SPF Finances ................................................................... 30 II.6.6 Normes et standards à respecter ......................................................................................... 31 II.6.7 Gestion des changements (« change management ») ........................................................ 31 II.6.8 Engagements particuliers concernant les informations reçues ............................................ 32 II.6.9 Responsabilités .................................................................................................................... 34 II.7 DURÉE ........................................................................................................................................... 34 II.8 SUIVI DES SERVICES PRESTÉS ET CONTRÔLES PAR DES TIERS ........................................................... 35 II.8.1 Suivi de la bonne exécution du marché ............................................................................... 35 II.8.2 Contrôles par des tiers ......................................................................................................... 35 II.9 EVALUATION DES SERVICES PRESTÉS ET OPÉRATIONS DE VÉRIFICATION ............................................ 35 II.10 RÉCEPTION PROVISOIRE ............................................................................................................... 36 II.11 GARANTIE .................................................................................................................................... 36 II.12 RÉCEPTION DÉFINITIVE.................................................................................................................. 37 II.13 MODALITÉS ET FRAIS DE RÉCEPTION .............................................................................................. 37 II.14 PROPRIÉTÉ DES SOFTS DÉVELOPPÉS ............................................................................................. 37 II.15 DÉPÔT CHEZ UN SÉQUESTRE ......................................................................................................... 39 II.16 FACTURATION, PAIEMENT ET REVISION DES PRIX............................................................................. 40 II.16.1 Facturation et paiement...................................................................................................... 40 II.16.2 Révision des prix ................................................................................................................ 40 II.16.3 Clause du client le plus avantagé....................................................................................... 41

P. 2

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

II.17 PUBLICITÉ - RÉFÉRENCEMENT ....................................................................................................... 41 II.18 LIVRAISONS EN RETARD ................................................................................................................ 41 II.19 MOYENS DE DEFENSE DE L’ADMINISTRATION - LITIGES .................................................................... 42 III. DESCRIPTION DES EXIGENCES TECHNIQUES .......................................................................... 43 III.1 DESCRIPTION DU MARCHÉ .............................................................................................................. 43 III.1.1 Contexte du marché ............................................................................................................ 43 III.1.2 Problématiques ................................................................................................................... 46 III.1.3 Objet du marché.................................................................................................................. 48 III.2 EXIGENCES DU MARCHÉ ................................................................................................................. 50 III.2.1 Exigences générales ........................................................................................................... 50 III.2.2 La solution ESB................................................................................................................... 51 III.2.3 Licences .............................................................................................................................. 63 III.2.4 Maintenance logicielle et support........................................................................................ 65 III.2.5 Transfert de connaissances ................................................................................................ 66 III.2.6 Projet pilote ......................................................................................................................... 68 III.2.7 Renforcement de la démarche SOA ................................................................................... 68 III.2.8 Organisation du projet ......................................................................................................... 69 III.2.9 SLA...................................................................................................................................... 75 IV. PARTIE D : ANNEXES .................................................................................................................... 77 ANNEXE A : FORMULAIRE D'OFFRE ................................................................................................ 78 ANNEXE B : CURRICULUM VITAE ..................................................................................................... 80 ANNEXE C : MODÈLE DE RÉFÉRENCE ........................................................................................... 82 ANNEXE D : FORMULAIRE DE QUESTIONS/RÉPONSES .............................................................. 83 ANNEXE E : INVENTAIRE ................................................................................................................... 84 A)

MISSIONS PRINCIPALES ................................................................................................................. 84 i) Transfert de connaissances .................................................................................................. 84 ii) Prix des licences .................................................................................................................... 85 iii) Fonction de volumétrie .......................................................................................................... 86 iv) Reste des missions principales ............................................................................................. 88 B) MISSIONS SECONDAIRES ............................................................................................................... 88 i) Profils ..................................................................................................................................... 88 ANNEXE F : INFORMATIONS SUR L’INVENTAIRE ......................................................................... 89

P. 3

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Auteur de projet Nom: Service d'Encadrement ICT Adresse: Boulevard du Roi Albert II 33 bte 95 à 1030 Bruxelles Personne de contact: Nicolas Vanderavero Téléphone: 0257/81.353 Fax: 0257/9.68.01 E-mail: [email protected] Réglementation en vigueur 1. Loi du 24 décembre 1993 (MB du 22-01-1994) relative aux marchés publics et à certains marchés de travaux, de fournitures et de services, et ses modifications ultérieures. 2. Arrêté royal du 8 janvier 1996 (MB du 26-01-1996) relatif aux marchés publics de travaux, de fournitures et de services et aux concessions de travaux publics, et ses modifications ultérieures. 3. Arrêté royal du 26 septembre 1996 (MB du 18-10-1996) établissant les règles générales d'exécution des marchés publics et des concessions de travaux publics ainsi que l’annexe à cet arrêté royal concernant le cahier général des charges, et ses modifications ultérieures.

En ce qui concerne les documents propres au pouvoir adjudicateur : • • •

•

Le présent cahier spécial des charges. Les avis relatifs au marché et les avis de modification, annoncés ou publiés dans le Bulletin des Adjudications et dans le Journal des Publications de l'Union Européenne, qui concernent les marchés publics en général. Les clarifications résultant de la séance d'information (questions posées et réponses données par le pouvoir adjudicateur). Ces précisions font partie intégrante des conditions contractuelles. Le soumissionnaire est censé en avoir pris connaissance et en avoir tenu compte dans son offre. Les documents auxquels le pouvoir adjudicateur fait référence dans le cahier spécial des charges.

En ce qui concerne les documents propres au soumissionnaire : • •

L'offre du soumissionnaire. Les précisions et engagements acceptés par le SPF Finances et qui complètent l'offre (avec la même référence) suite aux questions et demandes de clarification.

Dérogations, précisions et commentaires Néant

P. 4

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Sigles et acronymes utilisés B2B Business-to-Business B2G Business-to-Government BAM Business Activity Monitoring BCE Banque Carrefour des Entreprises BCSS Banque Carrefour de la Sécurité Sociale BCFF Banque Carrefour de la Fiscalité Fédérale CCFF Centre de Communications de la Fiscalité Fédérale CV Curriculum Vitæ DB Database DMZ Demilitarized zone EAI Enterprise Application Integration EDA Event-Driven Architecture ESB Enterprise Service Bus ESM Enterprise System Management ETP Équivalent Temps Plein FedIAM Federal Identity and Access Management FSB Federal Service Bus FUP Finance Unified Process G2C Government-to-Citizen G2G Government-to-Government IAM Identity and Access Management IT Information Technology ICT Information and Communication Technologies IDE Integrated Development Environment ISO International Organization for Standardization JDBC Java DataBase Connectivity JEE Java Platform, Enterprise Edition JMX Java Management Extensions KPI Key Performance Indicator PRINCE2 PRojects IN Controlled Environments 2 QoS Quality of Service REST Representational State Transfer RDC Relational Data Center RUP Rational Unified Process SGBD Système de Gestion de Base de Données SLA Service Level Agreement SNMP Simple Network Management Protocol SOA Service Oriented Architecture SOAP Simple Object Access Protocol SPF Service Public Fédéral UME Universal Messaging Engine WSDL Web Services Description/Definition Language WS-I Web Services Interoperability XML Extensible Markup Language

P. 5

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

I. Dispositions administratives Cette première partie se rapporte à la réglementation d'attribution d'un marché public jusqu'à la désignation de l'adjudicataire. Les dispositions contenues dans cette partie se rapportent à la loi du 24 décembre 1993 et à l’arrêté royal du 8 janvier 1996 et ses modifications ultérieures.

I.1 Description du marché I.1.1 Contexte du marché Cette section présente le contexte dans lequel se place le présent marché : l’infrastructure IT du SPF Finances et ses problématiques actuelles. Cette infrastructure est d’abord présentée de manière globale en la replaçant dans le contexte du plan Coperfin. Elle est ensuite décrite plus précisément, tout d’abord du point de vue du matériel et du logiciel qui la constitue, ensuite du point de vue des communications qui transitent via cette infrastructure. Enfin, les problématiques actuellement rencontrées sont présentées ainsi que les motivations qui ont poussé l’Administration à publier ce cahier des charges. Les informations présentées dans ces sections sont des informations partielles destinées à présenter le contexte général du marché. Le soumissionnaire consultera le site Internet du SPF Finances à l’adresse http://minfin.fgov.be/ où il trouvera de plus amples informations sur : ● Coperfin : sous la rubrique Modernisation > Bibliothèque Coperfin ● ICT : sous la rubrique Modernisation > ICT ● Architectural Building Blocks : sous la rubrique Modernisation > ICT > Fondement ● Les différents cahiers des charges publiés : sous la rubrique Marchés publics

I.1.1.1 Infrastructure IT du SPF Finances I.1.1.1.1 Présentation globale Au sein du SPF Finances, le plan de modernisation Coperfin se voit exécuté, dans son volet informatique, par divers projets d'amélioration de l'infrastructure existante dont :

●

●

● ●

●

Atlas, lancé en 2004, qui offre une plate-forme matérielle de systèmes et de stockage ouverts d'entreprise sur lesquelles fonctionne la nouvelle infrastructure logicielle du SPF Finances, appelée à remplacer tous les mainframes Le CCFF (Centre de Communications de la Fiscalité Fédérale) qui depuis 2003 se veut une infrastructure d'applications dynamique basée sur JEE et ouverte à un maximum d'outils de développement, de technologies d'échanges de données et de services. Le CCFF s'est notamment développé via la conception d'un framework, regroupant de nombreux services mis à disposition des applications (comme Tax on Web, Intervat, …) qui fonctionnent audessus et grâce à lui RDC qui apporte un système de gestion de bases de données relationnelles standard pour le département ICT SupDev qui offre un support au développement via, entre autres, une méthodologie complète de développement de logiciels (FUP, basée sur RUP) ainsi que tous les outils nécessaires à son application à grande échelle Le projet « Enterprise System Management » qui met en place le monitoring

P. 6

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

● Le service « Job Scheduling » qui gère les jobs de production à exécuter sur les différentes plates-formes (Windows, UNIX et mainframe) du SPF Finances

I.1.1.1.2 Présentation spécifique L’infrastructure IT peut être vue de deux manières :

I.1.1.1.2.1 Du point de vue du matériel et du logiciel

Les caractéristiques principales de l’infrastructure matérielle sont : ● L’environnement est réparti sur deux sites : au North Galaxy, siège du SPF Finances et au South Galaxy à Anderlecht, distant de plusieurs kilomètres du premier site ● Les serveurs web et d’applications sont installés sur des Fujitsu-Siemens BF200 et BF400. Les BF200 peuvent contenir maximum 6 lames contenant chacune 2 CPU Intel E5450 de 4 cores à 3Ghz et 32Gb RAM. Les BF400 peuvent contenir maximum 24 lames contenant chacune 4 CPU de 4 cores à 2.93Ghz et 64Gb RAM. Le système d’exploitation est Solaris 10 ● Les serveurs de base de données sont des FTS M9000 contenant chacun 32 CPU, 8 cores par CPU et 512 Gb RAM. Le système d’exploitation est Solaris 10 ● L’environnement est complètement redondant et tous les éléments fonctionnent en parallèle. La charge est répartie entre eux via des mécanismes de clustering ● Les applications sont totalement déployées sur les serveurs d’applications situés dans le LAN interne

P. 7

SERVICE PUBLIC FÉDÉRAL FINANCES

●

●

● ●

Réf.: ICT/INF/ESB

Les serveurs « Apache » ne contiennent que du contenu statique et réalisent du forwarding des requêtes vers les serveurs d’applications. Ces serveurs web font également office de filtre entre les applications accessibles sur Internet et les applications accessibles uniquement sur l’intranet L'équilibrage des charges des serveurs d’applications est entièrement réalisé sur base des mécanismes de Bea Weblogic. Le load balancing est exécuté au niveau des serveurs web Apache par un plugin Bea Le « clustering » des serveurs web est basé sur des loadbalancers matériels Cisco ACE L’accès aux mainframes est possible de façon identique à partir des deux environnements

I.1.1.1.2.2 Du point de vue des communications Le schéma suivant donne une vue générale des communications qui peuvent transiter via l’infrastructure IT du SPF Finances :

Les acteurs principaux de ce schéma sont : ● CCFF : propose des abstractions d’accès aux mainframes, des mécanismes de communication inter-applications ainsi que le développement et l’hébergement de services internes ● IAM : fournit une solution d’Identity and Access Management gérant les aspects liés à l’authentification et à l’autorisation des utilisateurs ● RDC : gère les bases de données relationnelles P. 8

SERVICE PUBLIC FÉDÉRAL FINANCES

● ●

Réf.: ICT/INF/ESB

D&RMC : gère l’archivage des documents numériques ESM : gestion du monitoring, implémentée via HP OVOw

On retrouve différents types de flux qui peuvent transiter via cette infrastructure. Citons, par exemple :

●

Communications inter-applicatives : la plupart du temps, définies via le CCFF

●

Communications G2C : la plupart du temps, via des web-applications spécifiques telles que Tax-on-Web, Intervat, …

●

Communications G2G : ○ BCSS : via des web services ○ BCE : via FTP ○ Communauté Européenne : via CCN/CSI ○ Fedict : via le FSB et l’UME de Fedict ○ Registre National : via FTP ○ Communes : entre autres via des web-applications spécifiques ○ ...

●

Communications B2G : ○ Banque : via le réseau Isabel ○ Chambre Royale des Notaires de Belgique : via le FSB Fedict ○ Belcotax On Web : via une web-application, via chargement de DVD ○ ...

I.1.2 Problématiques Le SPF Finances est confronté à deux problématiques : d’une part, l’accroissement des besoins hétérogènes en communication de et vers l’extérieur et, d’autre part, le besoin de renforcer la démarche SOA (Service Oriented Architecture).

I.1.2.1 Accroissement des besoins en communication de et vers l’extérieur Dans un futur proche, le SPF Finances sera confronté à une évolution des canaux de communication qu’il utilise pour communiquer avec ses partenaires externes. Ainsi, la modernisation de l’infrastructure IT des partenaires actuels amènera des changements tant dans la technologie que dans la nature de ces canaux de communications, augmentant à terme fortement l’hétérogénéité. De plus, l’apparition de nouveaux partenaires au niveau régional, fédéral ou encore européen, amènera la création de nouveaux canaux de communication. Afin de centraliser les aspects liés à la communication avec les partenaires externes et de créer un pôle d’expertise, le SPF Finances désire mettre en place une « Banque Carrefour de la Fiscalité Fédérale » qui sera la plateforme centrale de communication avec l’extérieur du SPF Finances. Il est important de se préparer de manière adéquate à ces futurs changements dans les canaux de communication afin, d’une part, de minimiser les impacts sur les applications existantes et, d’autre part, de pouvoir réagir rapidement lorsqu’il est nécessaire de créer un nouveau canal de communication ou bien d’adapter la technologie utilisée pour les canaux existants. En effet, dans certains cas les délais de mise en œuvre sont dérivés de contraintes légales qu’il faut respecter sous peine de pénalités. Une solution possible serait de gérer ces flux de communication dans le framework CCFF et de l’utiliser comme couche d’exposition et de médiation de et vers l’extérieur. Cette solution impliquerait

P. 9

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

donc de devoir développer, tester et maintenir en interne des composants d’interfaçage et de médiation. Par ailleurs, cela impliquerait également de devoir planifier la mise en production d’une nouvelle version du framework à chaque évolution de ces composants. Afin d’obtenir la souplesse nécessaire pour absorber au mieux les nombreux changements prévus sur les canaux de communication et pour minimiser l’impact sur les applications, le SPF Finances désire se tourner vers une autre solution en intégrant un ESB (Enterprise Service Bus) dans son architecture. En effet, le rôle principal d’un ESB est de fournir des fonctionnalités de médiation de services et de permettre la transformation et le routage de messages. De plus, un ESB comporte de nombreux connecteurs qui permettent de s’interfacer rapidement avec diverses technologies de communication sans qu’il soit nécessaire de développer et maintenir en interne des composants spécifiques. Enfin, la définition des flux de communication et des opérations à effectuer sur les messages qui y transitent peuvent être définis dynamiquement via des opérations de configuration.

I.1.2.2 Renforcement de la démarche SOA Parallèlement à ces aspects de communication externe, le SPF Finances désire renforcer l’approche SOA qui incube depuis quelques années au sein de l’ICT. En effet, le développement du framework CCFF a permis de faire émerger quelques artefacts d’une approche SOA tels que le découplage technologique avec ses clients, l’apparition de la notion de service, un embryon d’annuaire de service, … Plus récemment, le cahier des charges CCFF 2008 a confirmé la volonté de s’inscrire dans une démarche SOA et en a tracé les grandes lignes directrices. Il est cependant nécessaire de consolider ce qui a déjà été réalisé et de systématiser la démarche SOA. À titre d’exemple, on peut constater que la notion de service, notion centrale de la démarche SOA, commence à se répandre au sein de l’ICT et a permis de mettre en place plusieurs services tels que la validation de numéro de compte bancaire, la récupération des bureaux compétents pour une certaine fonction, la gestion de tâches humaines via le Taskmanager, … Cependant, la maturité de certains aspects peut être améliorée, par exemple en référençant tous les services dans un annuaire de service, en définissant et vérifiant des SLA sur ces services, en mettant en place une couche d’abstraction et de médiation de l’accès aux services afin de ne plus devoir modifier les applications appelantes suite à une modification technique du service, ... Il est important pour le SPF Finances de s’engager plus en avant dans la démarche SOA. En effet, en faisant émerger la notion de couche de service au sein d’une organisation, la démarche SOA permet, à terme, de favoriser l’agilité, l’interopérabilité et une meilleure réutilisation de l’existant. Le SPF Finances désire donc consolider son socle technologique SOA en intégrant un ESB dans son architecture de référence. Grâce à ses fonctionnalités de médiation et d’intégration, il permettra de renforcer le travail effectué pour faire émerger une couche de service et d’augmenter le niveau de maturité SOA en jouant un rôle de levier pour accélérer l’adoption de SOA au sein du SPF Finances.

I.1.2.3 Le besoin d’une solution ESB Répondre correctement à l’augmentation des besoins en communication et au désir d’augmenter le niveau de maturité SOA sont deux défis de taille. Ils ont cependant un point commun : tous deux peuvent bénéficier de la mise en œuvre, non pas d’un simple produit ESB, mais bien d’une solution ESB. Le SPF Finances définit une solution ESB comme une plateforme de communication qui place un produit ESB au cœur de son architecture mais qui peut également comporter d’autres modules ou produits (tels que, par exemple, un catalogue de services, ...) qui s’inscrivent tous dans une approche intégrée de renforcement de la démarche SOA en place.

P. 10

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

La solution ESB sera placée au cœur de la future banque carrefour de la fiscalité fédérale afin de pouvoir répondre plus facilement à l’augmentation pressentie des besoins liés à la communication avec les partenaires externes. Il n’est pas exclu qu’à terme les flux de communications existants et les communications inter-applicatives soient également du ressort de la solution ESB. Cette solution ESB sera également utilisée comme un catalyseur de la démarche d’urbanisation SOA au sein du SPF Finances en mettant en avant la notion de service grâce à ses fonctionnalités de médiation et d’intégration Le but du présent cahier des charges n’est donc pas simplement de doter l’infrastructure IT du SPF Finances d’un produit ESB en acquérant des licences. L’objectif poursuivi est de mettre en place une solution ESB complète qui soit pérenne et évolutive, qui s’intègre dans notre architecture, qui promeut la notion de service au sens SOA du terme et qui est alignée avec l’objectif à long terme de mise en place d’une architecture de référence SOA.

I.1.3 Objet du marché I.1.3.1 Introduction Comme expliqué dans la section « Contexte du marché », le SPF Finances souhaite doter son infrastructure IT d’une solution ESB lui permettant de faciliter les communications avec ses partenaires externes et d’utiliser cette solution ESB comme levier pour accélérer l’adoption de la démarche SOA. La mise en place d’un ESB dans un contexte SOA est une démarche inédite au SPF Finances. Si les premières étapes de la réalisation sont claires et bien définies, certains aspects à plus long terme sont encore inconnus, tels que, par exemple, le nombre et la volumétrie des futurs canaux de communication, la rapidité de l’adoption de SOA, le taux de réutilisation de services internes, … De plus, certaines de ces étapes futures dépendent fortement du succès de la réalisation des étapes en amont. Pour refléter cet état de fait, l’objet du marché est divisé en deux volets. Ces derniers étant fortement connexes, ils ne constituent qu’un seul lot. Le premier volet définit un ensemble de missions qualifiées de principales. Ces missions portent sur la mise en place correcte de la solution ESB, la réalisation d’un projet pilote et le démarrage du renforcement de la démarche SOA. Ces missions principales doivent être réalisées en prix fixe avec une obligation de résultat. Le second volet définit quant à lui un ensemble de profils qui seront utilisés pour réaliser des missions qualifiées de secondaires. Ces missions seront des missions liées à la solution ESB et à l’adoption de la démarche SOA mais pour lesquelles il est très difficile de prévoir dès à présent quel sera leur contenu ou leur ampleur. En effet, ces missions secondaires n’ont potentiellement de sens que si les missions principales sont un succès. Elles peuvent également être liées à des aspects en dehors du contrôle du SPF Finances (par exemple : mise en place d’un format de données spécifique découlant d’une contrainte légale, …) Comme ces missions ne peuvent être définies précisément pour l’instant, le SPF Finances ne garantit aucunement un minimum de commande dans le cadre de ces missions secondaires.

P. 11

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

I.1.3.2 Objet du marché Le marché est constitué d’un seul lot. Il consiste à mener à bien les missions suivantes dont les exigences sont détaillées dans la suite de ce cahier des charges :

●

Missions principales, en prix fixe, avec obligation de résultat : ○ Mettre en œuvre une solution ESB au sein de l’infrastructure du SPF Finances qui respecte les contraintes et les exigences définies dans le présent cahier des charges et qui s’intègre harmonieusement avec l’existant et les bonnes pratiques du SPF Finances (monitoring, IAM, haute-disponibilité, fail-over, disaster recovery, …) (voir entre autres section III.2.1 « Exigences générales », section III.2.2 « La solution ESB », section III.2.9 « SLA ») ○ Fournir les licences des différents composants de la solution ESB (voir section III.2.3 « Licences ») ○ Fournir au personnel interne du SPF Finances les connaissances nécessaires à l’installation, la configuration, l’exploitation, le développement et la maintenance de la solution ESB (voir section III.2.5 « Transfert de connaissances ») ○ Réaliser un projet pilote reposant sur la solution ESB (voir section III.2.6 « Projet pilote ») ○ Évaluer le niveau de maturité SOA avant et après l’installation de la solution ESB et la réalisation du pilote; rédiger des recommandations d’améliorations (voir section III.2.7 « Renforcement de la démarche SOA »)

●

Mission secondaire, sans garantie de commande par le SPF Finances : fournir des profils à temps plein et/ou à temps partiel pour réaliser des missions dans le cadre de l’exploitation, la maintenance et le développement de la solution ESB ainsi que dans le cadre du renforcement de la démarche SOA (voir section III.2.8.4 « Profils pour les missions secondaires »)

La solution ESB devant être installée sur l’infrastructure existante du SPF Finances, ce marché ne couvre pas la fourniture de matériel.

I.2 Identité du pouvoir adjudicateur Service Public Fédéral Finances Service d’Encadrement ICT Boulevard du Roi Albert II 33 bte 95 1030 Bruxelles

I.3 Utilisation par d’autres pouvoirs adjudicateurs fédéraux Le SPF Finances est le pouvoir adjudicateur compétent pour la surveillance et le contrôle du marché. Cependant, dans le cadre du présent marché, conformément à l’article 2, 4° de la loi du 15 juin 2006, d’autres pouvoirs adjudicateurs fédéraux ou entreprises publiques fédérales peuvent se référer aux conditions du présent marché afin de répondre à des besoins éventuels, sans recourir à cette fin à la mise en concurrence. Par conséquent, chaque fois qu’il est fait mention du « SPF Finances » dans le présent texte, il convient de lire effectivement « SPF Finances » pour tout ce qui concerne ou précède l’adjudication,

P. 12

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

ou « SPF Finances ou un autre pouvoir adjudicateur fédéral ou une entreprise publique fédérale » pour tout ce qui concerne l’exécution.

I.4 Déclaration de confidentialité En déposant l'offre le soumissionnaire est lié automatiquement à la clause suivante : La personne ou les personnes qui intervien(nen)t en tant que mandataire(s) et qui a/ont signé cette offre électroniquement, garantit/garantissent la confidentialité des données et les résultats de leur traitement qui sont obtenus dans le cadre de la mission décrite dans ce cahier spécial des charges. Il s’ensuit que ces données et les résultats de leur traitement : • seront utilisés uniquement, si nécessaire, pour la réalisation de l'objet de la mission, • ne seront ni diffusés ni copiés, • ne seront pas gardés plus longtemps que nécessaire pour l'exécution de la mission.

I.5 Mode de passation Le marché est passé par appel d’offres général. En application de l'article 18 de la loi du 24 décembre 1993 relative aux marchés publics et à quelques marchés de travaux, de fournitures et de services, le pouvoir adjudicateur peut soit renoncer à octroyer le marché, soit recommencer la procédure, au besoin suivant une autre méthode.

I.6 Procédure négociée ultérieure Conformément à l'article 17, § 2, 2°, b de la loi d u 24 décembre 1993 relative aux marchés publics, le pouvoir adjudicateur se réserve le droit, moyennant une procédure de négociée, sans publicité pendant une période de maximum trois ans après la conclusion du présent marché, d'attribuer, au soumissionnaire qui a obtenu le premier marché, un marché pour de nouveaux services consistant en une répétition des services similaires aux services décrits dans le présent cahier de charges.

I.7 Détermination des prix Le présent marché est un marché de type mixte. Le marché mixte est celui dont les prix sont fixés suivant plusieurs des modes dont il est question aux alinéas 2 à 4 de l’article 86 de l’arrêté royal du 8 janvier 1996. Tous les prix mentionnés dans le formulaire « inventaire » doivent être obligatoirement libellés en euros. Dans son offre, le soumissionnaire indiquera les prix de toutes les parties de l'offre. Il complétera également l'inventaire prévu en annexe du présent cahier spécial des charges (annexe “inventaire”). Les prix sont mentionnés tous frais compris, mais hors TVA. L'utilisation du modèle "inventaire", tel qu'il est joint au cahier des charges, est obligatoire. La non-utilisation de ce modèle peut mener à l'exclusion de l'offre. L'on ne tiendra pas compte des prix qui sont mentionnés à un autre endroit qu'à la partie 2 de l'offre.

P. 13

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

I.8 Durée du marché Le marché a une durée de 5 années qui débute à la date du kick-off. Cependant, une fois les missions principales réalisées, le SPF Finances se réserve le droit, sans être redevables d’indemnités, de ne pas passer de commandes dans le cadre des missions secondaires. Cette période peut être prolongée, à la demande du pouvoir adjudicateur de 2 fois un an aux mêmes conditions et aux mêmes modalités que prévues dans le contrat de base. L’adjudicataire reste donc lié contractuellement pendant le délai de la période initiale, augmenté de prolongations éventuelles.

I.9 Séance d’information Etant donné la complexité du marché, le pouvoir adjudicateur a décidé d'organiser une séance d'information unique à l'attention des candidats-soumissionnaires. Il ne sera répondu à aucune des questions posées après cette séance d’information afin de traiter tous les candidats-soumissionnaires de la même manière. Il y sera exclusivement répondu aux questions écrites introduites au plus tard le 16 août 2011 par le biais du formulaire questions / réponses joint en annexe au présent cahier spécial des charges (voir “annexe: formulaire questions / réponses”). Ces questions peuvent uniquement être introduites par courriel, dans un tableur tel que celui joint en annexe, à l'adresse [email protected]. La séance d'information se déroulera le 18 août 2011 à 10 h. à cette adresse : SPF Finances Boulevard du Roi Albert II 33 1030 Bruxelles C5. Salle Mandarin. Toutes les questions doivent obligatoirement faire précisément référence au cahier spécial des charges, de façon à faciliter une réponse rapide (par ex. partie 1, point 1.1, paragraphe 1, page 1). Prière aussi de mentionner la langue du cahier spécial des charges utilisée (la pagination peut différer d’une langue à l’autre). Pendant cette séance d'information, un bref aperçu de l'objet du marché sera présenté. Les réponses aux questions introduites dans les délais seront données verbalement lors de la séance d’information et seront ensuite publiées sur le site Internet du SPF Finances. Il est demandé aux sociétés intéressées de se faire connaître au préalable par courriel à l’adresse [email protected] et de communiquer le nom et la fonction de la (des) personne(s) qui les représentera (représenteront) à la séance d’information. Pour des raisons d’organisation, un maximum de 2 personnes par société intéressée sera admis. Le SPF Finances se réserve le droit de refuser aux personnes qui ne se sont pas fait connaître 24 heures à l'avance, de participer à la session d’information.

Si les sociétés intéressées remarquent des incohérences, imprécisions, etc. dans le cahier spécial des charges, elles sont invitées à le faire savoir par écrit avant la séance d’information, suivant les mêmes modalités que pour l’envoi des questions. Le SPF Finances accorde une grande importance à l’égalité des soumissionnaires et rédige les spécifications de ses cahiers des charges en conséquence. Si une firme intéressée estime malgré tout que ses chances sont diminuées, voire réduites à néant, par certaines spécifications du présent cahier

P. 14

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

des charges, elle est invitée à en faire part par écrit au plus tard lors de la séance d’information. Le cas échéant, le SPF adaptera, s’il l’estime nécessaire, son cahier des charges afin d'en tenir compte.

I.10 Forme et contenu des offres Le soumissionnaire est tenu d’utiliser le formulaire d’offre joint en annexe au présent cahier spécial des charges. Si toutefois d’autres documents sont utilisés, il est tenu d’attester sur chaque document la conformité au formulaire d’offre joint au cahier spécial des charges (art. 89 de l’AR du 8 janvier 1996). L’offre et les annexes jointes au formulaire d’offre sont rédigées en français ou en néerlandais. Le soumissionnaire doit indiquer la langue à utiliser pour l’interprétation du contrat, c’est-à-dire le français ou le néerlandais. Par le dépôt de son offre, le soumissionnaire renonce automatiquement à ses conditions générales ou particulières de vente, même si celles-ci sont mentionnées dans l’une ou l’autre annexe à l’offre. Les soumissionnaires sont tenus de s'engager expressément sur toutes les clauses administratives et contractuelles du présent cahier spécial des charges. Toute réserve ou absence d’engagement sur l'une de ces clauses peut entraîner l'irrégularité de l'offre.

Quant à la structure de l’offre: L'offre du soumissionnaire devra obligatoirement être présentée selon le schéma suivant : Partie 1 – Partie administrative A. Formulaire d’offre (modèle: voir ci-dessous) B. Pouvoirs des mandataires C. Sélection qualitative Critères d’exclusion Critère de sélection relatif aux moyens économiques et financiers du soumissionnaire Critères de capacité technique D. Informations relatives aux sous-traitants (si applicable) Partie 2 – Partie financière Le tableau de prix : détailler et résumer les coûts (modèle: voir ci-dessous) Partie 3 – Proposition technique L’offre suit la structure de la partie III du cahier des charges Partie 4 – Annexes obligatoires Annexe 1: Références de projets récents, aussi bien dans le secteur privé que public (modèle: voir ci-dessous) Annexe 2: Curriculum Vitae (modèle: voir ci-dessous) Partie 5 – Annexes spécifiques Annexe A, B, C, … : Annexes que le soumissionnaire juge utile de joindre. Chaque proposition du soumissionnaire qui ne suivrait pas la structure imposée par le pouvoir adjudicateur, peut être considérée comme irrégulière. La Partie 3 - proposition technique ne peut contenir aucune indication administrative et/ou de prix. Il ne sera tenu aucun compte de toute mention administrative ou indication de prix apparaissant dans une autre partie que la partie 2. P. 15

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Il est demandé de réduire au minimum le nombre de fichiers à présenter. Ainsi par exemple des fichiers séparés peuvent être regroupés dans des documents plus importants. Il est également essentiel d’ordonner les fichiers au moyen d'une numérotation, de sorte que la structure de l’offre soit claire. Il est aussi demandé que dans chaque fichier les pages soient pourvues d’une numérotation ininterrompue. Concernant les mandataires: Toute offre introduite par des mandataires doit indiquer l'entité au nom de laquelle agissent les mandataires.

Celui qui a signé l’offre électroniquement doit, à la date de la signature, être habilité à engager le mandant au montant total de l’offre. Les mandataires joignent à l'offre une copie électronique d e l ’ acte authentique ou sous seing privé les habilitant, ou une copie de cet acte. Ils doivent également mentionner le numéro de l'annexe au Moniteur belge à laquelle sont publiés les mandats.

Concernant les sous-traitants Tout recours à des sous-traitants sera clairement indiqué dans l'offre du soumissionnaire. Celui-ci décrira le type de relation contractuelle qui le lie avec chacun de ses sous-traitants. Le nom et l'adresse des sous-traitants seront joints à l'offre, avec mention de la ou des parties du marché à réaliser par chaque sous-traitant. Les sous-traitants doivent par ailleurs répondre aux « critères d’exclusion » mentionnés au point « procédure d’attribution du marché ». Le soumissionnaire joindra à son offre tous les renseignements permettant de contrôler la situation de chacun de ses sous-traitants.

Concernant les documents d’ordre technique Les documents d’ordre technique (Pas de brochures publicitaires !) qui sont joints à l’offre dans la partie 5 - annexes spécifiques, peuvent être rédigés en anglais dans le cas où il n’existerait pas de traduction dans la langue de l’offre, les autres langues ne sont pas autorisées.

Formulaires à utiliser (joints en annexe au présent cahier spécial des charges): • • • •

Le formulaire d’offre: voir “annexe: formulaire d’offre” Le formulaire tableau de prix : voir “annexe: inventaire” Le formulaire pour les références: voir “annexe: modèle de référence” Le formulaire curriculum vitae: voir “annexe: curriculum vitae”

P. 16

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

I.11 Associations momentanées La remise d'une offre par une association momentanée est admise. Le formulaire d’offre (voir formulaire qui est repris dans le présent cahier spécial des charges : « annexe : formulaire d’offre ») est complété et signé par tous les membres de l'association momentanée ou par un ou plusieurs membres qui, selon les règles, sont mandatés pour représenter tous les membres de l'association momentanée (la preuve de ce mandat doit dans ce cas être présentée). Chaque membre de l'association momentanée doit satisfaire aux critères d'exclusion décrits ultérieurement dans le présent document. L'évaluation de la capacité économique, financière et technique porte sur l'association momentanée et non sur chaque membre séparément. Chaque membre de l'association momentanée est solidairement responsable de toutes les obligations résultant de la présente adjudication.

I.12 Variantes libres Il est interdit de proposer des variantes libres.

I.13 Options La proposition « d’options libres » n’est pas autorisée. Si des options sont demandées, les dispositions suivantes sont d'application : • Les options obligatoires (développements, accessoires ou prestations complémentaires) dont la livraison est obligatoire par le cahier des charges, seront proposées par les soumissionnaires, sous peine d'irrégularité de leur offre • Le pouvoir adjudicateur se réserve cependant le droit de ne pas lever ces options. Le fait de ne pas lever une option ne peut donner lieu à une quelconque forme de dédommagement. • Lorsqu'un équipement demandé comme option obligatoire, est prévu initialement dans le matériel standard, le soumissionnaire le mentionnera expressément dans son offre.

I.14 Délai de validité Les soumissionnaires restent liés par leur offre pendant un délai de 240 jours calendrier, à compter du jour qui suit celui de l’ouverture des offres.

P. 17

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

I.15 Dépôt des offres Le pouvoir adjudicateur impose dans le cadre du présent marché le recours aux moyens électroniques pour le dépôt des offres. S'il s'avère que certains écrits ne peuvent être créés par des moyens électroniques, ou s'il s'avère trop complexe de les créer par ces moyens, ces écrits peuvent être fournis sur un support papier et ce avant l’ouverture des offres. Le recours à des documents sur un support papier devra faire l'objet d'un accord préalable de la part du pouvoir adjudicateur. Cet accord est à demander à l’adresse suivante : SPF Finances Service d’Encadrement ICT – Cellule Marchés publics Boulevard du Roi Albert II 33 bte 95 1030 Bruxelles E-mail : [email protected] Afin de remédier à certains aléas de la transmission, de la réception ou de l'ouverture des demandes de participation ou des offres introduites par des moyens électroniques, le pouvoir adjudicateur autorise les soumissionnaires à introduire à la fois une offre transmise par des moyens électroniques et, à titre de sauvegarde, une copie établie par des moyens électroniques ou sur support papier. Cette copie de sauvegarde est glissée dans une enveloppe définitivement scellée qui porte clairement la mention "copie de sauvegarde" et est introduite dans les délais de réception impartis. Cette copie ne peut être ouverte qu'en cas de défaillance lors de la transmission, la réception ou l'ouverture de la demande de participation ou de l'offre transmise par des moyens électroniques. Elle remplace dans ce cas définitivement le document transmis par des moyens électroniques. Quant à l'introduction même: Avant leur ouverture, les offres électroniques sont déposées via le site Internet e-tendering https://eten.publicprocurement.be/, qui garantit le respect des conditions de l'article 81 ter de l'AR du 8 janvier 1996. Notons que l'envoi d'une offre par courriel ne répond pas à ces conditions. Il n'est dès lors pas autorisé d'introduire l'offre de cette façon. Indépendamment des variantes éventuellement autorisées, chaque soumissionnaire ne peut introduire qu'une seule offre par marché. L'offre doit parvenir au pouvoir adjudicateur avant la date limite de réception des offres. En soumettant son offre par la voie électronique, le soumissionnaire accepte que les données générées par le système de réception soient enregistrées (article 81 quinquiès de l'AR du 8 janvier 1996). Il faut signaler que la signature doit se faire par voie électronique. Une signature manuscrite scannée n’est pas considérée comme une signature acceptable. Au besoin, les attestations demandées seront scannées afin de les joindre à l'offre. Vous trouverez de plus amples http://www.publicprocurement.be Ou via le helpdesk e-procurement : • •

informations

sur

le

site

FR: Liza Torossian, 02 790 52 66, [email protected] NL: Peter Christiaens, 02 790 52 58, [email protected]

P. 18

Internet

suivant

:

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Si un soumissionnaire souhaite modifier ou retirer une offre déjà envoyée: Cela doit s'effectuer selon les dispositions reprises à l'article 105 de l'AR du 8 janvier 1996. La modification ou le retrait d'une offre déjà introduite peut se faire par voie électronique satisfaisant à l'article 81 ter de l'AR du 8 janvier 1996 ou sur papier. Pour modifier ou retirer une offre déjà introduite, une déclaration écrite est nécessaire. Celle-ci doit être dûment signée par le soumissionnaire ou son mandataire. L'objet et la portée des modifications doivent, sous peine de nullité de l'offre, être mentionnés de manière précise. Le retrait doit être inconditionnel. Le retrait peut également être communiqué par télégramme ou télécopie, pour autant que celui-ci arrive dans les mains du président de la séance avant l'ouverture des offres, avant qu'il ne déclare la séance ouverte.

I.16 Ouverture des offres La séance publique d'ouverture des offres électroniques se déroulera le 23 septembre 2011 à 10 h., à l'adresse suivante : SPF Finances North Galaxy Bld. du Roi Albert II, 33 1030 Bruxelles >> C5. Petite salle.

I.17 Procédure d’attribution du marché I.17.1 Critères de sélection qualitative Simplification administrative Par le simple fait de participer à la procédure d'attribution d'un marché public, le soumissionnaire déclare ne pas se trouver dans l'un des cas d'exclusion suivants, tels que mentionnés aux articles 17, 43 et 69 de l'Arrêté Royal du 8 janvier 1996 relatif aux marchés publics pour des contrats de travaux, fournitures et services, et les concessions de travaux publics. Le pouvoir adjudicateur analysera l'exactitude de cette déclaration implicite sur l'honneur en fonction du soumissionnaire dont l'offre est la mieux classée. Le soumissionnaire en question devra fournir les renseignements et les documents qui devront permettre de vérifier sa situation, par la voie la plus rapide et le délai imposé par le pouvoir adjudicateur, et ce pour chaque décision relative à l'attribution du marché. Ces informations seront toutefois demandées par le pouvoir adjudicateur par voie électronique auprès des gestionnaires de données si celles-ci sont disponibles gratuitement par ce biais. Un soumissionnaire peut être exclu de la participation à un marché s'il apparaît, après vérification, que la déclaration sur l'honneur ne correspond pas à sa situation personnelle à la date limite précédant la réception des demandes de participation lors d'une procédure limitée ou d'une procédure de négociation avec publication, ou à la date ultime précédant la réception des offres en cas de procédure ouverte. Une régularisation à posteriori est dès lors impossible. Une telle exclusion est également possible si, pendant le déroulement de la procédure, il apparaît que le fichier personne du candidat ou du soumissionnaire ne correspond plus à la déclaration sur l'honneur.

P. 19

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Dans ces deux hypothèses, le pouvoir adjudicateur effectuerait un classement corrigé, en tenant compte de l'impact possible de la suppression de la demande de participation ou de l'offre du candidat exclu ou du soumissionnaire, à savoir, en cas d'application des dispositions relatives au contrôle des prix anormaux de l'article 110, § 4 de l'arrêté royal du 8 janvier 1996. Le pouvoir adjudicateur pourra ensuite attribuer le marché au soumissionnaire dont l'offre est classée juste après celle du soumissionnaire exclu, après avoir appliqué ces mêmes dispositions à son égard également.

I.17.1.1 Critères d’exclusion Premier critère d’exclusion. §.1.

Le soumissionnaire belge qui emploie du personnel assujetti à la loi du 27 juin 1969 révisant l’arrêté-loi du 28 décembre 1944 concernant la sécurité sociale des travailleurs doit être en règle en matière de cotisations de sécurité sociale avant la date limite de réception des offres. Le pouvoir adjudicateur demandera directement cette information via le guichet électronique. Est en règle pour l’application du présent article, le soumissionnaire qui, suivant compte arrêté au plus tard la veille de la date limite de réception des offres : 1°

2°

a transmis à l’Office National de Sécurité Soci ale toutes les déclarations requises jusque et y compris celles relatives à l’avant-dernier trimestre civil écoulé par rapport à la date limite de réception des offres et n’a pas pour ces déclarations une dette en coti sations supérieure à 2.500 euros, à moins qu’il n'ait obtenu pour cette dette des délais de paiement qu’il respecte strictement.

Toutefois, même si la dette en cotisations est supérieure à 2.500 euros, le soumissionnaire sera considéré comme étant en règle s’il établit, avant la décision d’attribuer le marché, qu’il possède, au jour auquel l’attestation constate sa situation, à l’égard d’un pouvoir adjudicateur au sens de l’article 4, § 1 et § 2, 1° à 8° et 10° de la loi, ou d’une entreprise publique au sens de l’article 26 de cette même loi, une ou plusieurs créances certaines, exigibles et libres de tout engagement à l’égard de tiers pour un montant au moins égal, à 2.500 euros près, à celui pour lequel il est en retard de paiement de cotisations.

§ 2.

Le soumissionnaire étranger doit joindre à son offre ou présenter au pouvoir adjudicateur avant la date limite de réception des offres : 1°

une attestation délivrée par l’autorité compéten te certifiant que, suivant compte arrêté au plus tard la veille de la date limite de réception des offres, il est en règle à cette date avec ses obligations relatives au paiement des cotisations de sécurité sociale selon les dispositions légales du pays où il est établi. Lorsqu’un tel document n’est pas délivré dans le pays concerné, il peut être remplacé par une déclaration sous serment ou par une déclaration solennelle faite par l’intéressé devant une autorité judiciaire ou administrative, un notaire ou un organisme professionnel qualifié de ce pays ;

2°

§.3.

une attestation conformément au § 1, s’il emploi e du personnel assujetti à la loi du 27 juin 1969 révisant l’arrêté-loi du 28 décembre 1944 concernant la sécurité sociale des travailleurs.

A quelque stade de la procédure que ce soit, le pouvoir adjudicateur peut s’informer, par tous les moyens qu’il juge utiles, de la situation en matière de paiement des cotisations de sécurité sociale de tout soumissionnaire.

P. 20

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Deuxième critère d’exclusion. Le soumissionnaire ne peut pas se trouver dans l'une des situations suivantes : 1°

se trouver en état de faillite ou de liquidation , avoir cessé ses activités ou avoir obtenu un concordat judiciaire, ou se trouver dans toute situation analogue résultant d’une procédure de même nature existant dans les législations et réglementations nationales;

2°

avoir déposé une déclaration de faillite, avoir entamé une procédure de liquidation ou de concordat judiciaire ou avoir en cours une procédure de même nature existant dans les législations et réglementations nationales.

Pour les soumissionnaires Belges, le pouvoir adjudicateur demandera directement cette information via le guichet électronique. Pour le soumissionnaire étranger, l’attestation doit émaner de l’organisme administratif compétent du pays concerné, ou, à défaut, le soumissionnaire doit produire une déclaration sur l’honneur certifiée par un notaire ou par une autorité judiciaire ou administrative.

Troisième critère d’exclusion. Le soumissionnaire doit être en ordre concernant ses obligations vis-à-vis des contributions directes et de la TVA. Le soumissionnaire belge joint à son offre une attestation 276C2 récente (datant de 6 mois au maximum avant la date d’ouverture des offres) émanant de l’administration des Contributions directes ainsi qu'une attestation récente (datant de six mois au maximum avant la date d'ouverture des offres) de l'Administration de la TVA dont il dépend et mentionnant qu’il est en ordre concernant ses obligations vis-à-vis de l’administration précitée. Le soumissionnaire étranger joint à son offre une ou plusieurs attestations récentes (datant de 6 mois maximum avant la date d’ouverture des offres) émanant de l’administration / des administrations compétente(s), dans son pays, pour la perception des contributions directes et de la TVA (ou des taxes qui, dans son pays, remplacent la TVA), mentionnant qu’il est en ordre concernant ses obligations vis-à-vis de l’administration / des administrations précitée(s). Si cette attestation ou ces attestations ne sont pas délivrées dans son pays, il suffit de joindre une déclaration sur l’honneur certifiée par un notaire ou par une autorité judiciaire ou administrative de son pays.

I.17.1.2 Critère

de

sélection

relatif

aux

moyens

économiques

et

financiers

du

soumissionnaire Le soumissionnaire fournit la preuve de sa capacité économique et financière par le biais de son chiffre d'affaires relatif aux activités sur lesquelles porte le marché et réalisées au cours des trois derniers exercices comptables.

I.17.1.3 Critères de capacité technique

Premier critère relatif à la capacité technique du soumissionnaire. Le soumissionnaire prouvera la réalisation d’un projet comparable au moins (les projets réalisés au sein de la société du soumissionnaire ou au sein de la/des société(s) du/des sous-traitant(s) ne sont pas pris en compte pour ce critère). À cet effet, il fournira une liste des marchés les plus importants accomplis au cours des trois dernières années. Il fournira également une liste des projets similaires réalisés au cours de la même période, et

P. 21

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

indiquera les instances publiques et privées pour lesquelles ces projets ont été réalisés. Lorsqu'il s'agit de services aux pouvoirs publics, la preuve sera fournie par des certificats qui seront émis ou signés par l'autorité compétente. Lorsqu’il s’agit de services à des personnes privées, la preuve sera fournie par des certificats émanant de ces personnes. À défaut de ces certificats, le soumissionnaire peut certifier lui-même la réalisation de ces prestations. Le soumissionnaire précisera la date, le montant total du marché, ainsi que les coordonnées d’une personne de contact au sein de la société ou de l’organisation concernée. L’utilisation du modèle « modèle de référence » (voir annexe du cahier de charges : modèle de référence ) est obligatoire pour la présentation des références. Deuxième critère relatif à la capacité technique du soumissionnaire. Le soumissionnaire mentionnera les certificats ISO et autres certificats qu’il possède. Le pouvoir adjudicateur souhaite que le soumissionnaire soit en possession d'un certificat ISO de type 9000 (9001 ou 9002) ou équivalent. Le pouvoir adjudicateur souhaite que les sous-traitants possèdent une certification ISO de type 9000 (9001 ou 9002) ou équivalent pour l’activité qui leur est sous-traitée. Troisième critère relatif aux capacités techniques du soumissionnaire. Le soumissionnaire mentionnera tout recours à la sous-traitance avec indication de la part du marché qui est sous-traitée ainsi que le nom des sous-traitants.

I.17.2 Régularité des offres Les offres des candidats sélectionnés seront examinées sur le plan de leur régularité conformément aux articles 89 et suivants de l'arrêté royal du 8 janvier 1996 et aux dispositions du présent cahier spécial des charges. Les offres irrégulières seront exclues. Chaque proposition sera examinée afin de s’assurer qu’elle soit conforme aux besoins exprimés. S'il est déterminé qu'un besoin exprimé n'a pas été satisfait, l'offre peut être considérée comme étant irrégulière. La solution proposée dans l’offre du soumissionnaire doit satisfaire aux besoins techniques présupposés qui peuvent être trouvés dans ce cahier des charges. Chaque proposition financière ou offre de prix incomplète ou contenant des contradictions ou des erreurs importantes, ou qui ne respecte pas les exigences en matière de présentation du prix, telles que formulées dans le cahier spécial des charges, peut être considérée comme irrégulière. Seules les offres reconnues régulières seront prises en considération pour être confrontées aux critères d’attribution.

I.17.3 Critères d’attribution Le choix de l'offre la plus avantageuse sera fait par le SPF Finances sur la base des données et des renseignements qui sont joints à l'offre par le soumissionnaire et sur la base des critères décrits ciaprès. L'attribution se fera sur la base de l'offre régulière la plus intéressante, en tenant compte des critères ci-dessous. Le soumissionnaire joindra à son offre, tous les renseignements nécessaires à l'évaluation de son offre à la lumière des critères d'attribution et de leurs sous-critères éventuels, comme détaillé cidessous.

P. 22

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Les critères mentionnés ci-dessous sont les seuls qui seront utilisés pour effectuer le choix parmi les offres.

35 % 20 % 15 % 15 % 10 % 2.5 % 2.5 %

Prix Qualité de la solution ESB Qualité de l’équipe Transfert de connaissance Aspects SOA SLA proposés Qualité de l’offre

Pour être classé en ordre utile, le soumissionnaire devra atteindre une cote d’au moins 60% dans chacun des critères, hormis les critères « Prix », « SLA proposés » et « Qualité de l’offre ». Le critère « Prix» a été pondéré comme suit :

 Pr P = Pmax ×  min  Pr  offerte

   

dont : • • • •

= prix le plus bas des offres jugées régulières entrant en ligne de compte pour Prmin l’attribution du marché Profferte = prix de l’offre P = points octroyés au critère « Prix » Pmax = pondération maximale du critère « Prix »

La détermination du score final se fait comme suit: Les cotes relatives aux critères d’attribution susmentionnés, y compris celle du prix, seront additionnées. Le marché sera octroyé au soumissionnaire qui obtient le score final le plus élevé.

Le calcul du prix de l’offre (Profferte) est décrit dans l’annexe F. Nous vous rappelons que si le pouvoir adjudicateur constate des prix anormaux dans une offre de prix, il peut demander au soumissionnaire concerné de fournir les justificatifs nécessaires. Si après examen de ces justifications, le prix proposé est toujours considéré comme anormal ou en l'absence de justificatifs, le pouvoir adjudicateur pourra considérer l'offre comme irrégulière.

P. 23

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

II. Dispositions contractuelles Cette deuxième partie fixe la procédure relative à l’exécution du marché. Pour autant qu’il n’y soit pas dérogé, l’Arrêté royal du 26 septembre 1996 et ses modifications ultérieures établissant les règles générales d’exécution des marchés publics de travaux, de fournitures et de services et des concessions de travaux publics est d’application, de même que les dispositions de l’annexe à cet arrêté royal relative au cahier général des charges, et ses modifications ultérieures.

II.1 Notification de l’attribution du marché Conformément à l’article 65/8 de la loi du 23 décembre 2009 (insertion d’un nouveau livre concernant la motivation, l’information et les moyens juridiques dans la loi du 24 décembre 1993 sur les marchés publics et certains marchés d’adjudication de travaux, fournitures et services), l’instance adjudicatrice communique, immédiatement après la décision d’attribution : Extrait du §1 : 1° à chaque soumissionnaire non sélectionné, les m otifs de sa non-sélection, sous la forme d’un extrait de la décision motivée ; 2° à chaque soumissionnaire dont l’offre est décla rée irrégulière, les motifs du rejet, sous la forme d'un extrait de la décision motivée ; 3° à chaque soumissionnaire dont l’offre n’est pas choisie ainsi qu’au soumissionnaire choisi, la décision motivée. La notification visée ci-dessus comprend également, le cas échéant : 1° la mention précise de la durée exacte du terme visé à l’article 65/11, premier alinéa ; 2° la recommandation d’avertir l’instance adjudica trice dans le même délai, par télécopie, courriel ou autre moyen électronique, si l’intéressé dépose une demande de suspension conformément à l'article 65/11; 3° le numéro de télécopie ou l’adresse électroniqu e auxquels la notification visée à l’article 65/11, troisième alinéa, peut être envoyée. L’instance adjudicatrice émet cette notification sans retard, par télécopie, courriel ou autre moyen électronique ainsi que, le même jour, par lettre recommandée. § 2. La notification visée sous § 1 ne génère aucune obligation contractuelle à l’égard du soumissionnaire choisi et suspend le délai durant lequel les soumissionnaires sont tenus par leur offre, pour autant qu’un tel délai et que l’article 65/11 s'appliquent. Pour toutes les offres déposées dans le cadre de ce marché, la suspension du délai prend fin : 1° en l’absence de demande de suspension en vertu de l’article 65/11, deuxième alinéa, le dernier jour du délai visé à l’article 65/11, premier alinéa ; 2° en présence d’une demande de suspension en vert u de l’article 65/11, deuxième alinéa, le jour où l’instance de recours visée à l'article 65/15 prend sa décision ; 3° en tout cas, au plus tard le quarante-cinquième jour après la notification visée au paragraphe 1.

P. 24

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Certains renseignements ne peuvent être communiqués lorsque leur diffusion entrave l’application de la loi, compromet l’intérêt public, lèse les intérêts commerciaux légitimes d’entreprises publiques ou privées ou empêche une concurrence loyale entre entreprises.

II.2 Le bon de commande et ses modalités Le bon de commande est adressé à l’adjudicataire et ce, soit par courrier recommandé, soit par fax, soit via tout autre support permettant de définir la date d'envoi de façon certaine. Les échanges de correspondance subséquents relatifs au bon de commande (et à l’exécution des services) suivent les mêmes règles que celles prévues pour l’envoi du bon de commande chaque fois qu’une partie désire se ménager la preuve de son intervention. En cas de réception du bon de commande postérieure au délai de deux jours ouvrables, le délai de livraison peut être prorogé au prorata du retard constaté pour la réception du bon de commande, à la demande écrite et justifiée de l’adjudicataire. Si le service commandeur, après avoir examiné la demande écrite de l’adjudicataire, l’estime fondée ou partiellement fondée, il lui communique par écrit quelle prorogation de délai est acceptée. En cas de libellé manifestement incorrect ou incomplet du bon de commande empêchant toute exécution de la commande, l’adjudicataire en avise immédiatement par écrit le service commandeur afin qu’une solution soit trouvée pour permettre l’exécution normale de la commande. Si nécessaire, l’adjudicataire sollicite une prorogation du délai de l’exécution des services dans les mêmes conditions que celles prévues en cas de réception tardive du bon de commande. En tout état de cause, les réclamations relatives au bon de commande ne sont plus recevables si elles ne sont pas introduites dans les 15 jours calendrier à compter du premier jour qui suit celui où l’adjudicataire a reçu le bon de commande.

II.3 Fonctionnaire dirigeant L’exécution des services se déroule sous le contrôle du fonctionnaire dirigeant: Nom: Monsieur Louis Collet Adresse: Service d'Encadrement ICT, Boulevard du Roi Albert II 33 bte 95 à 1030 Bruxelles Téléphone: 0257/6.41.92 Fax: 0257/9.68.01 E-mail: [email protected] Le surveillant des services: Nom: Monsieur Nicolas Vanderavero Adresse: Service d'Encadrement ICT, Boulevard du Roi Albert II 33 bte 95 à 1030 Bruxelles Téléphone: 0257/81 353 Fax: 0257/9.68.01 E-mail: [email protected]

II.4 Cautionnement Le cautionnement est fixé à 5% du montant total, hors TVA, du marché. Le montant ainsi obtenu est arrondi à la dizaine d’euros supérieure.

P. 25

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Le cautionnement peut être constitué conformément aux dispositions légales et réglementaires, soit en numéraire ou en fonds publics, soit sous forme de cautionnement collectif. Le cautionnement peut également être constitué par une garantie accordée par un établissement de crédit satisfaisant au prescrit de la loi du 22 mars 1993 relative au statut et au contrôle des établissements de crédit ou par une entreprise d’assurances satisfaisant au prescrit de la loi du 9 juillet 1975 relative au contrôle des entreprises d’assurances et agréée pour la branche 15 (caution). L’adjudicataire doit, dans les trente jours de calendrier suivant le jour de la conclusion du marché, justifier la constitution du cautionnement par lui-même ou par un tiers, de l’une des façons suivantes : 1° lorsqu’il s’agit de numéraire, par le virement du montant au numéro de compte du Postchèque de la Caisse des Dépôts et Consignations (CCP n° 67 9-2004099-79, IBAN: BE58 6792 0040 9979 , BIC: PCHQBEBB) ou d’un organisme public remplissant une fonction similaire à celle de ladite Caisse, ci-après dénommé organisme public remplissant une fonction similaire ; 2° lorsqu’il s’agit de fonds publics, par le dépôt de ceux-ci entre les mains du caissier de l’Etat au siège de la Banque nationale à Bruxelles ou dans l’une de ses agences en province, pour compte de la Caisse des Dépôts et Consignations, ou d’un organisme public remplissant une fonction similaire ; 3° lorsqu’il s’agit d’un cautionnement collectif, p ar le dépôt par une société exerçant légalement cette activité, d’un acte de caution solidaire auprès de la Caisse des Dépôts et Consignations ou d’un organisme public remplissant une fonction similaire ; 4° lorsqu’il s’agit d’une garantie, par l’acte d’en gagement de l’établissement de crédit ou de l’entreprise d’assurances. Cette justification se donne, selon le cas, par la production au pouvoir adjudicateur : 1° soit du récépissé de dépôt de la Caisse des Dépô ts et Consignations ou d’un organisme public remplissant une fonction similaire ; 2° soit d’un avis de débit remis par l’établissemen t de crédit ou l’entreprise d’assurances ; 3° soit de la reconnaissance de dépôt délivrée par le caissier de l’Etat ou par un organisme public remplissant une fonction similaire ; 4° soit de l’original de l’acte de caution solidair e visé par la Caisse des Dépôts et Consignations ou par un organisme public remplissant une fonction similaire ; 5° soit de l’original de l’acte d’engagement établi par l’établissement de crédit ou l’entreprise d’assurances accordant une garantie. Ces documents, signés par le déposant, indiquent au profit de qui le cautionnement est constitué, son affectation précise par l’indication sommaire de l’objet du marché et de la référence du cahier spécial des charges, ainsi que le nom, le prénom et l’adresse complète de l’adjudicataire et éventuellement, du tiers qui a effectué le dépôt pour compte, avec la mention « bailleur de fonds » ou « mandataire », suivant le cas. Si la preuve de la caution n’est pas fournie dans le délai requis, une amende sera appliquée. L’absence de caution peut entraîner la rupture du contrat. Le délai de trente jours de calendrier visé ci-avant est suspendu pendant la période de fermeture de l’entreprise de l’adjudicataire pour les jours de vacances annuelles payées et les jours de repos compensatoire prévus par voie réglementaire ou dans une convention collective de travail rendue obligatoire. La preuve de la constitution du cautionnement doit être envoyée à l’adresse suivante : SPF Finances Service d'encadrement B&CG Division Engagements des Services d’Encadrement Boulevard du Roi Albert II 33 bte 785 1030 Bruxelles Le cautionnement est libérable à la demande après la dernière réception définitive.

P. 26

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

II.5 Caractère livrable du système proposé Les éventuels appareils, le logiciel système (sauf les pièces spécifiques développées au cours du projet) et les programmes d'application proposés doivent être officiellement disponibles et livrables lors de l'introduction de l'offre. Leur entretien éventuel doit également être disponible (il ne peut dès lors pas s'agir de versions β du logiciel, de pré-releases, etc. …).

II.6 Exécution du marché II.6.1 Clause d’évolution technologique Si, avant l'expiration du délai de livraison, une évolution technologique donne naissance à des logiciels/matériels plus avancés en termes de performances ou de fonctionnalités que ceux proposés dans l’offre et ce, sans augmentation de prix, l’adjudicataire est tenu d'en avertir le pouvoir adjudicateur et d’en proposer le remplacement. Le pouvoir adjudicateur est libre d'accepter ou de refuser la proposition.

II.6.2 Lieu d’exécution du marché et particularités II.6.2.1 L’exécution des services

L'exécution du marché se déroulera principalement dans les locaux du Service d’Encadrement ICT du SPF Finances. Si, au cours de certaines périodes, il fallait travailler en autres lieux, les frais de déplacement ne seraient en principe pas remboursés par le SPF Finances. Une partie des services peut aussi être exécutée dans les locaux de l’adjudicataire si la prestation n’est pas possible ailleurs ou si le SPF Finances en tire un avantage particulier. En vue d’une collaboration optimale avec le personnel du SPF Finances, le personnel de l’adjudicataire effectuant des prestations dans les locaux du SPF Finances doit, dans la mesure du possible, suivre le même horaire de travail que les collègues des Finances. Par “heures de bureau normales”, nous entendons les jours ouvrés, du lundi au vendredi, de 7h30 à 18h00, selon le régime d'horaire variable en vigueur au SPF Finances. Le 2 novembre, le 15 novembre et la période entre Noël en Nouvel An sont considérés comme jours fériés par le SPF Finances, ainsi que le premier jour ouvrable de l’année. Des « ponts » obligatoires sont également prévus ; ils seront communiqués chaque année.

P. 27

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

II.6.2.2 Livraisons Livraisons et installation L’adjudicataire doit fournir au SPF Finances tous les renseignements et facilités nécessaires pour que la préparation et l’exécution des livraisons puissent être contrôlées. Aucune livraison ne peut être faite sans qu'un avis en ait été donné, par écrit, aux services destinataires au moins quatre jours ouvrables avant la date d'expédition des marchandises ou de l’installation du logiciel, sauf avis contraire explicite du pouvoir adjudicateur.

L'équipement (logiciel) sera fourni et installé par l'adjudicataire, conformément à un calendrier détaillé à convenir de commun accord après l'avis d'adjudication du marché. Les locaux d’installation seront aménagés par le SPF Finances conformément aux prescriptions énoncées dans l’offre remise par l’adjudicataire.

Spécifications techniques Les livraisons et services doivent correspondre en tous points avec les plans, documents et domaines applicables à ce marché. Même en cas de défaut de spécification technique contractuelle, les livraisons et services doivent satisfaire à toutes les exigences et règles de bonne exécution. Emballages Les emballages éventuels demeurent la propriété de l’adjudicataire et sont enlevés par lui dans les dix jours calendrier à compter de la date de livraison. Passé ce délai, le SPF Finances est en droit de renvoyer ces emballages aux frais de l’adjudicataire. Le matériel sera déballé dans les locaux désignés par le destinataire et selon ses instructions. Lieu Les livraisons se feront à : Service d’Encadrement ICT Boulevard du Roi Albert II 33 à 1030 Bruxelles

II.6.3 Personnel de l’adjudicataire Pour ce marché, l’adjudicataire devra désigner un chef de projet (également décrit, dans le cadre de 1 PMfin , comme le « coordinateur de projet externe ») qui l e représentera dans ses rapports avec le SPF Finances. Le personnel de l’adjudicataire qui sera amené à réaliser le marché devra : • •

avoir une expérience dans le cadre de la solution proposée ou de solutions comparables, être en mesure de comprendre tous les textes, rapports, comptes rendus, etc. nécessaires, utilisés ou produits par les deux parties dans le cadre du présent marché, et ce tant en français qu’en néerlandais. Avoir une connaissance orale et écrite suffisante pour pouvoir communiquer en français ou en néerlandais, et si possible indifféremment dans les deux langues,

1

une méthodologie de projet unique au sein du SPF Finances qui est basée sur la méthode internationalement reconnue Prince2 P. 28

SERVICE PUBLIC FÉDÉRAL FINANCES

•

Réf.: ICT/INF/ESB

le chef de projet doit être en outre capable de communiquer oralement tant en français qu’en néerlandais. Le service d’assistance et de support technique doit en outre pouvoir communiquer avec aisance dans les deux langues.

Le personnel de l’adjudicataire devra satisfaire à toutes les dispositions légales en vigueur en Belgique en matière d'immigration et de permis de travail. L’adjudicataire garantira le SPF Finances contre tout dommage généralement quelconque que le SPF Finances pourrait subir du fait du non-respect par l’adjudicataire ou les membres de son personnel des dispositions légales en question. L’adjudicataire doit disposer de suffisamment de personnel possédant les connaissances nécessaires et adaptées à l’exécution des tâches. Le personnel concerné doit également disposer d'une connaissance suffisante des outils utilisés dans le cadre du projet. Les adjudicataires doivent être capables de répondre immédiatement aux besoins résultant de l’attribution du marché. L’équipe de projet mise à disposition par l’adjudicataire doit être suffisante afin de mener à bien les missions qui lui sont confiées. Le personnel affecté à l'exécution du marché doit être le même que celui proposé dans l'offre. A défaut, le personnel mis à disposition pour l'exécution sera de niveau et d’expérience équivalents. Le SPF Finances devra marquer son accord sur la composition de l'équipe proposée pour le projet. L'adjudicataire garantit pour toute la durée du marché, la stabilité des personnes affectées à l'exécution du présent marché. En cours d'exécution, l'adjudicataire n'apportera aucun changement dans la composition de l'équipe de projet sans l'autorisation préalable du SPF Finances. Le SPF Finances pourra réclamer le remplacement immédiat d'une ou plusieurs personnes de l'équipe de projet de l'adjudicataire si elle juge que leurs qualifications ou leurs prestations entravent la bonne exécution du marché. Le changement devra intervenir dans les 20 jours ouvrables de la demande du SPF Finances, et ce sans frais à dater de la notification de l’incident au soumissionnaire.

Les soumissionnaires doivent joindre à leur offre, le curriculum vitae (obligatoire selon le modèle de « curriculum vitae ») des personnes amenées à réaliser le marché. L’offre devra contenir une proposition claire concernant la composition réelle de l’équipe de projet et le type de profils qui participeront à la réalisation du marché. Un certain nombre de personnes pourront être proposées par profil, mais le soumissionnaire devra indiquer combien et quels membres du personnel feront partie de l’équipe de projet réelle. La liste des membres du personnel proposés (effectifs et suppléants éventuels) sera considérée comme une liste exhaustive comprenant tous les membres du personnel susceptibles de faire partie de l’équipe de projet.

II.6.4 Sous-traitants L’adjudicataire assumera l'entière responsabilité de la livraison de tous les produits et services visés dans ce marché. Le recours à des sous-traitants n'exonère pas l’adjudicataire de ses responsabilités quant aux prestations attendues dans le cadre du marché. En cas de changement de sous-traitant par rapport à l’offre, l'adjudicataire informera le SPF Finances qui devra marquer son accord avant que l’adjudicataire puisse procéder au changement. Le fait que le prestataire de services confie tout ou partie de ses engagements à des tiers ne l'exonère pas de sa responsabilité envers le SPF Finances. Celui-ci ne se reconnaît aucun lien contractuel avec ces tiers.

P. 29

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

II.6.5 Moyens mis à disposition par le SPF Finances II.6.5.1 Moyens techniques L’adjudicataire mettra à disposition de son personnel tout le matériel nécessaire à l’exécution de sa mission (ordinateur portable, etc.). On applique le principe que le SPF Finances mettra simultanément à la disposition des membres du personnel au cours de leur mission, au maximum trois bureaux de type "shared desk", sans armoires. Le personnel de l’adjudicataire dispose d’un accès limité au réseau du SPF Finances, ainsi que d’une adresse e-mail. Le SPF Finances ne dispose pas d’emplacements de parking pour le personnel de l’adjudicataire. Le SPF Finances n'effectuera aucune adaptation aux postes de travail des membres du personnel de l'adjudicataire afin de les faire mieux fonctionner au sein de l'infrastructure du SPF Finances. L'adjudicataire ne peut en aucun cas modifier, perturber ou surcharger l'infrastructure du SPF Finances par l'ajout de postes de travail pour son personnel dans cette infrastructure, sauf pour ce qui est directement associé au développement de l'application concernée. L'adjudicataire est intégralement responsable de la protection des postes de travail concernés contre les virus et de la gestion de ces postes. Il utilisera de manière prioritaire les outils mis à sa disposition par le SPF Finances. Au cas où d'autres logiciels devraient être utilisés dans le cadre du projet, leur utilisation se déroulera, après acceptation par le comité de pilotage, sous la responsabilité de l'adjudicataire et le coût de cette utilisation sera compris dans le prix des services. Le personnel de l’adjudicataire devra suivre les procédures internes et les règlements relatifs à l’utilisation des moyens mis à sa disposition et à leur accès, et ne peut exiger aucun ajout ou modification à l’environnement de travail du pouvoir adjudicateur. Si des manquements dans le soutien logistique entraînent des perturbations de service, il devra être fait appel aux moyens d’arbitrage décrit dans le point « Moyens d’actions de l’administration – Litiges » avant de faire appel au droit.

II.6.5.2 Tâches des collaborateurs du SPF Finances Les collaborateurs du SPF Finances participent au(x) projet(s) pour ce qui concerne : • • • • • •

la définition du contenu du/de chaque projet ; la participation au choix de solutions : architecture, etc. ; la validation des documents de réalisation : dossiers de spécification, dossiers de réalisation, dossiers d’acceptation, dossier de tests, manuels d’utilisation, manuels de maintenance, etc. ; les contrôles de la qualité, notamment le contrôle de la concordance de la documentation avec la réalisation, du respect des normes en matière de documentation et de programmation, etc. ; le cas échéant : la participation obligatoire aux tests de réception (aspects techniques et fonctionnels), indépendamment du fait qu’il s’agisse de tests de fonctionnement unitaires, de tests d’intégration ou de tests concernant le fonctionnement général ; le support logistique aux équipes d’exécution, en ce qui concerne la mise à disposition des moyens techniques nécessaires à la réalisation selon ce qui sera déterminé en concertation.

La réalisation sera suivie de très près, étape après étape, par les collaborateurs du SPF Finances, qui, avec l’aide nécessaire de l’adjudicataire, seront chargés de contrôler (et, si nécessaire, de définir) les normes et standards sur le plan (où cela s’applique) de l’architecture, des règles d’application, des procédures de travail, de la documentation, de la programmation, etc. Ils doivent également veiller à ce que les normes soient strictement respectées, de façon à ce que les solutions implémentées puissent ensuite être reprises dans leur intégralité et sans problème spécifique par le SPF Finances.

P. 30

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

II.6.6 Normes et standards à respecter Les équipes de réalisation mis à disposition par l'adjudicataire au SPF Finances appliqueront les méthodes et les standards spécifiés par le SPF Finances ou ceux choisis avec son accord. Ces standards concernent au minimum : • • • • • •

les normes techniques pour logiciels ; la méthode de gestion de projet (PMFin, une méthodologie de projet unique au sein du SPF Finances qui est basée sur la méthode internationalement reconnue Prince2) ; la tenue de la documentation ; les règles de programmation (création, structures des codes, commentaires, conventions en matière de dénomination, standards de développement conformément aux fondements ICT, y compris les Standards ouverts, etc.); les règles de gestion définies par les services de gestion des environnements d'exploitation ; les procédures pour les garanties de base

Toutes les normes utilisées par le SPF Finances figurent dans un document explicatif, disponible sur http://minfin.fgov.be/portail1/fr/cadrefr.htm (sous « ICT et plans informatiques ») et http://minfin.fgov.be/portail1/nl/cadrenl.htm (onder “ICT en informaticaplan”) . Toute référence à quelque norme ou méthodologie que ce soit dans le présent cahier des charges dépend de la description exacte dans le document officiel présent sur ce site. Seul le comité tactique est compétent au sein du SPF Finances pour modifier ou ajouter des normes et méthodologies. Si l’adjudicataire a besoin de l’approbation d’une nouvelle norme, il devra en introduire la demande auprès du comité tactique et entièrement se soumettre à sa décision.

II.6.7 Gestion des changements (« change management ») Généralités A tout moment lors de l’exécution du contrat, le SPF Finances peut proposer au prestataire de services de modifier, de développer ou de limiter n’importe quel aspect de l’exécution du contrat, entre autres le contenu des services (« proposition de modification » dans PMFin request for change). Des activités ou des aspects qui ont pu être anticipés ou prévus par le prestataire de services lors de la remise de son offre, ou encore qui en font raisonnablement partie, sont inclus dans l’exécution du contrat et ne pourront donc pas faire l’objet d’une proposition de modification. Le prestataire de services ne pourra refuser une proposition de modification émise par le SPF Finances si la modification en question entraîne une réduction des coûts ou des volumes. Tant qu’une proposition de modification n’est pas entérinée de manière formelle par les parties (ainsi que par le comité de pilotage) et sauf si les parties ont conclu un autre accord par écrit, le prestataire de services continuera à exécuter le contrat comme s’il n’existait pas de proposition de modification. Le prestataire de services sera seul responsable pour toute avarie ou perte résultant de l’exécution d’une modification pour laquelle le SPF Finances n’avait pas donné son aval préalable par écrit.

Modalités Le prestataire de services assure qu’il disposera toujours des moyens humains et matériels nécessaires à l’exécution de modifications. Une modification ne peut donner lieu à une adaptation de prix que si elle implique un surcoût matériel avéré dans le chef du prestataire de services. Le prestataire de services ne facturera aucun coût additionnel pour l’étude ou la préparation d’un rapport sur une proposition de modification.

P. 31

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Procédure Sous réserve des articles 7 et 8 de l’arrêté royal du 26 septembre 1996 fixant les règles générales d’exécution des marchés publics, une modification de contrat ne sera contraignante que si elle a été proposée, traitée et entérinée conformément à la présente disposition. Si une des parties désire apporter des modifications au contrat, elle devra transmettre les détails de cette modification à l’autre partie par écrit. Si le SPF Finances propose une modification, le prestataire de services devra transmettre au SPF Finances, dans un délai raisonnable et sans surcoût, une estimation du temps nécessaire prévu pour la mise en œuvre de la modification et de l’effet attendu de ladite modification au niveau du contrat. Si le SPF Finances décide de ne pas appliquer cette modification, aucune modification ne sera apportée au contrat. Si le SPF Finances désire appliquer cette modification et si les deux parties acceptent la proposition de modification, elles définiront conjointement la modification ainsi que les conséquences de cette modification au niveau des modalités d’acceptation dans une « annexe au contrat » qu’elles signeront. Le prestataire de services exécutera immédiatement la modification convenue conformément aux stipulations de cette annexe. Si le prestataire de services demande une modification, la SPF Finances ne devra pas refuser ou différer son autorisation de manière inconsidérée. Si les deux parties acceptent la proposition de modification, elles définiront conjointement la modification ainsi que les conséquences de cette modification au niveau des modalités d’acceptation dans une « annexe au contrat » qu’elles signeront. Le prestataire de services exécutera immédiatement la modification convenue conformément aux stipulations de cette annexe.

II.6.8 Engagements particuliers concernant les informations reçues Tous les résultats et rapports produits par l’adjudicataire pendant l'exécution de ce marché, constituent la propriété du pouvoir adjudicateur et ne peuvent être publiés ou communiqués à des tiers, sauf accord écrit préalable de la part du pouvoir adjudicateur. L'exécutant des services et ses collaborateurs sont tenus au secret professionnel quant aux informations qu'ils auraient pu obtenir lors de l'exécution de ce marché. Ces informations ne pourront en aucun cas être communiquées à des tiers sans accord écrit de la part du pouvoir adjudicateur. L’adjudicataire est autorisé à mentionner le présent marché dans ses références. Tous les renseignements dont le personnel d e l’a dj udic ata ir e sera amené à prendre connaissance dans le cadre de sa mission, tous les documents qui lui sont confiés et toutes les réunions auxquelles il participe sont considérés comme strictement confidentiels. Les informations dont il s’agit: • •

•

peuvent être enregistrées sur n'importe quel type de support d'information, comme le papier, un film, une bande magnétique, un disque, une disquette, un montage intégré, etc. ; peuvent être communiquées à l’adjudicataire oralement, par une démonstration et/ou par la transmission d'un support d'information qui contient l'information considérée ou peuvent venir à la connaissance de l’adjudicataire à l'occasion de l'exécution du présent marché ou d'une mission confiée par le SPF Finances dans le cadre du présent marché ; peuvent, dans leur totalité ou en partie, consister en, par exemple, études, modes d'emploi, plans de conception, plans de fabrication, descriptions techniques, plans de détail, spécifications fonctionnelles, procédures, programmes d'ordinateur, codes exécutables, calculs, etc.

P. 32

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

L’adjudicataire s’engage à garder secrètes, tant pendant qu’après l’exécution du marché, toutes ces informations confidentielles, de quelque ordre que ce soit, qui lui seront communiquées ou dont il aura eu connaissance au cours de sa mission. L’adjudicataire se porte garant du respect de la confidentialité de ces informations par son personnel et ses sous-traitants. Il s’engage à ne pas les divulguer à des tiers, en ce compris les filiales et autres entreprises liées à l’adjudicataire. Il ne communiquera à son personnel et à celui de ses sous-traitants directement impliqués au marché, uniquement les données nécessaires à l'exécution de leur tâche, dans le cadre du présent marché. Les obligations énoncées ci-dessus ne sont pas applicables aux informations du SPF Finances : • • • •

dont l’adjudicataire peut démontrer par un moyen acceptable par le SPF Finances qu'elles étaient déjà en sa possession au moment où elles lui ont été communiquées pour la première fois par le SPF Finances ; qui, au moment où elles ont été connues par le SPF Finances, étaient déjà publiques ; qui, après qu'elles aient été connues par le SPF Finances, ont été rendues publiques autrement que par le fait de l’adjudicataire ; ou que l’adjudicataire a obtenues d'un tiers qui disposait de bonne foi des informations du SPF Finances et qui était autorisé à les communiquer à l’adjudicataire.

L’adjudicataire s'engage : • •

à ne pas copier tout ou partie de l'information du SPF Finances, si celle-ci se trouve sur un support mis à disposition par le SPF Finances ; à, d'autre part, ne pas saisir tout ou partie de l'information du SPF Finances sur un support quelconque, sauf pour l'exécution des missions qui lui sont confiées par le SPF Finances, et ce uniquement si cela s’avère nécessaire.

Toute l'information mise à la disposition de l’adjudicataire par le SPF Finances et tout support d'information, contenant de l'information du SPF Finances, mis à la disposition de l’adjudicataire par le SPF Finances reste l'entière propriété du SPF Finances. Même si l’adjudicataire a copié ou consigné ces informations ou une partie de celles-ci, elles demeurent la propriété intégrale du SPF Finances. Le SPF Finances a le droit, à tout moment, de demander à l’adjudicataire de lui remettre tout ou partie des supports d’information sur lesquels l’adjudicataire aura stocké de l’information du SPF Finances. L’adjudicataire s’engage à remettre immédiatement les supports réclamés sans les copier. L’adjudicataire s’engage à remettre au SPF Finances, à l’issue de l’exécution du marché et sans délai, tous les supports d’information qui contiennent de l’information du SPF Finances et qui ont été mis à la disposition de l’adjudicataire pour l’exécution du marché, pour autant que ces supports d’information n’aient pas déjà été remis au SPF Finances. Toute information du SPF Finances restera la propriété du SPF Finances. Par la mise à disposition d’informations du SPF Finances, celui-ci ne concède à l’adjudicataire, ni explicitement ni implicitement, aucun droit à licence sur les droits de brevet, droits d’auteur ou autres droits intellectuels. L’adjudicataire s'engage à ne pas appliquer industriellement l'information du SPF Finances et à ne pas l'utiliser pour d'autres fins que l'exécution du présent marché ou d'une mission à lui confiée par le SPF Finances dans le cadre du présent marché. L’adjudicataire est responsable de tout dommage dont le SPF Finances serait victime du fait du nonrespect par lui-même ou par les membres de son personnel d’obligations qui lui incombent en vertu du présent article.

P. 33

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

II.6.9 Responsabilités Responsabilité Fournitures Le fournisseur est responsable de ses fournitures jusqu'au moment où les opérations de vérification de la livraison sont effectuées, sauf si les pertes ou avaries survenant dans les dépôts du destinataire sont dues à des faits ou circonstances visés à l'article 16 du Cahier Général des Charges.

Responsabilité Services Le prestataire de services assume la pleine responsabilité des fautes et des omissions constatées dans les services fournis, spécialement dans les études, les calculs, les plans ou toute autre pièce qu’il fournit dans le cadre de l’exécution du marché. En outre, le prestataire de services garantit le pouvoir adjudicateur contre toute action en dommages et intérêts intentée par des tiers en raison de son retard ou de sa défaillance. Le prestataire de services garantit que tous les services qui devront être exécutés dans le cadre du contrat seront exécutés conformément aux meilleures normes professionnelles, par un personnel suffisamment formé et compétent, en respectant les délais prévus. Le prestataire de services est responsable du niveau de qualité des prestations exécutées et s’engage à mettre tout en œuvre afin de réaliser les objectifs de la mission qui lui est assignée dans le cadre de l’exécution du marché. Sur la base de l’article 1384 du Code civil, le prestataire de services est en tous cas responsable de tout fait ayant un rapport avec les activités exercées pour le compte du SPF Finances commis par des membres de son personnel.

II.7 Durée Le déroulement des missions principales du projet se fera selon le plan suivant : • • •

•

Étape 1 : En parallèle à l’évaluation du niveau de maturité SOA du SPF Finances, l’adjudicataire mettra en place la solution ESB en collaboration avec les équipes internes Étape 2 : L’adjudicataire démontrera le bon fonctionnement de la solution ESB en réalisant un proof-of-concept du projet pilote en collaboration avec les équipes internes Étape 3 : Une fois la faisabilité technique validée via le proof-of-concept, l’adjudicataire entamera ensuite la réalisation complète du projet pilote en collaboration avec les équipes internes Étape 4 : L’adjudicataire effectuera une nouvelle évaluation du niveau de maturité SOA du SPF Finances et présentera les évolutions par rapport au niveau évalué lors de l’étape 1. Il rédigera ensuite des recommandations sur les actions à entreprendre pour continuer à améliorer le niveau de maturité SOA

Les missions principales devront être terminées au plus tard 12 mois après le kick-off du projet.

P. 34

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

II.8 Suivi des services prestés et contrôles par des tiers II.8.1 Suivi de la bonne exécution du marché Le SPF Finances a le droit de maintenir une surveillance permanente sur les livraisons et les services qui sont exécutés par l’équipe impliquée dans l’exécution du marché. L’équipe d’exécution doit fournir aux représentants du SPF Finances tous les renseignements et facilités afin de remplir cette tâche. Les plans, spécifications, dossiers, etc. sont établis, dans le cadre de ce marché, par le personnel de l’adjudicataire. Ils doivent avoir été approuvés par le SPF Finances avant exécution. Le SPF Finances dispose d’un délai de 30 jours calendrier afin d’approuver ces documents ou de formuler des remarques. En cas de remarques, les documents concernés doivent être corrigés avant l'exécution et sans que ces corrections n'aient comme conséquence une révision des délais d'exécution planifiés, à moins que les remarques ne proviennent de nouvelles exigences de la part du SPF Finances. Tout dépassement du terme planifié pour l’acceptation d’un document mène, à la demande de l’adjudicataire concerné, à un prolongement du délai d’exécution. Le fait qu'un retard puisse être imputé au SPF Finances ne dégage pas l'adjudicataire de son obligation de veiller à en réduire les conséquences. L’adjudicataire ne peut pas faire appel au fait que cette surveillance a été exécutée, dans le but de se soustraire à sa responsabilité au cas où les fournitures ou les prestations seraient refusées pour cause de manquements de quelque nature que ce soit et que dès lors des délais d’exécution prolongés en découleraient.

II.8.2 Contrôles par des tiers Afin d'évaluer les services prestés et le suivi du projet, le pouvoir adjudicateur peut faire appel à un tiers. L'adjudicataire est tenu de collaborer avec la partie tierce et lui fournir toute l'information afin de permettre le bon déroulement de ces activités de contrôle. Dans ce cadre, le SFP Finances souhaite mettre l’offre de l’adjudicataire à la disposition des personnes internes et externes au SPF chargées de l'évaluation et du contrôle. Les soumissionnaires doivent dès lors indiquer clairement quelles sont les parties de leur offre qui ne peuvent être mises à la disposition de personnes externes au SPF et chargées de l'évaluation et du contrôle. Si le soumissionnaire ne prend aucune décision en la matière dans son offre, cela sera interprété comme une absence de limites de sa part dans le cadre du « contrôle par des tiers », l’intégralité de son offre pouvant être mise à disposition des personnes externes chargées de l’évaluation et du contrôle.

II.9 Evaluation des services prestés et opérations de vérification Si pendant l’exécution des services, des anomalies sont constatées, ceci sera immédiatement notifié à l’adjudicataire par télécopieur ou par courriel, confirmé par la suite au moyen d’une lettre recommandée. L'adjudicataire est tenu à ré-exécuter les services effectués qui ne seraient pas conformes. Au moment où les services auront été exécutés, on procédera à l’évaluation de la qualité et de la conformité des services exécutés. Un procès-verbal de cette évaluation sera établi, dont

P. 35

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

l’exemplaire original sera transmis à l’adjudicataire. Les services qui auront été exécutés incorrectement et/ou pas conformes devront être recommencés.

II.10 Réception provisoire A l’issue des opérations de vérification qui se sont déroulées avec succès, le SPF Finances dressera un procès-verbal de réception provisoire des équipements couverts par l'étape concernée. Le procèsverbal de livraison provisoire sera signé par les deux parties. Si les services qui font partie de ce marché se composent de prestations purement intellectuelles, telles que des études, analyses ou autres rapports de consultance, la réception provisoire sera considérée comme réception définitive. La (les) réception(s) provisoire(s) (partielle(s)) aura (auront) lieu au(x) moment(s) suivant(s) : • •

•

Étape 2 : L’adjudicataire démontrera le bon fonctionnement de la solution ESB en réalisant un proof-of-concept du projet pilote en collaboration avec les équipes internes Étape 3 : Une fois la faisabilité technique validée via le proof-of-concept, l’adjudicataire entamera ensuite la réalisation complète du projet pilote en collaboration avec les équipes internes Étape 4 : L’adjudicataire effectuera une nouvelle évaluation du niveau de maturité SOA du SPF Finances et présentera les évolutions par rapport au niveau évalué lors de l’étape 1. Il rédigera ensuite des recommandations sur les actions à entreprendre pour continuer à améliorer le niveau de maturité SOA

Dans le cas où la réception provisoire partielle d'une étape a un impact sur une étape qui a été réceptionné avant, les modifications devront y être apportées aux frais de l’adjudicataire avant que le SPF Finances accepte la réception provisoire partielle de cette étape. Après chaque réception provisoire partielle commence la période de garantie de l’étape pour une période de un an.

II.11 Garantie Dans cette section, le terme « élément » fait référence à toute méthodologie, équipement ou logiciel et, par extension, à tout ce qui relève de la période de garantie et/ou de maintenance et qui a été développé/livré par l’adjudicataire et fait partie du présent marché. Le délai de garantie de chaque élément du marché est fixé à un an minimum à compter de la date de la réception provisoire. Si des éléments sont défectueux, si les fonctions et/ou les prestations et/ou le respect du SLA (Service Level Agreement – accord sur le niveau des services), prescrits dans le cahier des charges ou annoncés dans l’offre de l’adjudicataire, ne sont pas satisfaisants ou ne le sont qu’en partie, dans la mesure où les défauts ne sont pas la conséquence d’une utilisation anormale des éléments, l’adjudicataire s'engage à effectuer toutes les réparations ou corrections nécessaires à ses frais ou à remplacer, le cas échéant, les éléments défectueux dans les délais indiqués dans les spécifications du SLA. Le délai de garantie complet s’applique aux éléments à remplacer. Pendant les périodes de garantie, les sanctions relatives au SLA s’appliquent.

P. 36

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

En cas de non-disponibilité de la solution pendant la période de garantie, celle-ci sera prolongée d’une durée équivalente à cette non-disponibilité. La garantie couvre notamment : • la réparation ou le remplacement, sur site, des éléments défectueux ; • la correction des paramètres ; • le renforcement du système si celui-ci ne répond pas au SLA réalisé au préalable ; • la durée des travaux prestés ; • les déplacements du personnel de l’adjudicataire. Le soumissionnaire doit veiller à mettre à jour les éléments pendant la période de garantie. Ces mises à jour se rapportent tant à d’éventuelles ‘corrections’ qu’aux évolutions de l’élément installé.

II.12 Réception définitive La réception définitive sera prononcée à la demande de l’adjudicataire, après l’expiration du délai de garantie et au moins un an après la réception provisoire de la dernière étape, pour autant que le SPF Finances n’ait pas émis, pendant cette période, de plaintes quant au bon fonctionnement. Dans ce dernier cas, la réception définitive sera remise jusqu'au moment où le système aura fonctionné de manière correcte pendant une période ininterrompue d'un an. La réception définitive sera enregistrée dans un procès-verbal signé par l’adjudicataire et par le SPF Finances. Le SPF Finances dispose d'un délai de 15 jours calendrier, à compter de la demande, pour dresser le procès-verbal d'acceptation qui donne l'autorisation de réception. Aucun paiement n'est prévu à la réception définitive.

II.13 Modalités et frais de réception Modalités de réception Les services seront suivis de près pendant leur exécution et ce, par un ou plusieurs représentants du pouvoir adjudicateur.

Frais de réception Tous les frais se rapportant à la livraison et à la (aux) réception(s) provisoire(s) et/ou définitive(s) sont à charge de l’adjudicataire.

II.14 Propriété des softs développés Propriété intellectuelle Les droits de propriété intellectuelle et industrielle relatifs notamment aux dessins, modèles, œuvres et/ou documents littéraires (enregistrés de manière durable ou en langage de machine), rapports, logiciels et bases de données, ainsi que les méthodes, le savoir-faire, les concepts et autres développements dont le SPF Finances est propriétaire ou détenteur de licence, continueront à appartenir au SPF Finances en tant que propriétaire ou détenteur de licence (ci-après dénommé la « propriété intellectuelle de l’Administration »). Tous les droits de propriété intellectuelle qui découlent d’une modification ou d’une adaptation de la propriété intellectuelle de l’Administration reviennent automatiquement au SPF Finances. P. 37

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Le prestataire de services s’engage à documenter de manière précise toute modification ou adaptation. Toute la documentation, sous quelque forme que ce soit, qui concerne ces modifications ou adaptations de la propriété intellectuelle de l’Administration, est considérée comme en faisant partie intégrante. Les droits de propriété intellectuelle et industrielle relatifs notamment aux dessins, modèles, œuvres et/ou documents littéraires (enregistrés de manière durable ou en langage de machine), rapports, logiciels et bases de données, ainsi que les méthodes, le savoir-faire, les concepts et autres développements, que le prestataire de services, et/ou le(s) sous-traitant(s) désigné(s) par le prestataire de services crée(nt) dans le cadre de l’exécution du marché sont ci-après dénommés « développements spécifiques ». Les droits de propriété intellectuelle et industrielle relatifs notamment aux dessins, modèles, œuvres et/ou documents littéraires (enregistrés de manière durable ou en langage de machine), rapports, logiciels et bases de données, ainsi que les méthodes, le savoir-faire, les concepts et autres développements, que le prestataire de services utilise dans le cadre de l’exécution du marché et qui sont la propriété du prestataire de services et/ou du (des) sous-traitant(s) désigné(s) par le prestataire de services, ou qui sont la propriété de tiers, sont ci-après dénommés « Autres composants ». Immédiatement après leur création, les « développements spécifiques » appartiennent au SPF Finances en propriété pleine et exclusive. Si nécessaire, afin de permettre au SPF Finances d’utiliser, d’adapter, de (faire) maintenir (par des tiers) et/ou de reproduire les développements spécifiques, le prestataire de services s’engage et/ou se fait fort d’octroyer au SPF Finances, en ce qui concerne les autres composants utilisés pendant et après l’exécution du marché, une licence non exclusive, transmissible, universelle, irrévocable et susceptible de sous-licence, pour la durée de la protection légale des droits de propriété intellectuelle en vue de l’utilisation, de la modification et de la reproduction des autres composants. Le prestataire de services renonce à utiliser les développements spécifiques de quelque manière que ce soit à d’autres fins que l’exécution du présent marché sans l’accord préalable, écrit et exprès du SPF Finances ; il veillera à ce que ses employés, agents et sous-traitants soient également liés par cette obligation. Le prestataire de services s’engage à mettre à la disposition du SPF Finances et à maintenir à jour en permanence pour lui, sans frais supplémentaires, la documentation (y compris toutes les spécifications techniques pertinentes) et, dans le cas de logiciels, aussi le code source des développements spécifiques sous forme d’un environnement de développement et de production utilisable. Les indemnités que le SPF Finances paie pour la fourniture des services comprennent les indemnités pour le transfert ou le droit d’utilisation de ces droits de propriété intellectuelle. Garanties Le prestataire de services s’abstiendra d’exiger, n’importe où dans le monde, le droit de propriété intellectuelle des développements spécifiques ou de prétendre y avoir droit de quelle que manière que ce soit, de soumettre une demande de brevet ou de toute protection similaire. Il veillera à ce que ses travailleurs, agents et sous-traitants soient aussi liés par cette obligation. Le prestataire de services garantit qu’il possède tous les droits et toutes les autorisations nécessaires pour transférer les droits de propriété intellectuelle décrits ci-dessus ou d’en permettre une licence d’utilisation. Le prestataire de services s’engage à fournir au SPF Finances toute l’assistance requise, à remplir les formalités qui s’imposent et à entreprendre les démarches nécessaires afin d’assurer et de prouver la validité de la cession des droits précités. Le prestataire de services s’engage à et se fait fort de faire respecter cette obligation par ses employés, ses préposés et d’éventuels sous-traitants. Le prestataire de services informera le SPF Finances de tous les autres composants utilisés lors de la fourniture des services.

P. 38

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Le prestataire de services garantit que les droits conférés concernant les développements spécifiques et les autres composants ne porteront pas atteinte aux droits intellectuels et autres d’un tiers. Si une action est intentée par un tiers en raison d’une prétendue violation du droit de propriété intellectuelle ou autre de ce tiers par n’importe quelle personne à la suite de la fourniture ou de l’utilisation des services, le prestataire de services fournira, à la première requête du SPF Finances, toutes les informations possibles, ainsi qu’une aide et une assistance (notamment l’intervention volontaire dans une procédure à la première requête du SPF Finances) pour permettre au SPF Finances d’organiser sa défense de manière effective et efficace. Le prestataire de services supportera tous les frais découlant d’une telle accusation (frais d’avocat y compris). Si le SPF Finances doit, à la suite d’une telle action, payer une amende et/ou des dommages et intérêts, le prestataire de services prendra ce paiement à sa charge. Si, à la suite d’une telle action, les services ne peuvent plus être fournis avec succès ou si un service fourni ne peut plus continuer à exister avec succès, le prestataire de services, après concertation avec le SPF Finances et à ses frais, se chargera de les rétablir. Sans porter préjudice à l’obligation du prestataire de services de garder secrètes les informations sur le présent marché et les informations confidentielles, le prestataire de services a le droit de réutiliser le savoir-faire ou l’expérience qu’il a acquis(e) dans le cadre de l’exécution du marché à d’autres fins que l’exécution du marché.

II.15 Dépôt chez un séquestre Dans le cadre de l’exécution du présent marché et des mesures transitoires, le prestataire de services devra, au plus tard 30 jours après la signature du PV de réception provisoire, déposer auprès d’un séquestre le code source des développements spécifiques. Il en fera de même pour chaque modification ou mise à jour de ceux-ci et de la documentation technique (appelée « matériel déposé ») y afférent, sous la forme d’un environnement utilisable, à l’intention du SPF Finances. Après signature du contrat, le prestataire de services informera le SPF Finances aussi rapidement que possible quant aux développements spécifiques provenant de tiers qui sont utilisés pour fournir les services. De commun accord avec le SPF Finances, il sera alors spécifié quelles règles devront être adoptées et quelles garanties complémentaires devront être demandées le cas échéant à ces tiers pour assurer la continuité du droit d’utilisation de ces développements spécifiques en tant que part desdits services et ce, aussi bien pendant l'exécution de ce marché que dans la perspective d'une transition éventuelle. Pour autant que cela s’avère raisonnablement nécessaire, le prestataire de services se fera fort d’obtenir de ces tiers qu’ils déposent chez un séquestre le code source des développements spécifiques utilisés pour la prestation des services et ce, sous les mêmes conditions spécifiées dans le présent article. Le prestataire de services est entièrement responsable de la consignation du matériel déposé. Le prestataire de services veillera à ce que la version du matériel déposé chez le séquestre soit toujours à jour et sous la forme d’un environnement utilisable. Le SPF Finances a le droit de faire vérifier à tout moment le contenu du matériel déposé. L’indemnité payée par l’Administration publique pour la fourniture des services englobe les services du séquestre et les coûts liés à la création et à la consignation du matériel déposé.

P. 39

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

II.16 Facturation, paiement et révision des prix II.16.1 Facturation et paiement Dans la mesure où le pouvoir adjudicateur est en possession d’une facture régulièrement établie (avec mention de la TVA et du numéro du bon de commande correspondant), accompagnée du procès-verbal de réception provisoire, la procédure est la suivante : • • •

Pour les fournitures et services, tout le montant dû est facturé à la réception provisoire. Les acomptes ne sont pas possibles ; les paiements ne peuvent être effectués qu’a posteriori, pour des fournitures ou services déjà livrés et acceptés. Les paiements périodiques relatifs à la maintenance seront facturés par échéances annuelles. Les droits de licence sont facturés chaque année au début du terme. Les frais relatifs aux services (complémentaires / auxiliaires) prestés peuvent être facturés dès leur achèvement et leur acceptation (joindre PV de réception avec time-sheet)

La facture doit être établie en euros. L'adjudicataire envoie ses factures (en deux exemplaires) à l'adresse suivante : SPF Finances Gestion des Engagements des Services d’Encadrement North Galaxy B 22 Boulevard du Roi Albert II, 33, boîte 785 1030 Bruxelles

Le paiement est effectué dans les 50 jours calendrier à dater de la réception de la facture. Les intérêts de retard seront calculés conformément à l'article 15, §4 du cahier général des charges.

II.16.2 Révision des prix Pour les fournitures, aucune révision de prix n'est autorisée. La révision des prix des services est possible. Les règles de révision sont les suivantes : Les prix peuvent être revus annuellement. Chaque année, le prestataire demande la révision du prix par lettre recommandée adressée au Pouvoir Adjudicateur, Service d'encadrement B&CG, Division Engagements, bd Roi Albert II 33 bte 785, 1030 Bruxelles. La révision des prix entre en vigueur : o

o

le jour anniversaire de l'avis d'attribution du marché si le prestataire a introduit sa demande de révision avant cette date. La révision des prix ne concerne que les services effectivement prestés après l'anniversaire de l'attribution du marché. le 1er jour du mois qui suit l'envoi de la lettre recommandée si le prestataire a laissé passer un ou plusieurs anniversaires. La révision des prix ne concerne que les services effectivement prestés après la date visée ci-dessus (attention : le prestataire de services doit introduire une nouvelle demande pour la révision des prix des services à prester après l'anniversaire suivant).

P. 40

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

La révision des prix se calcule suivant la formule :

  S P = P0 *  0,8 * + 0.2  S0   où : P = prix revu P0 = prix initial S0 = indice salarial AGORIA (seulement pour les prestataires belges ; les prestataires étrangers doivent proposer un indice analogue) - moyenne nationale, charges sociales comprises, pour les contrats à partir du 11/07/1981, valable le mois qui précède l'ouverture des offres. S = comme S0 ci-dessus, mais valable le mois qui précède le jour anniversaire de la notification de l'attribution du marché. Pour les indices, voir : http://www.agoria.be Le pouvoir adjudicateur se réserve le droit de revoir les prix en cas de baisse de l'indice. Dans ce cas, la révision suit les règles ci-dessus, sauf que la lettre recommandée émane du pouvoir adjudicateur.

II.16.3 Clause du client le plus avantagé L’adjudicataire considérera le SPF Finances comme étant le client le plus favorisé. Si le marché court sur plusieurs années, l’adjudicataire adaptera chaque année, à partir de la deuxième année de l'exécution du contrat, les prix pour ce marché, en appliquant les prix les plus bas qu'il propose pour des prestations similaires aux autres clients en Belgique, pour autant que ces prix les plus bas soient inférieurs aux prix à l'unité valables au début du marché. Les déclarations faites à ce sujet par l’adjudicataire, qui sont déterminantes pour le respect de cette obligation, pourront être vérifiées dans les livres de l’adjudicataire par un auditeur, payé par le SPF Finances, pendant les heures de bureau et sans déplacement des documents pertinents. L'auditeur se limitera à certifier ou à ne pas certifier les données pertinentes. Si l'auditeur conclut à la non certification, l’adjudicataire disposera de 30 jours civils pour adapter les prix. Cette adaptation des prix peut se faire une seule fois par an.

II.17 Publicité - référencement Aucun avis, communiqué de presse, rapport informationnel de recherche, et/ou avis public semblable concernant ce projet ne peut être publié par l’adjudicataire ou par ses sous-traitants sans approbation écrite préalable d'un représentant autorisé du SPF Finances.

II.18 Livraisons en retard L'adjudicataire peut se prévaloir des carences, lenteurs ou faits quelconques qu'il impute au pouvoir adjudicateur ou à ses agents et qui lui occasionnent un retard et/ou un préjudice, en vue d'obtenir la prolongation des délais d'exécution, la révision ou la résiliation du marché et/ou des dommagesintérêts.

P. 41

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Le pouvoir adjudicateur peut se prévaloir des carences, lenteurs ou faits quelconques qu'il impute à l'adjudicataire ou à son personnel et qui lui occasionnent un retard et/ou un préjudice, en vue d'obtenir la révision ou la résiliation du marché et/ou des dommages-intérêts. Sous réserve des prescriptions concernant les mesures prévues d’office aux articles 20, 66 et 75 du Cahier général des charges, et si la livraison d’une phase déterminée n’a pas eu lieu trois mois après la date d’exécution convenue, et si l’adjudicataire n’a pas, dans l’intervalle, obtenu une prolongation du délai de livraison, l’Administration se réserve le droit de renoncer au marché (cf. article 9, A.R. du 26 septembre 1996). Dans ce contexte, la livraison doit être considérée comme une livraison de biens et de services.

II.19 Moyens de défense de l’administration - Litiges Les moyens d'actions du SPF Finances sont ceux prévus aux articles 20 et 75 du Cahier général des Charges (en annexe à l'arrêté royal du 26 septembre 1996). Le marché doit être élaboré, interprété et exécuté conformément au droit belge. Les parties s'engagent à respecter leurs obligations de bonne foi et à coopérer en vue de la réussite de l'opération. Les litiges relatifs aux obligations découlant des dispositions qui régissent le marché doivent être réglés en concertation. •

Les parties devront préalablement à tout autre recours, essayer de régler l'affaire à l'amiable. A cette fin, la partie la plus diligente notifiera à l'autre partie par simple lettre recommandée la mauvaise exécution du contrat. Un mode de solution sera, si possible, joint à la notification. L'autre partie disposera d'un délai de 15 jours de calendrier à compter de l'envoi de la lettre recommandée pour en accuser réception et donner son accord sur la solution proposée.

•

A défaut d'accord et avant de faire valoir leurs droits en justice, les parties s'efforceront de trouver un compromis par la voie des négociations qui seront engagées dès qu'il est apparu que l'affaire ne peut être réglée à l'amiable. Les négociations se tiendront à l'adresse indiquée au point « fonctionnaire dirigeant » de la partie II en présence des personnes désignées à cette fin par les deux parties. Sauf accord contraire, les négociations ne pourront excéder une durée de 30 jours à dater de la première lettre recommandée.

Tous les litiges relatifs à l’exécution de ce marché sont exclusivement tranchés par les tribunaux compétents de l’arrondissement judiciaire de Bruxelles. La langue véhiculaire est le français ou le néerlandais. Le pouvoir adjudicateur n'est en aucun cas responsable des dégâts aux personnes ou aux biens qui sont la conséquence directe ou indirecte des activités nécessaires à l'exécution du présent marché. L’adjudicataire garantit le pouvoir adjudicateur contre toute action en dommages et intérêts par des tiers à cet égard.

P. 42

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

III. Description des exigences techniques III.1 Description du marché III.1.1 Contexte du marché Cette section présente le contexte dans lequel se place le présent marché : l’infrastructure IT du SPF Finances et ses problématiques actuelles. Cette infrastructure est d’abord présentée de manière globale en la replaçant dans le contexte du plan Coperfin. Elle est ensuite décrite plus précisément, tout d’abord du point de vue du matériel et du logiciel qui la constitue, ensuite du point de vue des communications qui transitent via cette infrastructure. Enfin, les problématiques actuellement rencontrées sont présentées ainsi que les motivations qui ont poussé l’Administration à publier ce cahier des charges. Les informations présentées dans ces sections sont des informations partielles destinées à présenter le contexte général du marché. Le soumissionnaire consultera le site Internet du SPF Finances à l’adresse http://minfin.fgov.be/ où il trouvera de plus amples informations sur : ● Coperfin : sous la rubrique Modernisation > Bibliothèque Coperfin ● ICT : sous la rubrique Modernisation > ICT ● Architectural Building Blocks : sous la rubrique Modernisation > ICT > Fondement ● Les différents cahiers des charges publiés : sous la rubrique Marchés publics

III.1.1.1 Infrastructure IT du SPF Finances III.1.1.1.1 Présentation globale Au sein du SPF Finances, le plan de modernisation Coperfin se voit exécuté, dans son volet informatique, par divers projets d'amélioration de l'infrastructure existante dont :

●

●

● ●

● ●

Atlas, lancé en 2004, qui offre une plate-forme matérielle de systèmes et de stockage ouverts d'entreprise sur lesquelles fonctionne la nouvelle infrastructure logicielle du SPF Finances, appelée à remplacer tous les mainframes le CCFF (Centre de Communications de la Fiscalité Fédérale) qui depuis 2003 se veut une infrastructure d'applications dynamique basée sur JEE et ouverte à un maximum d'outils de développement, de technologies d'échanges de données et de services. Le CCFF s'est notamment développé via la conception d'un framework, regroupant de nombreux services mis à disposition des applications (comme Tax on Web, Intervat, …) qui fonctionnent audessus et grâce à lui RDC qui apporte un système de gestion de bases de données relationnelles standard pour le département ICT SupDev qui offre un support au développement via, entre autres, une méthodologie complète de développement de logiciels (FUP, basée sur RUP) ainsi que tous les outils nécessaires à son application à grande échelle Le projet « Enterprise System Management » qui met en place le monitoring Le service « Job Scheduling » qui gère les jobs de production à exécuter sur les différentes plates-formes (Windows, UNIX et mainframe) du SPF Finances

P. 43

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

III.1.1.1.2 Présentation spécifique L’infrastructure IT peut être vue de deux manières :

III.1.1.1.2.1 Du point de vue du matériel et du logiciel

Les caractéristiques principales de l’infrastructure matérielle sont : ● L’environnement est réparti sur deux sites : au North Galaxy, siège du SPF Finances et au South Galaxy à Anderlecht, distant de plusieurs kilomètres du premier site ● Les serveurs web et d’applications sont installés sur des Fujitsu-Siemens BF200 et BF400. Les BF200 peuvent contenir maximum 6 lames contenant chacune 2 CPU Intel E5450 de 4 cores à 3Ghz et 32Gb RAM. Les BF400 peuvent contenir maximum 24 lames contenant chacune 4 CPU de 4 cores à 2.93Ghz et 64Gb RAM. Le système d’exploitation est Solaris 10 ● Les serveurs de base de données sont des FTS M9000 contenant chacun 32 CPU, 8 cores par CPU et 512 Gb RAM. Le système d’exploitation est Solaris 10 ● L’environnement est complètement redondant et tous les éléments fonctionnent en parallèle. La charge est répartie entre eux via des mécanismes de clustering ● Les applications sont totalement déployées sur les serveurs d’applications situés dans le LAN interne ● Les serveurs « Apache » ne contiennent que du contenu statique et réalisent du forwarding des requêtes vers les serveurs d’applications. Ces serveurs web font également office de filtre entre les applications accessibles sur Internet et les applications accessibles uniquement sur l’intranet

P. 44

SERVICE PUBLIC FÉDÉRAL FINANCES

●

● ●

Réf.: ICT/INF/ESB

L'équilibrage des charges des serveurs d’applications est entièrement réalisé sur base des mécanismes de Bea Weblogic. Le load balancing est exécuté au niveau des serveurs web Apache par un plugin Bea Le « clustering » des serveurs web est basé sur des loadbalancers matériels Cisco ACE L’accès aux mainframes est possible de façon identique à partir des deux environnements

III.1.1.1.2.2 Du point de vue des communications Le schéma suivant donne une vue générale des communications qui peuvent transiter via l’infrastructure IT du SPF Finances :

Les acteurs principaux de ce schéma sont : ● CCFF : propose des abstractions d’accès aux mainframes, des mécanismes de communication inter-applications ainsi que le développement et l’hébergement de services internes ● IAM : fournit une solution d’Identity and Access Management gérant les aspects liés à l’authentification et à l’autorisation des utilisateurs ● RDC : gère les bases de données relationnelles ● D&RMC : gère l’archivage des documents numériques ● ESM : gestion du monitoring, implémentée via HP OVOw

P. 45

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

On retrouve différents types de flux qui peuvent transiter via cette infrastructure. Citons, par exemple :

●

Communications inter-applicatives : la plupart du temps, définies via le CCFF

●

Communications G2C : la plupart du temps, via des web-applications spécifiques telles que Tax-on-Web, Intervat, …

●

Communications G2G : ○ BCSS : via des web services ○ BCE : via FTP ○ Communauté Européenne : via CCN/CSI ○ Fedict : via le FSB et l’UME de Fedict ○ Registre National : via FTP ○ Communes : entre autres via des web-applications spécifiques ○ ...

●

Communications B2G : ○ Banque : via le réseau Isabel ○ Chambre Royale des Notaires de Belgique : via le FSB Fedict ○ Belcotax On Web : via une web-application, via chargement de DVD ○ ...

III.1.2 Problématiques Le SPF Finances est confronté à deux problématiques : d’une part, l’accroissement des besoins hétérogènes en communication de et vers l’extérieur et, d’autre part, le besoin de renforcer la démarche SOA (Service Oriented Architecture).

III.1.2.1 Accroissement des besoins en communication de et vers l’extérieur Dans un futur proche, le SPF Finances sera confronté à une évolution des canaux de communication qu’il utilise pour communiquer avec ses partenaires externes. Ainsi, la modernisation de l’infrastructure IT des partenaires actuels amènera des changements tant dans la technologie que dans la nature de ces canaux de communications, augmentant à terme fortement l’hétérogénéité. De plus, l’apparition de nouveaux partenaires au niveau régional, fédéral ou encore européen, amènera la création de nouveaux canaux de communication. Afin de centraliser les aspects liés à la communication avec les partenaires externes et de créer un pôle d’expertise, le SPF Finances désire mettre en place une « Banque Carrefour de la Fiscalité Fédérale » qui sera la plateforme centrale de communication avec l’extérieur du SPF Finances. Il est important de se préparer de manière adéquate à ces futurs changements dans les canaux de communication afin, d’une part, de minimiser les impacts sur les applications existantes et, d’autre part, de pouvoir réagir rapidement lorsqu’il est nécessaire de créer un nouveau canal de communication ou bien d’adapter la technologie utilisée pour les canaux existants. En effet, dans certains cas les délais de mise en œuvre sont dérivés de contraintes légales qu’il faut respecter sous peine de pénalités. Une solution possible serait de gérer ces flux de communication dans le framework CCFF et de l’utiliser comme couche d’exposition et de médiation de et vers l’extérieur. Cette solution impliquerait donc de devoir développer, tester et maintenir en interne des composants d’interfaçage et de médiation. Par ailleurs, cela impliquerait également de devoir planifier la mise en production d’une nouvelle version du framework à chaque évolution de ces composants.

P. 46

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Afin d’obtenir la souplesse nécessaire pour absorber au mieux les nombreux changements prévus sur les canaux de communication et pour minimiser l’impact sur les applications, le SPF Finances désire se tourner vers une autre solution en intégrant un ESB (Enterprise Service Bus) dans son architecture. En effet, le rôle principal d’un ESB est de fournir des fonctionnalités de médiation de services et de permettre la transformation et le routage de messages. De plus, un ESB comporte de nombreux connecteurs qui permettent de s’interfacer rapidement avec diverses technologies de communication sans qu’il soit nécessaire de développer et maintenir en interne des composants spécifiques. Enfin, la définition des flux de communication et des opérations à effectuer sur les messages qui y transitent peuvent être définis dynamiquement via des opérations de configuration.

III.1.2.2 Renforcement de la démarche SOA Parallèlement à ces aspects de communication externe, le SPF Finances désire renforcer l’approche SOA qui incube depuis quelques années au sein de l’ICT. En effet, le développement du framework CCFF a permis de faire émerger quelques artefacts d’une approche SOA tels que le découplage technologique avec ses clients, l’apparition de la notion de service, un embryon d’annuaire de service, … Plus récemment, le cahier des charges CCFF 2008 a confirmé la volonté de s’inscrire dans une démarche SOA et en a tracé les grandes lignes directrices. Il est cependant nécessaire de consolider ce qui a déjà été réalisé et de systématiser la démarche SOA. À titre d’exemple, on peut constater que la notion de service, notion centrale de la démarche SOA, commence à se répandre au sein de l’ICT et a permis de mettre en place plusieurs services tels que la validation de numéro de compte bancaire, la récupération des bureaux compétents pour une certaine fonction, la gestion de tâches humaines via le Taskmanager, … Cependant, la maturité de certains aspects peut être améliorée, par exemple en référençant tous les services dans un annuaire de service, en définissant et vérifiant des SLA sur ces services, en mettant en place une couche d’abstraction et de médiation de l’accès aux services afin de ne plus devoir modifier les applications appelantes suite à une modification technique du service, ... Il est important pour le SPF Finances de s’engager plus en avant dans la démarche SOA. En effet, en faisant émerger la notion de couche de service au sein d’une organisation, la démarche SOA permet, à terme, de favoriser l’agilité, l’interopérabilité et une meilleure réutilisation de l’existant. Le SPF Finances désire donc consolider son socle technologique SOA en intégrant un ESB dans son architecture de référence. Grâce à ses fonctionnalités de médiation et d’intégration, il permettra de renforcer le travail effectué pour faire émerger une couche de service et d’augmenter le niveau de maturité SOA en jouant un rôle de levier pour accélérer l’adoption de SOA au sein du SPF Finances.

III.1.2.3 Le besoin d’une solution ESB Répondre correctement à l’augmentation des besoins en communication et au désir d’augmenter le niveau de maturité SOA sont deux défis de taille. Ils ont cependant un point commun : tous deux peuvent bénéficier de la mise en œuvre, non pas d’un simple produit ESB, mais bien d’une solution ESB. Le SPF Finances définit une solution ESB comme une plateforme de communication qui place un produit ESB au cœur de son architecture mais qui peut également comporter d’autres modules ou produits (tels que, par exemple, un catalogue de services, ...) qui s’inscrivent tous dans une approche intégrée de renforcement de la démarche SOA en place.

La solution ESB sera placée au cœur de la future banque carrefour de la fiscalité fédérale afin de pouvoir répondre plus facilement à l’augmentation pressentie des besoins liés à la communication avec les partenaires externes. Il n’est pas exclu qu’à terme les flux de communications existants et les communications inter-applicatives soient également du ressort de la solution ESB. Cette solution ESB

P. 47

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

sera également utilisée comme un catalyseur de la démarche d’urbanisation SOA au sein du SPF Finances en mettant en avant la notion de service grâce à ses fonctionnalités de médiation et d’intégration Le but du présent cahier des charges n’est donc pas simplement de doter l’infrastructure IT du SPF Finances d’un produit ESB en acquérant des licences. L’objectif poursuivi est de mettre en place une solution ESB complète qui soit pérenne et évolutive, qui s’intègre dans notre architecture, qui promeut la notion de service au sens SOA du terme et qui est alignée avec l’objectif à long terme de mise en place d’une architecture de référence SOA.

III.1.3 Objet du marché III.1.3.1 Introduction Comme expliqué dans la section « Contexte du marché », le SPF Finances souhaite doter son infrastructure IT d’une solution ESB lui permettant de faciliter les communications avec ses partenaires externes et d’utiliser cette solution ESB comme levier pour accélérer l’adoption de la démarche SOA. La mise en place d’un ESB dans un contexte SOA est une démarche inédite au SPF Finances. Si les premières étapes de la réalisation sont claires et bien définies, certains aspects à plus long terme sont encore inconnus, tels que, par exemple, le nombre et la volumétrie des futurs canaux de communication, la rapidité de l’adoption de SOA, le taux de réutilisation de services internes, … De plus, certaines de ces étapes futures dépendent fortement du succès de la réalisation des étapes en amont. Pour refléter cet état de fait, l’objet du marché est divisé en deux volets. Ces derniers étant fortement connexes, ils ne constituent qu’un seul lot. Le premier volet définit un ensemble de missions qualifiées de principales. Ces missions portent sur la mise en place correcte de la solution ESB, la réalisation d’un projet pilote et le démarrage du renforcement de la démarche SOA. Ces missions principales doivent être réalisées en prix fixe avec une obligation de résultat. Le second volet définit quant à lui un ensemble de profils qui seront utilisés pour réaliser des missions qualifiées de secondaires. Ces missions seront des missions liées à la solution ESB et à l’adoption de la démarche SOA mais pour lesquelles il est très difficile de prévoir dès à présent quel sera leur contenu ou leur ampleur. En effet, ces missions secondaires n’ont potentiellement de sens que si les missions principales sont un succès. Elles peuvent également être liées à des aspects en dehors du contrôle du SPF Finances (par exemple : mise en place d’un format de données spécifique découlant d’une contrainte légale, …) Comme ces missions ne peuvent être définies précisément pour l’instant, le SPF Finances ne garantit aucunement un minimum de commande dans le cadre de ces missions secondaires.

P. 48

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

III.1.3.2 Objet du marché Le marché est constitué d’un seul lot. Il consiste à mener à bien les missions suivantes dont les exigences sont détaillées dans la suite de ce cahier des charges :

●

Missions principales, en prix fixe, avec obligation de résultat : ○ Mettre en œuvre une solution ESB au sein de l’infrastructure du SPF Finances qui respecte les contraintes et les exigences définies dans le présent cahier des charges et qui s’intègre harmonieusement avec l’existant et les bonnes pratiques du SPF Finances (monitoring, IAM, haute-disponibilité, fail-over, disaster recovery, …) (voir entre autres section III.2.1 « Exigences générales », section III.2.2 « La solution ESB », section III.2.9 « SLA ») ○ Fournir les licences des différents composants de la solution ESB (voir section III.2.3 « Licences ») ○ Fournir au personnel interne du SPF Finances les connaissances nécessaires à l’installation, la configuration, l’exploitation, le développement et la maintenance de la solution ESB (voir section III.2.5 « Transfert de connaissances ») ○ Réaliser un projet pilote reposant sur la solution ESB (voir section III.2.6 « Projet pilote ») ○ Évaluer le niveau de maturité SOA avant et après l’installation de la solution ESB et la réalisation du pilote; rédiger des recommandations d’améliorations (voir section III.2.7 « Renforcement de la démarche SOA »)

●

Missions secondaires, sans garantie de commande par le SPF Finances : ○ Fournir des profils à temps plein et/ou à temps partiel pour réaliser des missions dans le cadre de l’exploitation, la maintenance et le développement de la solution ESB ainsi que dans le cadre du renforcement de la démarche SOA (voir section III.2.8.4 « Profils pour les missions secondaires »)

La solution ESB devant être installée sur l’infrastructure existante du SPF Finances, ce marché ne couvre pas la fourniture de matériel.

P. 49

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

III.2 Exigences du marché Cette section présente les besoins et exigences du SPF Finances ainsi que différentes questions destinées à évaluer l’adéquation entre l’offre du soumissionnaire et les besoins et exigences du SPF Finances.

Par défaut, les exigences présentées sont des exigences de priorité haute, c’est-à-dire des exigences qui doivent être respectées dès le début des prestations. Cependant, certaines exigences sont présentées comme étant de priorité moyenne ou basse : ces exigences peuvent ne pas être complètement respectées lors des premières itérations du projet mais devront à terme être totalement satisfaites. Dans tous les cas, toutes les exigences devront à terme être respectées et leur prix doit être inclus dans l’offre de base.

III.2.1 Exigences générales III.2.1.1 Réponse à l’offre La réponse du soumissionnaire au volet technique de la présente offre sera composée de deux parties. Dans la première partie, le soumissionnaire présentera le cadre général de sa réponse. Il pourra, par exemple, présenter une vue haut-niveau de sa solution technique, expliquer sa vision des problématiques et des solutions, mettre en avant les facteurs différenciateurs de sa proposition, … Le soumissionnaire dressera également dans cette partie la liste complète des logiciels qui composent l’offre de base de sa solution ESB. Le soumissionnaire veillera cependant à ce que cette première partie reste raisonnablement concise. La seconde partie sera constituée des réponses aux questions présentes dans ce chapitre. Les questions sont précédées d’un identifiant dont la forme est QXX, où XX est un nombre à deux chiffres. Avant chacune de ses réponses, le soumissionnaire prendra soin de reprendre l’identifiant de la question concernée. D’une manière générale, nous attendons que la réponse du soumissionnaire : ● soit soigneusement rédigée et issue d’un travail créatif ● montre que le soumissionnaire a compris et partage la vision du SPF Finances ● expose les différents choix possibles, résume leurs avantages et inconvénients, pose un choix et le justifie ● ne soit pas seulement technique mais décrive également des bonnes pratiques, des méthodologies et des organisations humaines à mettre en place ● soit réaliste, honnête et montre que le soumissionnaire connaît les limites de sa solution

III.2.1.2 Respect des standards Le soumissionnaire est censé avoir pris connaissance de l’infrastructure, des standards et des exigences en vigueur au sein de l’ICT et du SPF Finances en général. Pour rappel, ces fondements ont été cités dans le chapitre 1 « Contexte du marché », et sont accessibles via le site Internet du SPF Finances à l’adresse http://minfin.fgov.be/ . Il est bien évident que ces fondements peuvent évoluer au fil du temps. Le soumissionnaire s’engage expressément à respecter les fondements actuels, ainsi que leurs évolutions futures, dans le cadre de l’exécution du présent contrat. P. 50

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

À titre d’information, voici les dates théoriques de renouvellement de certains aspects de l’infrastructure IT : ● Firewall : renouvelable au plus tôt en 2011 ● Base de données : renouvelable au plus tôt en 2014 ● Application Server : renouvelable au plus tôt en 2014

III.2.1.3 Composition de la solution ESB Comme présenté dans la section I.1.2 « Problématiques », le SPF Finances ne recherche pas un simple produit ESB, mais bien une solution ESB complète. Le présent cahier des charges définit les exigences et les besoins du SPF Finances liés à cette solution ESB mais ne définit pas la composition exacte de la solution ESB. Il est de la responsabilité du soumissionnaire de définir et de composer une solution ESB qui respecte les exigences et les besoins décrits dans le présent cahier des charges. S’il juge que cela peut augmenter la qualité de son offre, le soumissionnaire peut intégrer dans sa solution des produits qui répondent à des problématiques plus poussées que celles présentées dans ce cahier des charges. Cependant, le présent marché n’acceptant ni les options ni les variantes, les prix de tous les produits composant la solution ESB doit être compris dans l’offre de base.

III.2.2 La solution ESB Cette section est divisée en trois parties : la première (III.2.2.1, « Description de la solution ESB proposée ») porte sur la composition et l’architecture de la solution ESB proposée par le soumissionnaire. La seconde (III.2.2.2, « Exigences fonctionnelles ») et la troisième (III.2.2.3, « Exigences non-fonctionnelles ») présentent respectivement les exigences fonctionnelles et nonfonctionnelles que devra respecter la solution ESB.

III.2.2.1 Description de la solution ESB proposée Cette section a pour but de permettre au soumissionnaire de présenter la solution ESB qu’il propose. Les questions abordent quatre sujets. En premier lieu, le soumissionnaire décrira et justifiera le choix des composants qui sont utilisés dans sa solution ESB. Ensuite, il décrira l’architecture générale de sa solution et en quoi elle est alignée avec les objectifs du SPF Finances. Enfin, le soumissionnaire décrira concrètement comment la solution peut être mise en œuvre et utilisée au quotidien et comment sa solution peut évoluer. Choix des composants Q01.

Le soumissionnaire présentera les composants constituant sa solution ESB et expliquera pourquoi ces composants particuliers ont été choisis. Il veillera également à ce que sa présentation réponde aux questions et demandes suivantes :

●

Le soumissionnaire donnera, pour chaque composant, la liste des exigences du présent cahier des charges auquel ce composant répond et justifiera succinctement pourquoi ces exigences sont rencontrées par ce composant

●

Le soumissionnaire expliquera pourquoi, selon lui, les composants de l’offre de base s’intègrent harmonieusement les uns avec les autres

●

Il présentera également les cas où l’intégration et la communication entre les composants est moins naturelle, voire problématique, quelles en sont les implications et justifiera pourquoi une autre solution n’a pas été retenue

P. 51

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

●

Le soumissionnaire décrira le niveau d’ouverture, d’évolution et d’interopérabilité des composants de sa solution ESB par rapport aux standards du marché. Il expliquera quels composants peuvent être remplacés par d’autres implémentations

●

Il est demandé au soumissionnaire d’expliquer en quoi les composants choisis respectent bien les standards exigés dans ce cahier de charges ainsi que les standards ICT du SPF Finances

Architecture Q02.

Le soumissionnaire décrira en détail l’architecture de la solution ESB qu’il propose de mettre en œuvre. Il veillera également à ce que sa description réponde aux questions et demandes suivantes :

●

Le soumissionnaire expliquera pourquoi, selon lui, la solution ESB proposée s’intègre harmonieusement avec l’infrastructure ICT du SPF Finances

●

Il décrira également les aspects de la solution ESB qui ne s’intègrent pas de manière harmonieuse avec l’infrastructure ICT du SPF Finances. Il expliquera quelles en sont les implications et justifiera pourquoi une autre solution n’a pas été retenue

●

Le soumissionnaire décrira comment et via quelles technologies (SNMP, …) la solution ESB s’intègre avec les outils et les environnements d’Enterprise Monitoring présents au SPF Finances. Il expliquera comment les actions de diagnostic et de correction pourront être initiées depuis la console du monitoring central

●

Le soumissionnaire expliquera pourquoi, selon lui, l’architecture de la solution ESB proposée est flexible, ouverte à la diversification, s’intègre avec la vision SOA du SPF Finances et permettra, dans le futur, d’intégrer de nouveaux composants nécessaires au support du développement de la démarche SOA

●

Le soumissionnaire expliquera pourquoi, selon lui, l’architecture de la solution ESB qu’il propose est capable de s’adapter à l’évolution éventuelle des fondements de l’ICT

●

Le soumissionnaire expliquera si sa solution se différencie d’un EAI et, si tel est le cas, quelles sont ces différences

Mise en œuvre et utilisation Q03.

Le soumissionnaire décrira sa proposition de mise en œuvre concrète de sa solution ESB. Dans sa réponse, il décrira et motivera sa proposition de capacity planning et de sizing de sa solution

Q04.

Le soumissionnaire expliquera quelles sont les best practices à mettre en œuvre pour l’utilisation de sa solution ESB

Q05.

Il est demandé au soumissionnaire d’expliquer les mécanismes permettant de créer plusieurs instances de la solution ESB. Il expliquera comment ces multiples instances peuvent être gérées, quel est le degré d’indépendance et de séparation entre les différentes instances et quelles sont les possibilités de communications entre les instances

P. 52

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Q06.

Le soumissionnaire présentera quelles sont les possibilités de scripting et d’automatisation de sa solution ESB. Il présentera également les fonctionnalités qui permettent d’exporter et d’importer la configuration de la solution ESB d’un environnement vers un autre

Q07.

Le soumissionnaire expliquera quels sont, selon lui, les rôles, les profils et les structures organisationnelles qui devraient être mis en place pour favoriser le bon déroulement de ce projet

Q08.

Le soumissionnaire est également invité à décrire quelques cas d’utilisation quotidienne de sa solution ESB du point de vue des différents intervenants (chef de projet, développeurs, gestion opérationnelle, …). En partant de cas réels ou fictifs, il décrira : la méthodologie à suivre et le cycle de vie du cas d’utilisation les différentes étapes à effectuer et les rôles organisationnels impliqués l’adéquation avec les standards ICT du SPF Finances, tels que, par exemple, le projet FUP-ITIL, les outils standards de développement et de test, ...

● ● ●

Les cas d’utilisation doivent au moins reprendre les cas suivants : ● un partenaire externe fourni un service web que le SPF Finances désire utiliser. Le service web est de type SOAP RPC-Encoded et est codé sur une stack Axis 1.1. Une fenêtre d’indisponibilité pour maintenance est prévue tous les dimanches de 8h à 10h. Le service authentifie ses utilisateurs via l’utilisation d’un certificat SSL. Le SLA définit que le temps de réponse est inférieur à 250 millisecondes et que le SPF ne fera pas plus de 10 requêtes par minute en moyenne sur une heure avec des pointes ne dépassant pas 1 requête par seconde. Du côté du SPF Finances, seules deux applications sont censées utiliser ce service. Comment ce service peut-il être exposé par la solution ESB ?

●

suite à une erreur de manipulation lors de la maintenance, le refroidissement d’une partie des salles machines n’est plus assuré et certains serveurs se sont éteints à cause de la surchauffe et sont potentiellement endommagés. En termes de capacité, la moitié des CPU et de la mémoire alloués à la solution ESB sont désormais indisponibles. Quels sont les impacts de cet incident et que faut-il faire pour minimiser les problèmes ? Un rack de serveurs équivalent à ceux actuellement indisponibles est commandé et sera opérationnel dans les 24 heures. Le contenu du disque est une image standard qui ne contient que le système d’exploitation. Que faut-il faire pour pouvoir utiliser ces serveurs dans le cadre de la solution ESB et combien de temps cela nécessitera-t-il ?

●

suite à l’arrivée d’une échéance dans le calendrier fiscal, on s’attend à un pic d’utilisation d’une application dans les 15 prochains jours. Cette application utilise trois services exposés par la solution ESB. Ces services sont utilisés par ailleurs par d’autres applications. Que faut-il faire pour minimiser l’impact du pic d’utilisation au niveau de la solution ESB ?

Q09.

Le soumissionnaire expliquera quels sont, selon lui, les KPI à mettre en place pour la solution ESB qu’il propose

Q10.

Le soumissionnaire expliquera, en prenant comme hypothèse que la solution ESB est déployée, fonctionnelle en production, exposant plusieurs services et utilisée par plusieurs applications, quelles sont les implications d’un changement des fondements ICT du SPF Finances au niveau des bases de données et des serveurs d’application

P. 53

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Évolutions de l’utilisation Q11.

Le soumissionnaire expliquera en quoi la solution ESB qu’il propose est capable, si cela s’avère nécessaire ou souhaitable, d’intégrer les flux de communication liés aux communications inter-applicatives

Q12.

Le soumissionnaire expliquera si, selon lui, il est envisageable et possible d’utiliser la solution ESB qu’il propose dans une architecture de type EDA

III.2.2.2 Exigences fonctionnelles Cette section présente les exigences fonctionnelles que devra respecter la solution ESB proposée.

III.2.2.2.1 Connectivité La solution ESB sera fournie avec un ensemble de connecteurs permettant de s’interfacer, d’une part, avec les technologies existantes au sein du SPF Finances et, d’autre part, avec ses partenaires externes.

Adéquation et utilité des connecteurs fournis Les solutions ESB sont en général fournies avec un nombre important de connecteurs. Cependant, il est fort probable qu’un nombre non négligeable de ces connecteurs ne soient d’aucune utilité pour le SPF Finances. D’autre part, certains connecteurs pourraient, de par leur principe de fonctionnement, ne pas s’intégrer harmonieusement avec les systèmes en place au SPF Finances (par exemple : connecteur avec un fonctionnement de type polling induisant une charge système trop élevée, connecteur JDBC demandant l’utilisation de triggers trop invasifs sur le SGBD, …).

Les connecteurs fournis avec la solution ESB devront donc être pertinents par rapport aux technologies existantes au sein du SPF Finances et par rapport aux standards permettant de faciliter les communications avec les partenaires externes actuels et futurs. Ces connecteurs devront s’intégrer harmonieusement avec les systèmes en place au SPF Finances.

Questions Dans ses réponses aux questions de cette section « Connectivité », le soumissionnaire ne devra pas lister de manière exhaustive les connecteurs fournis dans la solution ESB qu’il propose mais devra au contraire démontrer qu’il peut apporter une réelle valeur ajoutée en sélectionnant les connecteurs les plus utiles et les plus adéquats pour le SPF Finances. Pour rappel, les standards ICT et les moyens de communication avec les partenaires externes ont été cités dans le chapitre I.1.1 « Contexte du marché », et sont accessibles via le site Internet du SPF Finances à l’adresse http://minfin.fgov.be/ .

Communication avec des partenaires externes Q13.

Il est demandé au soumissionnaire d’expliquer quels sont, selon lui, les connecteurs effectivement fournis avec la solution ESB proposée qui sont susceptibles d’intéresser le SPF Finances dans le cadre de ses communications avec des partenaires externes, actuels ou futurs

P. 54

SERVICE PUBLIC FÉDÉRAL FINANCES

Q14.

Réf.: ICT/INF/ESB

Il est également demandé au soumissionnaire d’expliquer quels sont, selon lui, les canaux de communication utilisés actuellement par le SPF Finances pour communiquer avec des partenaires externes et pour lesquels il n’existe PAS de connecteurs fournis avec la solution ESB proposée

Intégration avec l’existant Q15.

Il est demandé au soumissionnaire d’expliquer quels sont, selon lui, les connecteurs fournis avec la solution ESB proposée qui permettent de se connecter de manière harmonieuse aux technologies existantes au sein du SPF Finances

Q16.

Il est également demandé au soumissionnaire d’expliquer quelles sont, selon lui, les technologies utilisées actuellement par le SPF Finances pour lesquelles il n’existe PAS de connecteurs fournis avec la solution ESB proposée ou bien pour lesquelles des connecteurs existent mais présentent des limitations qui empêchent leur intégration harmonieuse avec les technologies existantes au sein du SPF Finances

Évolutivité Q17.

D’autres connecteurs que ceux prévus dans l’offre de base peuvent-ils être fournis par le soumissionnaire ? Si oui, lesquels ?

Q18.

Est-il possible d’intégrer des connecteurs en provenance d’autres fournisseurs ? Si oui, sur quel standard se base cette interopérabilité ? Quelles sont les limitations ?

Q19.

Un kit de développement permettant de développer de nouveaux connecteurs est-il disponible ? Si oui : sur quels langages et technologies se base-t-il ? sur quelles plateformes peut-il être exécuté ? est-il fourni avec un environnement de développement intégré (IDE) ? quelles sont les fonctionnalités permettant de faciliter le développement de nouveaux connecteurs (par exemple : fourniture de bibliothèques, de templates, …) ● quelles sont les fonctionnalités permettant de faciliter les tests (par exemple : test sans envoi de données via le support de mocks, intégration avec des outils de testing, …) ● le kit de développement, son support, sa maintenance, sa documentation et les formations à l’utilisation du kit de développement font-ils partie de l’offre remise par le soumissionnaire ?

● ● ● ●

III.2.2.2.2 Routage La solution ESB proposée permettra le routage dynamique de messages. Le routage devra pouvoir se faire, entre autres, en fonction : ● du destinataire et/ou de l’expéditeur ● du contenu des messages ● de paramètres liés à la qualité de service (QoS) ● de règles définies par l’utilisateur ● …

P. 55

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Les règles de routages doivent pouvoir être définies via des fichiers de configuration et/ou via une interface graphique. La solution ESB doit être capable de gérer des flux de données synchrones et asynchrones. De plus, elle doit offrir une garantie de bonne livraison des messages.

Respect des exigences Q20.

Le soumissionnaire expliquera en quoi la solution ESB qu’il propose répond aux exigences décrites dans la présente section

Q21.

Le routage peut-il se faire selon d’autres critères que ceux présentés ci-dessus ? Si oui, lesquels et quelle pourrait être leur utilité pour le SPF Finances ?

Définition et mise à jour des règles de routage Q22.

● ● ● ● ● ●

●

Le soumissionnaire décrira comment les règles de routage peuvent être définies et mise à jour dans la solution ESB qu’il propose. Sa description devra répondre aux questions suivantes : Les règles de routage peuvent-elles être définies via des fichiers de configuration ? Les règles de routage peuvent-elles être définies via un éditeur graphique ? Si oui, sur quelles plates-formes l’éditeur s’exécute-t-il ? Quel est le langage utilisé pour définir les règles de routage ? Peut-on exporter la définition des règles de routage et les importer dans un autre produit ESB ? Si oui, lequel et via quel standard ? Quelles sont les facilités proposées par la solution ESB pour tester les règles de routage ? Dans quels cas une modification des règles de routage peut-elle s’appliquer “à chaud” et dans quels cas nécessite-t-elle un arrêt de l’ESB ou de l’un de ses composants et quelles en sont les conséquences ? En cas de modification d’une règle de routage (“à chaud” ou nécessitant un arrêt), qu’advient-il des messages acceptés par l’ESB avant la modification mais qui n’ont pas encore été routés vers leur destination ?

III.2.2.2.3 Transformation La solution ESB proposée offrira des fonctionnalités de transformation et d’enrichissement, c’est-àdire des fonctionnalités permettant de traduire et de modifier le contenu des messages transitant via l’ESB. Les règles de transformation doivent pouvoir être définies via des fichiers de configuration et/ou via une interface graphique.

Respect des exigences Q23.

Le soumissionnaire expliquera en quoi la solution ESB qu’il propose répond aux exigences décrites dans cette section

Définition et mise à jour des règles de transformation Q24.

Le soumissionnaire décrira les fonctionnalités de transformation et d’enrichissement présentes dans la solution ESB qu’il propose. Il veillera à ce que sa description réponde également aux questions suivantes : P. 56

SERVICE PUBLIC FÉDÉRAL FINANCES

● ● ● ● ● ● ●

● ●

●

Réf.: ICT/INF/ESB

Les règles de transformation peuvent-elles être définies via des fichiers de configuration ? Les règles de transformation peuvent-elles être définies via un éditeur graphique ? Si oui, sur quelles plates-formes l’éditeur s’exécute-t-il ? Quel est le langage utilisé pour définir les règles de transformation ? Peut-on exporter la définition des règles de transformation et les importer dans un autre produit ESB ? Si oui, lequel et via quel standard ? Quelles sont les éléments proposés permettant de faciliter l’écriture de règles de transformation (librairies, analyseur syntaxique, ...) ? Peut-on utiliser un langage de programmation généraliste (tel que Java, Python, Perl, …) pour écrire les règles de transformation ? Peut-on appeler des programmes ou des devices externes pour effectuer tout ou une partie de la transformation ? Si oui, quel est le mécanisme d’appel de programme et de retour de données utilisé ? Quelles sont les facilités proposées par la solution ESB pour tester les règles de transformation ? Peut-on modifier les règles de transformation “à chaud” ? Si non, dans quels cas une modification des règles de transformation nécessite-t-elle un arrêt de l’ESB ou de l’un de ses composants et quelles en sont les conséquences ? En cas de modification d’une règle de transformation, qu’advient-il des messages acceptés par l’ESB avant la modification mais qui n’ont pas encore été transformés ?

III.2.2.2.4 Validation La solution ESB doit proposer des fonctionnalités permettant de vérifier la validité des messages entrants et sortants. Cette exigence est une exigence de priorité basse : elle peut ne pas être présente dans les premières itérations du projet. Q25.

● ● ● ● ● ● ● ●

● ●

Le soumissionnaire décrira les fonctionnalités de validation présentes dans la solution ESB qu’il propose. Il veillera à ce que sa description réponde également aux questions suivantes : Quels sont les types de validation possibles (technique, protocolaire, sémantique, métier, …) ? Les règles de validation peuvent-elles être définies via des fichiers de configuration ? Les règles de validation peuvent-elles être définies via un éditeur graphique ? Si oui, sur quelles plates-formes l’éditeur s’exécute-t-il ? Quel est le langage utilisé pour définir les règles de validation ? Peut-on exporter la définition des règles de validation et les importer dans un autre produit ESB ? Si oui, lequel et via quel standard ? Quelles sont les éléments proposés permettant de faciliter l’écriture de règles de validation (librairies, analyseur syntaxique, ...) ? Peut-on utiliser un langage de programmation généraliste (tel que Java, Python, Perl, …) pour écrire les règles de validation ? Peut-on appeler des programmes ou des devices externes pour effectuer tout ou une partie de la validation ? Si oui, quel est le mécanisme d’appel de programme et de retour de données utilisé ? Quelles sont les facilités proposées par la solution ESB pour tester les règles de validation ? En cas de détection d’un message non valide, quelles sont les possibilités d’action offertes par la solution ESB ?

P. 57

SERVICE PUBLIC FÉDÉRAL FINANCES

●

●

Réf.: ICT/INF/ESB

Peut-on modifier les règles de validation “à chaud” ? Si non, dans quels cas une modification des règles de transformation nécessite-t-elle un arrêt de l’ESB ou de l’un de ses composants et quelles en sont les conséquences ? En cas de modification d’une règle de validation, qu’advient-il des messages acceptés par l’ESB avant la modification mais qui n’ont pas encore été validés ?

III.2.2.2.5 Annuaire et catalogue de services La solution ESB doit proposer des fonctionnalités de service registry et service repository. Cette exigence est une exigence de priorité moyenne : un sous-ensemble minimum fonctionnel doit être présent dès le début du projet mais les fonctionnalités complètes peuvent être livrées plus tard. Q26.

● ● ● ● ● ●

Le soumissionnaire fournira une description des fonctionnalités offertes par l’annuaire et le catalogue de services. Il répondra également aux questions suivantes : L’annuaire et le catalogue respectent-ils les spécifications décrites dans le Governance Interoperability Framework ? Quelles sont les possibilités de gestion du cycle de vie des services offertes par l’annuaire et le catalogue de services ? Quelles sont les types d’informations qui sont supportées par l’annuaire et le catalogue de services ? Quels sont les types de services qui peuvent être décrits dans l’annuaire et le catalogue ? Tous les types de services sont-ils gérés de la même façon ? Comment l’annuaire et le catalogue gèrent-ils les services de type REST ? Comment l’annuaire et le catalogue s’intègrent-ils aux outils déjà existants au SPF Finances tels que, par exemple, la Configuration Management DataBase (CMDB)

III.2.2.2.6 Exposition de services La solution ESB doit offrir des fonctionnalités permettant d’exposer des services existants ailleurs dans l’infrastructure IT sans que ceux-ci ne doivent être déployés à l’intérieur de la solution ESB. La solution ESB doit également fournir des fonctionnalités permettant d’exposer des services virtuels résultant de la composition de services de plus bas niveau et de l’agrégation de leurs résultats. La définition des règles d’agrégation et de composition doit supporter l’utilisation d’une logique programmable simple comportant, entre autres, des structures de contrôle séquentielles, conditionnelles et itératives. Les fonctionnalités d’exposition de services doivent également permettre de modifier le mode d’accès aux services en permettant, par exemple, d’exposer un service synchrone de manière asynchrone, et inversement. Q27.

● ● ● ●

Le soumissionnaire décrira les différentes possibilités d’exposition et de composition de services fournies par la solution ESB qu’il propose. Il veillera à ce que sa description réponde aux questions suivantes : Quels sont les Enterprise Integration Patterns utilisables ? L’exposition et la composition de services peut-elle être définie via des fichiers de configuration ? L’exposition et la composition de services peut-elle être définie via un éditeur graphique ? Si oui, sur quelles plates-formes l’éditeur s’exécute-t-il ? Quel est le langage utilisé pour définir les règles d’agrégation ou de composition ? Peuton les exporter vers un autre produit ESB ?

P. 58

SERVICE PUBLIC FÉDÉRAL FINANCES

● ●

● ●

Q28.

●

●

Q29.

● ● ● ●

Q30.

● ●

Réf.: ICT/INF/ESB

Peut-on utiliser un langage de programmation généraliste (tel que Java, Python, Perl, …) pour écrire les règles d’agrégation ou de composition ? Peut-on appeler des programmes ou des devices externes pour effectuer tout ou une partie de l’agrégation ou de la composition ? Si oui, quel est le mécanisme d’appel de programme et de retour de données utilisé ? Quelles sont les facilités proposées par la solution ESB pour tester les règles d’agrégation ou de composition ? En cas d’indisponibilité du service exposé, comment réagit la couche d’exposition ? Les clients peuvent-ils continuer à l’appeler ? Quelles informations renvoie-t-elle ? Le soumissionnaire expliquera comment les problématiques d’autorisation et d’authentification sont gérées par les mécanismes d’exposition de services. Il veillera à ce que sa description réponde aux questions suivantes : Quelles sont les possibilités permettant d’imposer un contrôle d’accès (autorisation et authentification) à l’exposition du service ? Comment cela est-il intégré aux solutions IAM du SPF Finances ? Le soumissionnaire expliquera comment il propose de vérifier que les accès aux services exposés respectent la condition de proportionnalité telle que définie dans la loi “vie privée” du 8 décembre 1992, chapitre II, article 4, paragraphe 1, point 3 Le soumissionnaire expliquera comment la problématique de gestion de cycle de vie des services est gérée par les mécanismes d’exposition de services. Il veillera à ce que sa description réponde aux questions suivantes : Comment peut-on gérer le cycle de vie des services qui sont exposés ? Comment peut-on gérer le cycle de vie de l’exposition des services ? Comment peut-on définir, gérer et vérifier les SLA des services exposés et de leur exposition ? Selon vous, qu’est-ce que le cycle de vie d’un SLA et comment peut-on le gérer dans la solution ESB que vous proposez ? Le soumissionnaire expliquera en quoi les fonctionnalités de composition et d’agrégation de services sont différentes d’un orchestrateur, si tel est le cas. Il veillera à ce que sa description réponde aux questions suivantes : Le soumissionnaire devra définir sa vision et les rôles de l’orchestration dans une architecture SOA Quels sont les avantages et inconvénients d’intégrer l’orchestration dans l’ESB ou de l’en séparer ?

III.2.2.2.7 Monitoring technique La solution ESB doit proposer une interface de monitoring permettant : • d’examiner l’état du fonctionnement de l’ESB et de ses différents composants • d’examiner les états des flux transitant par l’ESB • de consulter l’historique des états, des alertes et des erreurs Les différentes informations collectées doivent pouvoir être définies et personnalisables. Les niveaux d’alertes doivent pouvoir être définis en fonction de la criticité du problème. Les informations et les alertes seront consultables via une interface utilisateur graphique. Elles pourront également être exportées vers d’autres systèmes de traitement de l’information.

P. 59

SERVICE PUBLIC FÉDÉRAL FINANCES

Q31.

● ● ● ● ●

Réf.: ICT/INF/ESB

Le soumissionnaire fournira une description des capacités de monitoring technique de sa solution ESB. Il répondra également aux questions suivantes : Quelles sont les statistiques et alertes disponibles et quels sont les états monitorables ? Quelles sont les informations collectées qui sont personnalisables et par quel moyen peut-on les personnaliser (fichier de configuration, programmatiquement, …) ? Les statistiques, les états et les alertes sont-ils consultables de manière programmatique ? Si oui, via quelle technologie (jmx, …) ? Est-il possible de suivre l’état d’un message sur toute sa durée de vie ? Peut-on vérifier en temps-réel ou a posteriori le respect des SLA ?

III.2.2.2.8 Tableau de bord orienté « business » La solution ESB doit proposer un tableau de bord orienté « business », c’est à dire un tableau de bord montrant des informations business extraites des flux passant par la solution ESB. Il ne s’agit pas ici de vouloir faire du data mining, des processus de reporting qui doivent être exécutés périodiquement ou encore de l’extrapolation sur les événements futurs. Il s’agit de proposer une vue en (quasi-) temps-réel, au fil de l’eau, des informations métier. Les différentes informations collectées doivent pouvoir être définies et personnalisables et offrir une vue sur des concepts métiers contenus dans les flux d’informations transitant via la solution ESB. Les informations « temps-réel » doivent pouvoir être consultées via une interface utilisateur graphique et être exportées vers d’autres systèmes de traitement de l’information. Les écrans d’affichage doivent pouvoir être personnalisés. Il doit être possible de définir des utilisateurs et de limiter l’accès à certaines informations à certains utilisateurs. Le mécanisme d’identification et d’autorisation doit s’intégrer avec les solutions d’authentification et d’autorisation en place au SPF Finances. Cette exigence est une exigence de priorité basse : elle peut ne pas être présente dans les premières itérations du projet.

Q32. • •

Le soumissionnaire fournira une description des fonctionnalités offertes par le tableau de bord orienté « business ». Il répondra également aux questions suivantes : En quoi les fonctionnalités de tableau de bord business sont différentes d’un BAM, si tel est le cas ? Le soumissionnaire décrira quelle est, selon lui, la place d’un BAM dans une approche SOA

III.2.2.2.9 Contrôle des performances La solution ESB proposera des fonctionnalités permettant de contrôler et d’ajuster ses performances. Il doit être possible d’identifier les points dans la chaîne de traitement de la solution ESB qui posent un problème du point de vue des performances. De même, afin de prévenir une dégradation des performances, il doit être possible de mettre en place de la limitation de charge (throttling). Q33.

Le soumissionnaire décrira comment les performances de la solution ESB proposée peuvent être contrôlées et ajustées. Dans sa description, il répondra également aux questions suivantes :

P. 60

SERVICE PUBLIC FÉDÉRAL FINANCES

• •

•

Réf.: ICT/INF/ESB

Les fonctionnalités de contrôle de performance permettent-elles de contrôler les performances d’un flux donné d’un bout à l’autre de la chaîne de traitements ? Le contrôle des performances d’un flux se fait-il de manière intégrée depuis une interface centralisée ou bien faut-il contrôler et ajuster les performances à chacun des points de traitements via les interfaces spécifiques à ces points de traitement ? Au-delà du contrôle des performances, la solution permet-elle également de détecter les erreurs survenues à différents points de traitement ?

Q34.

Le soumissionnaire décrira comment la solution ESB qu’il propose prend en charge la fonctionnalité de limitation de la charge (throttling). Il expliquera également ce qu’il advient des requêtes client qui tomberaient sous le coup du mécanisme de limitation de charge

Q35.

En prenant comme hypothèse qu’un flux de messages à traiter par la solution ESB comporte à la fois des messages de petite taille et des messages de grande taille, le soumissionnaire expliquera comment on peut empêcher que le traitement des messages de grande taille monopolise les ressources et dégrade les performances de traitement des messages de petite taille

III.2.2.3 Exigences non-fonctionnelles Cette section présente les exigences non-fonctionnelles que devra respecter la solution ESB proposée.

III.2.2.3.1 Sécurité La solution ESB proposée devra permettre de chiffrer les messages échangés. Elle devra également permettre de gérer l’authentification et l’autorisation des accès aux services. Elle devra gérer des “utilisateurs techniques” et des utilisateurs humains, tant internes qu’externes au SPF Finances. Elle devra s’intégrer harmonieusement avec les solutions d’Identity and Access Management déjà en place ou planifiées (IAM et FedIAM). Enfin, la solution ESB devra être déployée en respectant les règles de bonnes pratiques en place concernant la sécurité des réseaux informatiques (intégration avec le firewall, la DMZ, …) afin d’empêcher tout accès non autorisé. Q36.

Le soumissionnaire devra décrire comment la solution ESB qu’il propose permet de gérer les aspects d’authentification et d’autorisation d’accès aux services. Il apportera un soin particulier aux détails de l’interaction avec les solutions IAM et FedIAM

Q37.

Le soumissionnaire fournira et commentera un schéma décrivant comment la solution ESB qu’il propose sera déployée dans l’infrastructure du SPF Finances. Il décrira comment l’ESB se positionnera par rapport à, entre autre, le firewall, la DMZ, les serveurs Apache, … Il décrira pourquoi, selon lui, la sécurité de la solution ESB est garantie

III.2.2.3.2 Passage à l’échelle (scalability) Dans un premier temps, la solution ESB sera principalement utilisée dans le cadre de nouvelles communications avec les partenaires externes au SPF Finances. Il est donc à priori difficile d’estimer le trafic et la charge que la solution ESB devra supporter. De plus, le trafic et la charge sont susceptibles de varier fortement en fonction des dates limites liées, entre autres, au calendrier fiscal.

P. 61

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

L’architecture de la solution devra prendre en compte cette problématique et permettre de croître ou de décroître en fonction de la charge réelle ou planifiée, éventuellement en tenant compte des capacités de virtualisation offertes par l’infrastructure IT du SPF Finances. A titre d’information, et sans que cela présume d’une quelconque utilisation future de la solution ESB dans les domaines mentionnés ci-après, voici les statistiques du nombre de visites sur les serveurs Apache de quelques applications du SPF Finances :

● ● ●

MyMinFin : 2.643.005 visites entre mai 2010 et mars 2011, avec un pic de 14.594 visites journalières (générant 194.191 hits) en moyenne au mois de juin 2010 TaxOnWeb : 3.895.253 visites entre mai 2010 et mars 2011, avec un pic de 44.263 visites journalières (générant 1.826.729 hits) en moyenne au mois de juin 2010 InterVat : 1.696.051 visites entre mai 2010 et mars 2011, avec un pic de 8.720 visites journalières (générant 311.287 hits) en moyenne au mois de janvier 2011

Q38.

Il est demandé au soumissionnaire d’expliquer pourquoi, selon lui, l’architecture de sa solution ESB permet de rencontrer les exigences non-fonctionnelles liées au passage à l’échelle (scalability). Dans sa réponse, le soumissionnaire expliquera comment est réalisée la scalability tant horizontale que verticale

Q39.

En prenant comme hypothèse qu’une étape dans la chaîne de traitement des flux de données est particulièrement consommatrice de ressources, le soumissionnaire expliquera comment il est possible de faire passer à l’échelle cette étape particulière

III.2.2.3.3 Disponibilité De par son rôle de connexion et de médiation, la solution ESB est amenée à occuper un rôle central au sein de l’infrastructure IT du SPF Finances. L’architecture logicielle de la solution ESB devra permettre d’assurer une haute disponibilité et une continuité de service (voir Section III.2.9, SLA). Le taux de disponibilité minimal sera de 99,9% calculé sur un mois. Elle devra pouvoir fonctionner dans un environnement composé de clusters et être capable d’en tirer parti. Q40.

Il est demandé au soumissionnaire d’expliquer pourquoi, selon lui, l’architecture de sa solution ESB permet de rencontrer les exigences non-fonctionnelles liées à la disponibilité

Q41.

Le soumissionnaire présentera les opérations susceptibles de rendre temporairement indisponible tout ou une partie de la solution ESB (reconfiguration, mise à jour des composants de la solution, ajout de serveurs pour tenir une montée en charge, …) et donnera une estimation de la durée de ces indisponibilités

III.2.2.3.4 Support des standards Comme précisé dans la section III.2.1.2, Respect de standards, la solution ESB respectera les standards ICT du SPF Finances et leurs évolutions futures. La solution ESB respectera également les standards du marché dans le domaine des ESB et de la mise en place d’une architecture orientée service. Elle devra donc satisfaire, entre autres, aux normes et standards techniques suivants : WebServices

●

SOAP 1.1 et 1.2 P. 62

SERVICE PUBLIC FÉDÉRAL FINANCES

● ● ● ●

Réf.: ICT/INF/ESB

WSDL 1.1 (2.0 est un plus) REST WS-I Basic Profile 1.1 (1.2 et 2.0 sont un plus) WS-Security, WS-SecurityPolicy

Transformations XML

● ●

XSLT XQuery

Sécurité

● ●

SSL SAML

Q42.

Le soumissionnaire décrira quels sont les standards qui ne sont pas respectés par la solution ESB qu’il propose et en expliquera les implications

Q43.

Le SPF Finances s’interroge sur la pertinence d’utiliser le standard WS-Trust. Il est demandé au soumissionnaire de fournir sa vision sur l’utilisation de WS-Trust dans l’architecture de la solution ESB proposée et en harmonie avec l’infrastructure existante. Le soumissionnaire est également libre d’exposer sa vision sur d’autres spécifications WS-* qu’il juge pertinentes pour le SPF Finances

Q44.

Le SPF Finances constate que le standard JBI, autrefois plébiscité par le marché, est désormais de moins en moins mis en avant. Le soumissionnaire précisera si la solution ESB qu’il propose supporte JBI et comment ce support est mis en œuvre. Le soumissionnaire décrira également quels sont, selon lui, les avantages et les inconvénients du support ou de l’absence de support de JBI par la solution ESB qu’il propose

III.2.3 Licences III.2.3.1 Progressivité de l’utilisation des licences Bien que le SPF Finances désire à terme un contrat de licence de type « site » sans restrictions d’utilisation, une telle politique de licence ne doit pas être mise en place dès les premiers instants du projet. En effet, le projet commencera par la mise en place d’un projet pilote (voir section III.2.6 « Projet pilote ») pour lequel une licence de type « site » est inutile. L’utilisation de la solution ESB montera progressivement en charge et seules les dernières phases du projet pourront éventuellement requérir une licence de type « site ». Dans un souci de réduction des coûts et de bonne gestion financière, le SPF Finances désire donc une mise en place progressive des licences de la solution ESB et désire, lors des premières phases du projet, pouvoir acheter uniquement le nombre de licences qu’il juge nécessaire. Concrètement, les licences ne seront mises en œuvre et payées que lors de leur utilisation effective, c’est-à-dire au plus tôt lors du démarrage du proof-of-concept, et non pas dès le kick-off du projet.

P. 63

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

III.2.3.2 Unité de mesure : la licence processeur Face à la multiplicité et la créativité des offres de prix sur le marché, il est très difficile de comparer les prix des licences. En effet, certaines licences imposent une limite sur le nombre de processeurs physiques utilisés, sur le nombre de cœurs présents ou encore sur le nombre d’utilisateurs. Afin de pouvoir garantir une comparaison équitable des différentes offres, le SPF Finances impose que les offres de prix concernant les licences de la solution ESB soient libellées sur base d’une unité de mesure qui facilite la comparaison : la « licence processeur ». Le nonrespect de cette prescription constitue une cause de nullité de l’offre. Le SPF Finances définit une « licence processeur » comme une licence permettant d’utiliser chacun des composants constituant la solution ESB sur un core physique, virtuel ou logique, sans limitation ni restrictions d’aucune sorte (par exemple et entre autres, pas de limitations sur le nombre de threads utilisés, sur le nombre d’utilisateurs concurrents ou non, sur le nombre d’instances créées, …). Le soumissionnaire notera que le SPF Finances impose également les points suivants : • une « licence processeur » n’est pas liée à une machine physique et pourra être installée sur une autre machine que celle sur laquelle elle a été utilisée initialement • si une « licence processeur » nécessite l’utilisation de matériel spécialisé (par exemple, une appliance), le prix de ce matériel, ainsi que sa livraison, son installation, sa configuration, son support et sa maintenance doivent être inclus dans le prix de la « licence processeur ». Ce matériel est soumis aux mêmes conditions que le logiciel (entre autres, les mêmes conditions de support, de maintenance, de SLA, …) • une « licence processeur », quel que soit l’environnement (développement, acceptance, production) auquel elle est destinée, inclus également dans son prix le droit d’installer et d’utiliser tous les outils de développement, de configuration, d’édition et de consultation liés aux différents composants de la solution ESB sur cinq stations de travail supplémentaires, sans distinction sur l’environnement Afin de garantir à l’Administration un fonctionnement ininterrompu de la future solution ESB, l’acquisition d’une « licence processeur » est définitive et irrévocable et doit garantir au SPF Finances qu’il pourra continuer à utiliser sans aucun frais supplémentaires les logiciels après la fin du présent marché. Le soumissionnaire remettra une offre présentant les prix d’une « licence processeur » destinée respectivement à l’environnement de développement, l’environnement d’acceptance et l’environnement de production.

III.2.3.3 Volumétrie Le nombre de processeurs utilisés (et donc le nombre de « licences processeur » possédées) évoluera avec la montée en charge de l’utilisation de la solution ESB. Afin de pouvoir planifier le nombre de processeur et donc de licences nécessaires, le SPF Finances désire obtenir un devis, pour une volumétrie donnée, du nombre de processeurs requis pour que la solution ESB supporte cette volumétrie. Le SPF Finances définit la fonction de volumétrie V() comme une fonction prenant comme entrée : ● n, le nombre moyen de messages par seconde devant être traités par la solution ESB ● t, la taille moyenne en kibioctets (1024 octets) de ces messages et retourne comme résultat un entier représentant le nombre de processeurs (et donc de « licences processeur ») requis pour que la solution ESB définie et déployée par le soumissionnaire dans l’infrastructure IT du SPF Finances puisse traiter en moyenne n messages par secondes de taille moyenne t. Les moyennes sont calculées sur une période de cinq minutes. Le soumissionnaire donnera les détails permettant de calculer la fonction de volumétrie V() pour sa solution ESB déployée sur l’infrastructure du SPF Finances. Le SPF Finances impose une garantie sur cette fonction : s’il s’avère que le nombre de processeurs et donc de « P. 64

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

licences processeur » renvoyé par la fonction pour tenir une volumétrie donnée est en réalité insuffisant pour tenir cette volumétrie donnée, le soumissionnaire offrira définitivement et irrévocablement, sans compensation d’aucune sorte, les « licences processeur » supplémentaires nécessaires pour tenir cette volumétrie donnée. Ces licences offertes sont soumises aux mêmes contraintes que les licences achetées (voir, entre autres, la sous-section suivante « Licence site », la section III.2.4 « Maintenance logicielle », la section III.2.9 « SLA », …)

III.2.3.4 Licence site À terme, le SPF Finances souhaite obtenir une licence de type « site » pour la solution ESB, c’est-àdire une licence lui permettant d’utiliser la solution ESB sur autant de processeurs que nécessaires sans devoir acheter une « licence processeur » pour chaque processeur utilisé. Le SPF Finances définit une licence de type « site » comme une « licence processeur » sur laquelle la limitation d’utilisation sur un seul core a été levée. Il s’agit donc d’une licence permettant d’utiliser le logiciel, dans toutes ses versions : ● sur de multiples et différentes plate-forme hardware physiques et virtuelles ainsi que sur différents OS, sur différents environnement (développement, acceptance, production , …) et sur différents sites physiques (North Galaxy, South Galaxy, …) pour de multiples instances de la solution ESB, et ce sans limite ni restriction d’aucune sorte ● par et pour toutes les applications, flux de données, utilisateurs et partenaires, tant internes qu’externes, présents et à venir, connus ou inconnus, du SPF Finances et ce sans limite ni restriction d’aucune sorte Le soumissionnaire expliquera à partir de quelle quantité de « licences processeurs » détenues par le SPF Finances pour l’environnement de production (en ce incluses les licences offertes décrites au point précédent Volumétrie) il estime que l’ensemble de ces licences sont équivalentes à une licence de type « site ».

III.2.3.5 Tableau de prix Le soumissionnaire présentera (voir Annexe A :a)ii) ‘Prix des licences’) le prix de la licence de l’offre de base de sa solution ESB de la façon suivante :

●

Prix de l’offre de base de la solution ESB ○ Prix d’une « licence processeur » pour l’ensemble des composants de la solution ESB destinée respectivement à l’environnement de développement, d’acceptance et de production. Cette licence permet également d’installer et d’utiliser tous les outils de développement, de configuration, d’édition et de consultation liés aux différents composants de la solution ESB sur cinq stations de travail supplémentaires, sans distinction sur l’environnement ○ Fonction de volumétrie V() pour la solution ESB ○ Nombre de « licences processeurs » à posséder pour être en licence « site »

III.2.4 Maintenance logicielle et support Durant toute la durée du marché, l’adjudicataire s’engage à fournir au SPF Finances toutes les mises à jour, y compris les mises à jour qualifiées de « majeures » par l’adjudicataire, de tous les logiciels composant la solution ESB. Ceci porte sur l’ensemble de l’offre logicielle. Cependant, le SPF Finance sera seul habilité à décider s’il réalise une mise à jour ou non, si cette mise à jour est partielle ou complète et si cette mise à jour se fait dans tous les environnements ou seulement certains. En cas de changement dans le packaging (regroupement de logiciels formant un tout), le nouveau packaging ne sera pas imposé au SPF Finances si cela a pour effet de supprimer des fonctions déjà P. 65

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

disponibles. Le fait que le nouveau packaging comporte des fonctionnalités supplémentaires qui n'intéressent pas le SPF Finances ne pourra justifier une augmentation de prix.

L’adjudicataire fournira un support sur la solution ESB dans son ensemble ainsi que sur chacun des composants de la solution ESB. De plus, il sera le point de contact unique en ce qui concerne les aspects de support. Le soumissionnaire montrera qu'il bénéficie du support nécessaire de la part des différents fournisseurs des composants de la solution ESB afin d'avoir la possibilité de signaler les problèmes inattendus liés au logiciel et de les faire résoudre. Q45.

Le soumissionnaire décrira quel est le support qu’il s’engage à fournir sur la solution ESB dans son ensemble, c’est-à-dire sur les différents composants qui forment la solution ainsi que sur les interactions entre ces composants. Il veillera également à ce que sa description réponde aux questions et demandes suivantes :

●

Le soumissionnaire expliquera pourquoi, selon lui, les composants de l’offre de base sont fiables et ont un niveau de maturité adéquat. Il expliquera pourquoi le niveau de support, de maintenance et d’évolutivité de ces composants est également adéquat

●

Le soumissionnaire démontrera qu’il possède les compétences adéquates pour utiliser ces composants, tant individuellement que dans leur ensemble, dans le cadre des missions et des exigences décrites dans ce cahier des charges

●

En se basant sur des projets analogues présentés dans la section “Sélection qualitative” du volet administratif de la présente offre, le soumissionnaire expliquera dans quelles conditions il a déjà offert par le passé un support sur une solution ESB similaire à celle qu’il propose pour ce cahier des charges. Pour chaque expérience de support, il décrira clairement qu’elles étaient les différences et les similitudes avec la solution qu’il propose pour ce cahier des charges

●

En se basant sur ces expériences passées, le soumissionnaire expliquera comment il compte assurer le support de la solution ESB pour le présent marché et quelle est l’implication des éditeurs des logiciels qui composent la solution ESB vis-à-vis de ces aspects de support. Le soumissionnaire décrira également quels sont les SLA qu’il a luimême avec les éditeurs des logiciels qui composent la solution ESB

III.2.5 Transfert de connaissances Dans le cadre de la reprise en interne de la gestion de la solution ESB mise en place, le transfert de connaissances se fera à plusieurs niveaux. D’une part, via des formations et des manuels et, d’autre part, en collaborant étroitement avec le personnel interne du SPF Finances dans la mise en place de la solution ESB et de la réalisation du projet pilote. A l’issue des formations et suite au travail collaboratif de mise en place de la solution ESB et de réalisation du projet pilote, le personnel du SPF Finances devra être capable de réaliser par lui-même un deuxième projet pilote de nature similaire au projet pilote présenté dans le présent cahier des charges. Si ce deuxième pilote n’est pas réalisable suite à des formations ou un transfert de connaissances inadapté, l’adjudicataire fournira à ses frais les remédiations nécessaires au personnel du SPF Finances.

III.2.5.1 Formations et manuels

P. 66

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Des formations seront prévues pour le personnel du SPF Finances et pourront être commandées durant toute la durée du projet. Seront ciblés, entre autres : les opérateurs, les programmeurs, les architectes-analystes et les chefs de projet. Il y aura des formations pour chaque type de profil et le contenu sera adapté en fonction. Les exigences sur ces formations sont les suivantes :

● ● ● ● ●

Les formations auront lieu dans les locaux du SPF Finances, en collaboration avec ICT 2 Academy Chaque formation sera organisée en français et en néerlandais La documentation technique sera de préférence bilingue français / néerlandais Les formations se donneront par groupe de maximum dix personnes Le personnel interne sera capable de gérer, exploiter et faire évoluer la solution ESB de manière autonome à l’issue de ces formations (autant au niveau opérationnel que fonctionnel)

Les manuels d’utilisation de chaque composant et outil de la solution ESB seront fournis. Ces manuels devront décrire aussi bien l’installation, la configuration, la maintenance et l’exploitation de ces composants et outils. Le soumissionnaire présentera les prix des formations de la façon suivante : pour chaque groupe-cible (opérateurs, programmeurs, architectes-analystes et chefs de projet), le soumissionnaire indiquera le prix d’un cycle complet de formation pour un groupe de maximum 10 personnes de ce groupe-cible. Le prix porte donc bien sur un cycle de formation complet pour un groupe entier et n’est donc pas un prix par séance, par jour, par personne, … Ce prix comprend la documentation des produits ainsi que tous les supports de cours nécessaires.

Q46.

Il est demandé au soumissionnaire qu’il fournisse dans son offre un plan de formation satisfaisant les exigences susmentionnées. Ce plan devra déboucher sur une internalisation complète des compétences nécessaires à la gestion et à la maintenance de la solution ESB

Q47.

Le soumissionnaire expliquera comment il compte évaluer le fait que les formations ont bien atteint leurs objectifs et que les personnes formées possèdent bien les compétences nécessaires

Q48.

Le soumissionnaire décrira quelles remédiations il s’engage à fournir s’il s’avère que les formations ou le transfert de connaissances ont été inadaptés

III.2.5.2 Transfert continu des connaissances Dans un souci de transfert de connaissance, la mise en place de la solution ESB se fera en étroite collaboration avec le personnel interne du SPF Finances. Cela induit que toutes les connaissances nécessaires à cette mise en place, analyses et réflexions seront transmises au fil de l’eau, centralisées par l’adjudicataire et accessibles par toute personne attachée au projet. De même, tout développement faisant partie de la solution ESB (par exemple développement de connecteur, de règles de médiation, …) ou du projet pilote se fera en collaboration avec des développeurs internes. Q49.

Le soumissionnaire décrira comment il compte évaluer le succès du transfert de connaissances décrit ci-dessus

2

Gestion interne des formations pour le SPF Finances, service ICT P. 67

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

III.2.6 Projet pilote Le projet pilote se place dans le cadre des décisions d’octroi de bourses d’études et a pour but de proposer aux institutions compétentes un service leur permettant de vérifier si les conditions légales en matière de montant maximum des revenus autorisés sont remplies. Pour l’instant, les institutions voulant délivrer une bourse d’étude envoient un fichier texte contenant les numéros de registre national des candidats à l’octroi d’une bourse d’étude via FTP au SPF Finances. Ce fichier est ensuite traité par un batch qui va rechercher les informations utiles dans une table dédiée de TAXI. Il est possible d’obtenir le même type d’informations via le Webservice « Taxi aanslag -- IPCAL service ». Cependant, ce service n’est pour l’instant utilisé que par la BCSS. Le projet pilote consistera à utiliser la solution ESB pour combiner et exposer au mieux les solutions existantes tout en y ajoutant les mécanismes d’authentification, d’autorisation et d’audit adéquats. Bien que les institutions délivrant des bourses d’études soient les premières concernées, les services exposés devront également être accessibles par d’autres partenaires du SPF Finances. L’analyse, le design et la réalisation de ce pilote se feront en collaboration étroite avec les équipes internes du SPF Finances. Ce projet pilote n’est pas un proof-of-concept mais bien un projet à part entière qui a pour vocation d’être mis en production. Il devra respecter les standards en place et devra utiliser pleinement les fonctionnalités de la solution ESB tels que, par exemple, entrées dans le catalogue et l’annuaire de service, définition et suivi de SLA, monitoring technique et business, gestion de la sécurité, ...

III.2.7 Renforcement de la démarche SOA L'adjudicataire évaluera le niveau de maturité SOA du SPF Finances dès le kick-off du projet. Pour cela, il utilisera le modèle de maturité ouvert et indépendant publié par Inaganti et Sriram sur 3 bptrends.com Après la mise en place de la solution ESB et la réalisation du projet pilote, une nouvelle évaluation sera effectuée pour déterminer l'évolution du niveau de maturité. L'adjudicataire rédigera ensuite des recommandations sur les actions à entreprendre pour continuer à améliorer le niveau de maturité SOA.

3

Q50.

Le soumissionnaire expliquera sa vision de ce que devrait être l'architecture de référence SOA dans le contexte spécifique du SPF Finances

Q51.

Le soumissionnaire expliquera quels sont, selon lui, les difficultés et les pièges de la mise en place de SOA dans le contexte spécifique du SPF Finances

Q52.

Le soumissionnaire expliquera quels sont, selon lui, les quick wins à mettre en œuvre pour promouvoir la démarche SOA et augmenter son niveau d'acceptation au sein du SPF Finances

Q53.

Les services au sens SOA du terme sont destinés à être réutilisés. Cependant, les attentes et le comportement des différents consommateurs peuvent varier fortement. Dans ce contexte, la gestion de SLA différents et potentiellement contradictoires devient problématique. Dans ce contexte, il est demandé au soumissionnaire de décrire sa vision et les bonnes pratiques à mettre en œuvre en ce qui concerne la gestion des SLA des services dans une architecture de type SOA

http://bptrends.com/publicationfiles/04-07-ART-The%20SOA%20MaturityModel-Inagantifinal.pdf P. 68

SERVICE PUBLIC FÉDÉRAL FINANCES

Q54.

Réf.: ICT/INF/ESB

Le soumissionnaire expliquera comment, selon lui, le cycle de vie des services, y compris la phase de maintenance, doit être géré dans un contexte SOA

III.2.8 Organisation du projet III.2.8.1 Gestion du projet et méthodologie

III.2.8.1.1 PMFin

L'adjudicataire aura recours à PMFin, notre méthodologie et procédure de gestion des projets. PMFin est la méthodologie de projet unique et standard du SPF Finances. Elle repose sur la norme internationale Prince 2. La méthodologie est appuyée par l’outil de projet ProjectMaster.

P. 69

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

III.2.8.1.2 PID Le soumissionnaire est invité à soumettre un ‘Project initiation document’ (PID) résumant les principales tâches qui doivent permettre de réaliser le projet. Ce document est pour nous un produit, une unité de travail au sein de notre propre PID.

Le Project Initiation Document répond à des exigences minimales : •

Description du contexte du projet, définition du projet, de ses objectifs, de son étendue

•

Une PBS (‘project breakdown structure’) solide et bien étayée : produits, description, critères de qualité et d'acceptation

•

Une WBS (‘work breakdown structure’) complète, un planning détaillé et réaliste du projet avec ses jalons (GANTT) et la durée des différentes phases, sous-phases, activités et tâches, les moyens à mobiliser par phase (financiers, humains et autres). Ce planning sera tenu à jour

•

Analyse détaillée des risques avec la définition des mesures de maîtrise

•

Proposition de structure du projet, compte tenu des rôles décrits dans ce chapitre

•

Dépendances avec d'autres projets

•

Plan de qualité

•

Plan de communication (avec aspects ‘change management’)

•

Rapports et suivis de l'exécution (situation et progression)

Après la réunion de coup d'envoi (‘kick-off’), le PID est finalisé, complété, enfin soumis à la validation du comité de pilotage, sponsor compris. Le soumissionnaire doit décrire sa structure et ses capacités en termes d'organisation des services professionnels : services offerts, portée géographique, niveaux et qualités du personnel. Le plan doit spécifier les tâches, leur durée et le nombre de personnes concernées, pour chaque (partie de) phase. Le plan doit aussi détailler la collaboration attendue de la part du personnel du SPF Finances. Après l'attribution du projet, le soumissionnaire élaborera un PID et un plan de projet complets et détaillés, qu'il présentera à la structure de gestion du projet du SPF Finances. L'approbation formelle du PID (planning de projet compris) ci-dessus par le comité de pilotage du projet est indispensable avant d'entamer la phase suivante. Il appartient au soumissionnaire de veiller à la tenue à jour du PID pendant toute la durée du projet. Toute modification du plan de projet doit être approuvée formellement par le comité de pilotage du projet. Le PID du soumissionnaire constituera pour notre propre PID une source d'information à propos des produits et des unités de travail dont le soumissionnaire aura la charge.

P. 70

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

III.2.8.1.3 Structures de gouvernance Tous les projets sont pilotés et gérés au sein des structures de gestion de projet du SPF Finances. Celles-ci sont représentées dans le schéma suivant :

III.2.8.1.3.1 Chef de projet Chaque projet du SPF Finances est dirigé par un chef de projet interne (business). Celui-ci est nommé par le Sponsor, en concertation avec le comité de pilotage. Le soumissionnaire désignera son propre coordinateur de projet externe (chef de projet externe). Celui-ci et le chef de projet assument l'entière responsabilité de la bonne exécution du projet.

III.2.8.1.3.2 Comité de pilotage Le comité de pilotage détient de larges compétences : il surveille le scope et les objectifs du projet, approuve le PID et le plan de projet détaillé ainsi que toutes leurs modifications, surveille l'avancement du projet, confirme l'acceptation des livrables (produits, livraisons partielles), évalue la qualité des produits partiels et finaux, et se prononce dans tous les litiges et/ou problèmes soulevés par le chef de projet. Il s'occupe de tous les aspects contractuels, administratifs et techniques de l'exécution du marché (garantie, respect des SLA, qualité de l'exécution, etc). À cette fin, le chef de projet et le coordinateur de projet externe feront régulièrement rapport au comité de pilotage : situation, progression, risques et problèmes… Le comité de pilotage regroupe le sponsor, un profil senior du soumissionnaire, le chef de projet et le coordinateur de projet externe, ainsi qu'un représentant des utilisateurs. D'autres personnes peuvent être invitées, notamment le PMO opérationnel, le coordinateur de projet ICT, le responsable du ‘work package’ ou des personnes travaillant sur des aspects spécifiques du projet.

III.2.8.1.3.3 Équipe de projet

P. 71

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

L'équipe de projet se compose de différents profils (internes et externes), dont chacun rapporte au responsable de son unité de travail (‘work package’) ou au chef de projet. Idéalement, les rôles suivants font partie de l'équipe : coordinateur de projet ICT (qui assure la liaison avec le service d'encadrement ICT), change coordinator (chargé de la gestion des changements) (P&O et Communication), coordinateur externe (contractant).

III.2.8.1.3.4 PMO opérationnel

Le PMO opérationnel peut aider le chef de projet à gérer et à maîtriser le projet, à appliquer la méthodologie PMFin, à utiliser l'outil de projet ProjectMaster, et à rédiger les rapports destinés au comité de pilotage ou au comité de direction.

III.2.8.1.3.5 Réunion de coup d'envoi (‘kick-off’) Dans un délai maximum de << 2 semaines, 3 semaines, 1 mois, 6 semaines… >> suivant l'attribution du marché, l'adjudicataire et le SPF Finances doivent tenir une première réunion du comité de pilotage, appelée réunion de coup d'envoi (ou de kick-off). La réunion officialise le début du projet. Au cours de cette première rencontre, si cela s’impose au vu du cahier des charges, on examine le PID, on présente la composition des équipes et leurs compétences professionnelles, l'agenda des réunions de rapportage et des réunions du comité de pilotage, les modalités de gestion de projet, le planning de la réalisation du marché, on explique les principes du SLA, etc. Un document rédigé en deux exemplaires par l'adjudicataire et validé par le pouvoir adjudicateur entérine officiellement le début du projet dès que la réunion de coup d'envoi a eu lieu.

III.2.8.1.3.6 Réunion du comité de pilotage Dès la réunion de coup d'envoi, le premier comité de pilotage fixe la date de ses réunions suivantes, en principe << une fois par mois / tous les 2 mois / tous les 3 mois / … >>. Le sponsor ou le chef de projet peuvent toujours convoquer un comité de pilotage en dehors des dates fixées.

III.2.8.1.3.7 Autres réunions Une fois par semaine, le chef de projet rencontre l'équipe du projet et rédige un rapport décrivant la situation du projet. Le rapport est distribué aux parties concernées importantes (à déterminer au coup d’envoi).

III.2.8.1.4 Qualité Le PID réserve une large place à la qualité. Dans le PID, le soumissionnaire explique comment il entend surveiller la qualité.

P. 72

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Par ailleurs, le SPF Finances peut demander au QUAC (Quality Assurance Control Comité) un contrôle supplémentaire du respect des normes et des standards. Un contrôle de qualité par des tiers fait également parti des possibilités.

III.2.8.1.5 Rapports À l'occasion des réunions visées ci-dessus, ainsi qu'à des moments convenus, l'adjudicataire établira les rapports nécessaires concernant les moyens mobilisés (personnel, méthodes, matériel, logiciels), l'avancement du projet, sa situation… Périodiquement, à savoir << une fois par mois / tous les 2 mois / tous les 3 mois / … >>, suivant un calendrier mis au point de commun accord lors de la réunion de coup d'envoi, l'adjudicataire rédigera un rapport complet d'avancement du projet (situation de chaque phase de la réalisation) à l'intention du comité de pilotage. Le rapport évoquera les problèmes éventuels et les solutions proposées. L'adjudicataire rédigera aussi des rapports de coordination et de travail sur l'avancement du projet (situation de chaque phase de la réalisation), les problèmes éventuels et les solutions proposées. Les réunions auront lieu ponctuellement, à la demande des parties. Le rythme de ces rencontres dépendra de la progression des phases du projet. Le lieu des réunions sera précisé par le SPF Finances avec les dates. Le soumissionnaire et le coordinateur de projet désigné par lui mettront à la disposition du chef de projet toutes les informations nécessaires pour surveiller le déroulement réel des activités du soumissionnaire et la situation par rapport au planning. Ce rapportage destiné au chef de projet suivra une fréquence hebdomadaire, sur la base d'une situation représentée sur le schéma Gantt du projet, complétée d'une brève description écrite, avec les points principaux, les problèmes éventuels et leur solution. Tous les détails des modalités de rapportage doivent être communiqués au début du projet. Tous les aspects relatifs au fond (planning, risques, qualité, réception, ressources) seront d'abord évoqués au sein de l'équipe de projet. Si le chef de projet le juge nécessaire, les problèmes seront soumis à l'examen et à la délibération du comité de pilotage. Chaque mois, le chef de projet remettra au comité de pilotage un rapport mensuel sur l'avancement du projet. Le cas échéant, le chef de projet peut inviter le coordinateur de projet externe à la réunion du comité de pilotage afin de l'éclairer plus en détail sur certains points.

III.2.8.1.6 Gestion des changements (voir aussi partie II, Gestion des changements (request for change)) Tout changement (scope, résultats/produits visés, planning, budgets) au projet doit faire l'objet d'une demande de changement spécifiant le motif et l'impact du changement. Le comité de pilotage évalue le bien-fondé et l'opportunité du changement envisagé. Il peut se faire assister du PMO (opérationnel) et/ou d'un expert (externe). L'accord formel du fonctionnaire dirigeant conditionne l'exécution des changements envisagés. Le cas échéant, l’adjudicataire devra actualiser PID.

P. 73

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

III.2.8.2 Méthode de gestion de projet La gestion du projet respectera les standards en place au SPF Finances, tels que PMFin et FUP. Il est important pour le SPF Finances d’obtenir rapidement des succès tangibles sur ce projet. Ces succès valideront les principes mis en œuvre dans l’utilisation de l’ESB et dans la promotion de la démarche SOA. Nous désirons donc que la gestion du projet acquière une orientation de type “agile” et soit basée sur des cycles cours afin d’avoir une réactivité, une traçabilité et une transparence adéquate tant sur les missions principales que sur les missions secondaires. Q55.

Le soumissionnaire expliquera comment il donnera une orientation de type “agile” aux standards de gestion de projet du SPF Finances

III.2.8.3 Missions principales Le déroulement des missions principales se fera selon le plan suivant : • • •

•

Étape 1 : En parallèle à l’évaluation du niveau de maturité SOA du SPF Finances, l’adjudicataire mettra en place la solution ESB en collaboration avec les équipes internes Étape 2 : L’adjudicataire démontrera le bon fonctionnement de la solution ESB en réalisant un proof-of-concept du projet pilote en collaboration avec les équipes internes Étape 3 : Une fois la faisabilité technique validée via le proof-of-concept, l’adjudicataire entamera ensuite la réalisation complète du projet pilote en collaboration avec les équipes internes Étape 4 : L’adjudicataire effectuera une nouvelle évaluation du niveau de maturité SOA du SPF Finances et présentera les évolutions par rapport au niveau évalué lors de l’étape 1. Il rédigera ensuite des recommandations sur les actions à entreprendre pour continuer à améliorer le niveau de maturité SOA

Les missions principales devront être terminées au plus tard 12 mois après le kick-off du projet. Q56.

Il est demandé au soumissionnaire de présenter l’équipe qu’il propose d’affecter pour la réalisation des différentes missions principales

Q57.

Le soumissionnaire décrira quels sont, selon lui, les critères permettant d’évaluer la réussite des différentes missions principales

Q58.

Il est demandé au soumissionnaire de proposer un planning de réalisation des différentes missions principales. Ce planning identifiera les différentes phases et, pour chaque phase, décrira les différentes activités constituant cette phase ainsi que les dates prévues et les délivrables associés

Q59.

Il est demandé au soumissionnaire d’expliquer comment il compte gérer la complexité du projet et les risques qui y sont associés

III.2.8.4 Profils pour les missions secondaires Pour mener à bien les missions secondaires, le SPF Finances demande à l’adjudicataire de mettre à disposition les profils suivants :

●

Chef de projet

P. 74

SERVICE PUBLIC FÉDÉRAL FINANCES

● ● ● ●

Réf.: ICT/INF/ESB

Spécialiste ESB ayant de l’expérience sur la solution ESB mise en place par l'adjudicataire Analyste programmeur senior pour la réalisation des tâches liées à l’intégration de la solution ESB Architecte IT spécialisé dans les architectures d’entreprise avec un intérêt pour SOA Expert pour l’implémentation SOA qui aidera le SPF Finances à renforcer sa démarche SOA

Le soumissionnaire remplira le tableau des prix en proposant un prix pour chacun de ces cinq profils. Le soumissionnaire présentera les CV des collaborateurs qu’il propose de mettre à disposition sur le projet. Plusieurs personnes peuvent être proposées pour un même profil, mais le soumissionnaire présentera au plus trois CV par profil. Une même personne peut être proposée pour plusieurs profils différents, mais toutes les prestations de cette personne devront être facturées au prix du profil le moins cher. Sauf cas de force majeure, l’adjudicataire s’engage à ce que les personnes dont le curriculum vitæ a été proposé soient disponibles et puissent être effectivement affectées sur le projet. Q60.

● ●

Le soumissionnaire présentera les CV des collaborateurs qu’il propose de mettre à disposition sur le projet en fonction des profils demandés. Les CV devront être présentés sur base du modèle de CV donné en annexe « curriculum vitae ». Dans sa présentation des CV, le soumissionnaire répondra aux questions suivantes : Expliquez pourquoi, selon vous, les CV proposés sont adéquats par rapport à ce projet et rencontrent les besoins du SPF Finances En combien de temps pouvez-vous mobiliser un CV proposé et l’affecter au projet ? Quels sont les SLA de mise à disposition des ressources sur le projet ?

III.2.9 SLA L’administration souhaite des Service Level Agreement concernant les missions principales avec obligation de résultat (voir Section I.1.3, « Objet du marché »). Le SLA comporte la définition de l'indisponibilité visée, la catégorisation des problèmes possibles, les différents temps de réponse exigés et les options activables. Il n'est pas demandé que le personnel de l'adjudicataire reste disponible sur site en permanence. Le SLA comporte également une définition des pénalités qui pourront être appliquées à l’égard du fournisseur si le SPF Finances constate le non-respect de ses engagements et obligations de résultat. Le SPF Finances impose que tous les taux de disponibilités des SLA présentés soient calculés sur une période d’un mois (voir également Section III.2.2.3.3, Disponibilité). Niveaux de criticité : 1. Les systèmes de production sont impactés : au moins une application ou un service ne fonctionne plus. Deux types d'applications ou de services sont alors à considérer : ● L'application ou le service est utilisée par les agents du SPF Finances pendant les heures de bureau uniquement ● L'application ou le service fait partie de services de base que le SPF offre aux citoyens et doit, à ce titre, rester disponible 24 heures sur 24 et 7 jours sur 7 Dans ce cas, une procédure de contournement du problème doit être installée dans les, respectivement, 6 et 4 heures. La correction complète du problème doit intervenir dans le premier cas dans trois jours ouvrables qui suivent, dans le deuxième cas dans les deux jours ouvrables qui suivent la survenance du problème. 2. La facilité d'utilisation des applications ou des services en production est dégradée : ● soit certaines fonctionnalités ou accès sont impossibles à certaines catégories d'utilisateurs uniquement, ● soit l'utilisation d'au moins une application ou un service faisant partie des services de base est dégradée,

P. 75

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

●

soit au moins une application ou un service non couverte par le point 1. ne fonctionne plus. Dans ce cas, une procédure de contournement du problème doit être installée dans les 10 heures. La correction complète du problème doit intervenir endéans les quatre jours ouvrables qui suivent la survenance du problème. 3. La facilité d'utilisation des applications ou des services en production n'est pas dégradée mais une fonctionnalité mineure est défectueuse. Dans ce cas, une procédure de contournement du problème doit être installée dans les 48 heures. La correction complète du problème doit intervenir endéans les cinq jours ouvrables qui suivent la survenance du problème. 4. Le problème, quelle que soit sa nature, ne concerne que les systèmes d'acceptance, et pas ceux de production. Dans ce cas, une procédure de contournement du problème doit être installée dans les deux jours ouvrables qui suivent. La correction complète du problème doit intervenir dans les dix jours ouvrables qui suivent la survenance du problème.

Q61.

Le soumissionnaire précisera comment il compte rencontrer les exigences de SLA fournies ici, et proposera un plan d'amendes afférent

Q62.

Le soumissionnaire présentera un SLA sur les autres aspects du projet sur lesquels il désire également s’engager

P. 76

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

IV. Partie D : Annexes

P. 77

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

ANNEXE A : FORMULAIRE D'OFFRE Objet de la soumission : « Mise en place d’une solution ESB » Cahier spécial des charges : « Mise en place d’une solution ESB » Identification du soumissionnaire Société Raison sociale ou dénomination : Forme juridique : Nationalité : Siège social Rue : Localité : Pays : Numéro de téléphone : Numéro de fax : Numéro de TVA : Numéro d’entreprise : et pour laquelle Monsieur/Madame (*)

N° : Boîte : Code postal :

(nom) (fonction)

domicilié(e) à l’adresse :

(rue) (code postal et commune) (pays) En cas d’approbation de la présente offre, le cautionnement sera constitué dans les conditions et délais prescrits dans le cahier spécial des charges. L’organisme de paiement du pouvoir adjudicateur payera les sommes dues par virement ou versement sur le compte n° : Code IBAN Code BIC Pour l’interprétation du contrat, la française/néerlandaise (*) est choisie. Langue Toute correspondance concernant la passation et l’exécution du marché doit être envoyée à l’adresse suivante : Personne de contact : Téléphone : Fax : E-mail : Adresse postale :

P. 78

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Par la présente, j’accepte/je n’accepte pas (biffer la mention inutile) l’utilisation des moyens de communication électronique (e-mail) pour la correspondance avec le pouvoir adjudicateur dans le cadre du présent marché.

Durée de validité de la soumission La présente soumission reste valable jusqu’au : ……………………………………. (minimum 240 jours) J’autorise le pouvoir adjudicateur à prendre toutes informations utiles (par ex. de nature financière) sur mon entreprise, auprès d'autres instances. Je m’engage à effectuer, conformément aux dispositions du présent cahier spécial des charges, les prestations/livraisons énumérées de manière détaillée dans les tableaux de prix joints à la présente soumission, et ce conformément aux tarifs y fixés. Fait:

Le

A

Le soumissionnaire ou le fondé de pouvoir : (nom) (fonction)

P. 79

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

ANNEXE B : Curriculum vitae

NB : L'utilisation de ce modèle est obligatoire. En complétant les CV, le soumissionnaire doit veiller à écrire le nom des personnes en toutes lettres. De même, il précisera clairement les diplômes et les établissements d'enseignement où ils ont été obtenus. Le pouvoir adjudicateur s'engage à traiter ces données avec une extrême discrétion et à ne les utiliser que pour les besoins de l'évaluation de l'offre. Le pouvoir adjudicateur se réserve le droit de considérer comme insuffisants les CV qui ne respecteront pas les règles ci-dessus et de ne pas les prendre en compte dans l'évaluation de l'offre. Si les diplômes mentionnés ne correspondent pas à la réalité, le pouvoir adjudicateur se réserve le droit d'exclure l'offre.

Nom

……………………………………………………

Fonction dans le projet :

…………………………………………………… …………………………………………………… ……………………………………………………

Description de la pertinence du profil pour le marché : Le soumissionnaire explique de la façon la plus détaillée possible pourquoi le profil en question est utile dans le projet. Formations : Humanités ou équivalent : • Diplôme obtenu le (date)

……………………………………………………

Enseignement supérieur non universitaire (répéter si nécessaire) : • Titre …………………………………………………… • Diplôme obtenu le (date) …………………………………………………… • Institution …………………………………………………… Enseignement supérieur universitaire (répéter si nécessaire) : • Titre …………………………………………………… • Diplôme obtenu le (date) …………………………………………………… • Institution …………………………………………………… Expérience professionnelle : Chez le soumissionnaire : •

•

• •

Fonction actuelle o Titre …………………………………………………… o Description de fonction …………………………………………………… o Depuis le …………………………………………………… Fonction précédente (répéter si nécessaire) o Titre …………………………………………………… o Description de fonction …………………………………………………… Du ……….…..……… au …………..………. Participation aux projets suivants visés à l'annexe « modèle de référence » (projet et fonction) …………………………………………………… …………………………………………………… Participation à d'autres projets importants (nom, client et fonction assumée) …………………………………………………… ……………………………………………………

P. 80

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Dans trois autres entreprises au maximum : • Fonction (répéter 3 fois maximum) …………………………………………………… Du ……….…..……… au …………..………. Compétences techniques : • Matériel (hardware) • -

Logiciels (software) Systèmes d'exploitation Bases de données Langages de programmation Applications bureautiques Autres (préciser)

…………………………………………………… …………………………………………………… …………………………………………………… …………………………………………………… …………………………………………………… …………………………………………………… ……………………………………………………

Autres compétences : • En management …………………………………………………… • En consultance …………………………………………………… • Autres (seulement si pertinent) …………………………………………………… Connaissance des langues : • Français : commentaires • Néerlandais : commentaires • Anglais : commentaires • Autres (seulement si pertinent)

compréhension - actif - passif (biffer les mentions inutiles) …………………………………………………… compréhension - actif - passif (biffer les mentions inutiles) …………………………………………………… compréhension - actif - passif (biffer les mentions inutiles) …………………………………………………… ……………………………………………………

P. 81

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Annexe C : Modèle de référence

1. Nom du projet 2. Nom de l’entreprise …………………………… 4. Nom du contact …………………………… 6. Portée du développement ou du projet …………………………… 8. Date de début (par phase) - …………………………… - …………………………… 10. Budget (EUR) …………………………… 11. Résumé et brève description du rôle et de la part des éventuels sous-traitants 12. Complexité

13. Résumé et brève description des systèmes sources 14. Résumé et brève description des systèmes pour la réalisation du projet 15. Méthode de gestion de projet 16. Aperçu des profils affectés au projet ; (nombre (TOTAL) de personnes et hommes-jours pour le projet complet

……………………………………………………………………. 3. Secteur d'activité ……………………………………………………………………. 5. Coordonnées ……………………………………………………………………. 7. Buts poursuivis

……………………………………………………………………. 9. Date de fin …………………… A. Matériel …………………… A. Nom de la ou des entreprises

B. Logiciels …………………… B. Partie du marché

C. Services …………………… C. Compétence

…………………… …………………… …………………… << Nombre d’utilisateurs, nombre de systèmes IT hors PC (nombre de mainframes, minis et serveurs) / … >> ……………………………………………………………………. A. Matériel B. Logiciels C. Environnement de développement …………………… …………………… …………………… A. Matériel B. Logiciels C. Environnement de développement …………………… …………………… …………………… Instrument/méthode ……………………………………………………………………. Profil 1 Profil 2 Profil 3 ……………………

……………………

……………………

Profil 4

Profil 5

Profil …

……………………

……………………

……………………

P. 82

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Annexe D : Formulaire de questions/réponses Remarque : Si la question ne peut être liée à un paragraphe, indiquez "général" dans la première colonne. paragraphe n° d e page

langue

Question

P. 83

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

ANNEXE E : INVENTAIRE “MISE EN PLACE D’UNE SOLUTION ESB”

La proposition des prix mentionnés dans l’offre doit, sous peine de nullité, être divisée selon les tableaux ci-après. Il ne sera tenu aucun compte des prix mentionnés à d'autres endroits. En cas de divergence entre le présent inventaire et un inventaire détaillé du soumissionnaire, les prix de l’inventaire repris en annexe du présent cahier spécial des charges seront seuls pris en compte.

a) Missions principales i) Transfert de connaissances Prix pour les formations (voir Section III.2.5, Transfert de connaissances). Le prix indiqué est le prix pour un cycle de formation complet pour un groupe de maximum 10 personnes. Ce prix comprend la documentation des produits ainsi que tous les supports de cours nécessaires.

Groupe-cible

Prix pour un cycle complet pour un groupe Hors TVA

TVA Comprise

Opérateurs Programmeurs Architectes-Analystes Chefs de projet

P. 84

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

ii) Prix des licences Prix d’une « licence processeur » permettant d’utiliser l’ensemble des logiciels composant la solution ESB selon les modalités définies au point III.2.3, « Licences ». Une description des logiciels composant l’offre de base aura été clairement mentionnée dans l’offre du soumissionnaire tel que demandé au point III.2.1.1, « Réponse à l’offre ». Hors TVA

TVA Comprise

Prix d’une « licence processeur » pour l’environnement de développement Prix d’une « licence processeur » pour l’environnement d’acceptance Prix d’une « licence processeur » pour l’environnement de production

Hors TVA Prix unitaire (par « licence processeur ») de la maintenance et du support annuel pour l’environnement de développement (donc prix pour un an et pour une licence) Prix unitaire (par « licence processeur ») de la maintenance et du support annuel pour l’environnement d’acceptance (donc prix pour un an et pour une licence) Prix unitaire (par « licence processeur ») de la maintenance et du support annuel pour l’environnement de production (donc prix pour un an et pour une licence)

Nombre de « licences processeur » pour l’environnement de production à posséder pour être considéré en licence « site » pour tous les environnements

P. 85

TVA Comprise

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

iii) Fonction de volumétrie Le tableau suivant représente la fonction de volumétrie telle que définie au point « Volumétrie » de la section III.2.3 « Licences ». Pour rappel, cette fonction retourne, pour une volumétrie donnée, le nombre de processeurs et donc de « licences processeur » qu’il est nécessaire de posséder et de mettre en place pour tenir la charge liée à cette volumétrie donnée. Le tableau se lit de la façon suivante. En ligne, on trouve la taille moyenne des messages. En colonne, on trouve le nombre moyen de messages par seconde. Les moyennes sont calculées sur une période de cinq minutes. Une intersection ligne/colonne représente donc une volumétrie donnée. Le soumissionnaire remplira le tableau en indiquant à chaque intersection ligne/colonne le nombre de « licences processeur » nécessaires pour tenir la charge de cette volumétrie sur l’infrastructure du SPF Finances. S’il n’est pas possible de tenir une certaine volumétrie, le soumissionnaire remplira la case correspondante d’un X. Attention : chacune des volumétries définies dans ce tableau de volumétrie est un engagement contractuel : s’il s’avère que, pour une volumétrie donnée, le nombre de processeurs et donc de « licences processeur » indiqué dans le tableau est insuffisant pour tenir cette volumétrie, le soumissionnaire offrira définitivement et irrévocablement, sans compensation d’aucune sorte, les « licences processeur » supplémentaires nécessaires pour tenir cette volumétrie donnée. Le soumissionnaire remplira un seul tableau de volumétrie pour l’ensemble des composants de l’offre de base de sa solution ESB.

P. 86

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Nombre moyen de messages par seconde

Taille moyenne des messages

1

2

5

7

10

15

20

1 Kio 2 Kio 5 Kio 7 Kio 10 Kio 15 Kio 20 Kio 25 Kio 50 Kio 100 Kio 200 Kio 500 Kio 1 Mio 5 Mio

P. 87

25

30

50

75

100

150

200

500

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

iv) Reste des missions principales

Hors TVA

TVA Comprise

Prix total pour la réalisation en prix fixe du reste des missions principales (voir Section I.1.3, Objet du marché) : mise en place de la solution ESB, réalisation du projet pilote, évaluation du niveau de maturité SOA, …

b) Missions secondaires i) Profils Profil

Prix en euros pour un jour-homme Hors TVA TVA Comprise

Chef de projet Spécialiste ESB Analyste programmeur senior Architecte IT Expert pour l’implémentation SOA

P. 88

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

Annexe F : Informations sur l’inventaire Remarque : le texte suivant est uniquement destiné à l’évaluation des offres de prix. Il s’agit d’un scénario possible de commande. Il ne doit pas être interprété pour faire des estimations sur la durée du marché ou sur les commandes qui seront effectivement passées par la suite.

L’évaluation du prix d’une offre est le prix total du scénario de commande. Il s’agit la somme des prix suivants :

1. Prix de la réalisation en prix fixe des missions principales (point a)iv) du tableau des prix) 2. Prix des formations : pour chacun des 4 groupes (point a)i) du tableau des prix), commande de 2 formations (1 FR et 1 NL) chaque année, pendant 6 ans. 3. Prix des profils : o La charge en jours-hommes pour les missions secondaires est estimée à 4000 jours-hommes o Les 5 types profils (point b)i)) du tableau des prix seront appliqués dans les proportions suivantes : Chef de projet : 15 % Spécialiste ESB : 25 % Analyste programmeur senior : 40 % Architecte IT : 15% Expert pour l’implémentation SOA : 5% o Le coût pour un type de profil est donc le nombre de jours-hommes multiplié par la proportion du profil multiplié par le prix du profil o Le prix total des profils est donc la somme du coût total de chaque type de profil

P. 89

SERVICE PUBLIC FÉDÉRAL FINANCES

4. Prix des licences et de la maintenance. On se base sur le scénario possible de commande suivant : Année i Nombre de licences DEV considérées pour l’année i

Réf.: ICT/INF/ESB

1

2

3

4

5

6

17

10

0

0

0

0

2 mess./sec ;

7 mess./sec ;

10 mess./sec ;

15 mess./sec ;

20 mess./sec ;

25 mess./sec ;

2 Kio de taille moyenne

2 Kio de taille moyenne

5 Kio de taille moyenne

7 Kio de taille moyenne

10 Kio de taille moyenne

15 Kio de taille moyenne

Nombre minimum de licences ACC considérées pour l’année i (pour la haute-disponibilité, le clustering, l’instanciation multiple, …)

8

8

0

0

0

0

Nombre minimum de licences PROD considérées pour l’année i

8

8

0

0

0

0

Années de maintenance et support considérées pour l’année i

6

5

4

3

2

1

Point de référence dans le tableau de volumétrie pour l’année i

Le prix des licences et de la maintenance d’une offre donnée est calculé en additionnant le prix des licences et de la maintenance pour chacune des 6 années du scénario possible de commande. P_i, le prix des licences et de la maintenace pour une année i donnée, est calculé comme suit : Définissons : • P_DEV_i : le prix pour l’année i des licences et de la maintenance pour l’environnement de développement • P_ACC_i : le prix pour l’année i des licences et de la maintenance pour l’environnement de d’acceptance • P_PROD_i : le prix pour l’année i des licences et de la maintenance pour l’environnement de production P_i = P_DEV_i + P_ACC_i + P_PROD_i

P. 90

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

On calcule P_DEV_i comme suit : Définissons : • N_DEV_i, le nombre de licences de type DEV considérées pour l’année i dans le scénario (ligne 1 du tableau ci-dessus) • DUREE_SUPP_i, le nombre d’années de support et maintenance à considérer pour les licences de l’année i (ligne 5 du tableau ci-dessus) • P_LIC_DEV, le prix d’une licence de type DEV • P_SUPP_DEV, le prix pour un an de support et maintenance pour une licence de type DEV P_DEV_i = (N_DEV_i * P_LIC_DEV) + (N_DEV_i * P_SUPP_DEV * DUREE_SUPP_i) Attention : si, à l’année i, le nombre total de licences pour l’environnement de production a atteint le nombre de licences à posséder pour être en licence site, il n’est plus nécessaire de considérer les licences de DEV pour cette année (N_DEV_i = 0) puisqu’on est en « site » pour tous les environnements

On calcule P_ACC_i comme suit : Definissons : • N_REF_i, le nombre de licences qui est inscrit dans le tableau de volumétrie du soumissionnaire au point de référence de l’année i • N_MIN_ACC_i, le nombre minimum de licences de type « acceptance » considérées pour l’année i (ligne 3 du tableau ci-dessus) On peut donc calculer N_ACC_i, le nombre de licence de type « acceptance » effectivement considérées pour l’année i dans le scénario, comme suit : N_ACC_i = MAX(N_MIN_ACC_i, N_REF_i) Attention : si, à l’année i, le nombre total de licences pour l’environnement de production a atteint le nombre de licences à posséder pour être en licence site, il n’est plus nécessaire de considérer les licences de ACC pour cette année (N_ACC_i = 0) puisqu’on est en « site » pour tous les environnements

Définissons également : • P_LIC_ACC, le prix d’une licence de type ACC • DUREE_SUPP_i, le nombre d’années de support et maintenance à commander pour les licences achetées à l’année i • P_SUPP_ACC, le prix pour un an de support et maintenance pour une licence de type ACC P_ACC_i = (N_ACC_i * P_LIC_ACC) + (N_ACC_i * P_SUPP_ACC * DUREE_SUPP_i)

P. 91

SERVICE PUBLIC FÉDÉRAL FINANCES

Réf.: ICT/INF/ESB

On calcule P_PROD_i comme suit : Definissons : • N_REF_i, le nombre de licences qui est inscrit dans le tableau de volumétrie du soumissionnaire au point de référence de l’année i • N_SITE, le nombre de licences à posséder pour être considéré en licence « site » • N_MIN_PROD_i, le nombre minimum de licences de type « production » considérées pour l’année i (ligne 4 du tableau ci-dessus) • TOTAL_N_PROD_i : la somme du nombre de licences de type « production » considérées lors des années de 1 à i-1 On peut donc calculer N_PROD_i, le nombre de licence de type « production » effectivement considérées pour l’année i dans le scénario, comme suit : N_PROD_i = MIN(N_SITE ; MAX(N_MIN_PROD_i, N_REF_i) Attention, si en considérant l’achat de licences PROD l’année i, on dépasse au total le nombre de licences nécessaires pour être en « site », on ne considèrera pour cette année i que le nombre de licences PROD pour atteindre le « site » sans le dépasser. Autrement dit : SI TOTAL_N_PROD_i + N_PROD_i > N_SITE ALORS N_PROD_i = N_SITE – TOTAL_N_PROD_i

Définissons également : • P_LIC_PROD, le prix d’une licence de type PROD • DUREE_SUPP_i, le nombre d’années de support et maintenance à commander pour les licences achetées à l’année i • P_SUPP_PROD, le prix pour un an de support et maintenance pour une licence de type PROD P_PROD_i = (N_PROD_i * P_LIC_PROD) + (N_PROD_i * P_SUPP_PROD * DUREE_SUPP_i)

P. 92