CAHIER SPECIAL DES CHARGES MARCHE PUBLIC DE SERVICES COMMUNITY CLOUD BUILDING BLOCKS APPEL D OFFRES GÉNÉRAL. Version 2 du cahier des charges

Transcription

1 CAHIER SPECIAL DES CHARGES MARCHE PUBLIC DE SERVICES COMMUNITY CLOUD BUILDING BLOCKS APPEL D OFFRES GÉNÉRAL Version 2 du cahier des charges Modifications dans le cahier des charges aux pages suivantes : Page 69, point III.10 : les licences pour les nœuds «cibles» sont ajoutée et un tableau indiquant le nombre des noeuds «cibles» dans le cadre du ce marché Page 88, annexe E ; tableau 1, 2 et 3 : tableau de prix modifié : licence pour un nœud «cible» Date de la séance d'ouverture des offres : 26 septembre 2011 à 11h. P. 1

2 Table des matières I. DISPOSITIONS ADMINISTRATIVES... 6 I.1 DESCRIPTION DU MARCHE... 6 I.2 IDENTITE DU POUVOIR ADJUDICATEUR... 6 I.3 UTILISATION PAR D AUTRES POUVOIRS ADJUDICATEURS FEDERAUX... 6 I.4 DECLARATION DE CONFIDENTIALITE... 6 I.5 MODE DE PASSATION... 7 I.6 DETERMINATION DES PRIX... 7 I.7 DUREE DU MARCHE... 7 I.8 SEANCE D INFORMATION... 8 I.9 FORME ET CONTENU DES OFFRES... 8 I.10 ASSOCIATIONS MOMENTANEES I.11 VARIANTES LIBRES I.12 OPTIONS I.13 DELAI DE VALIDITE I.14 DEPOT DES OFFRES I.15 OUVERTURE DES OFFRES I.16 PROCEDURE D ATTRIBUTION DU MARCHE I.16.1 Critères de sélection qualitative I.16.2 Régularité des offres I.16.3 Critères d attribution I.16.4 Démonstration II. DISPOSITIONS CONTRACTUELLES II.1 NOTIFICATION DE L ATTRIBUTION DU MARCHE II.2 LE BON DE COMMANDE ET SES MODALITES II.3 FONCTIONNAIRE DIRIGEANT II.4 CAUTIONNEMENT II.5 CARACTERE LIVRABLE DU SYSTEME PROPOSE II.6 EXECUTION DU MARCHE II.6.1 Clause d évolution technologique II.6.2 Délais d exécution II.6.3 Lieu d exécution du marché et particularités II.6.4 Personnel de l adjudicataire II.6.5 Sous-traitants II.6.6 Moyens mis à disposition par le SPF Finances II.6.7 Normes et standards à respecter II.6.8 Gestion des changements («change management») II.6.9 Engagements particuliers concernant les informations reçues II.6.10 Responsabilités II.7 DELAI DE LIVRAISON II.8 SUIVI DES SERVICES PRESTES ET CONTROLES PAR DES TIERS II.8.1 Suivi de la bonne exécution du marché II.8.2 Contrôles par des tiers II.9 EVALUATION DES SERVICES PRESTES ET OPERATIONS DE VERIFICATION II.10 RECEPTION PROVISOIRE II.11 GARANTIE II.12 RECEPTION DEFINITIVE II.13 MODALITES ET FRAIS DE RECEPTION II.14 PROPRIETE DES SOFTS DEVELOPPES II.15 DEPOT CHEZ UN SEQUESTRE II.16 FACTURATION, PAIEMENT ET REVISION DES PRIX II.16.1 Facturation et paiement II.16.2 Révision des prix II.16.3 Clause du client le plus avantagé II.17 PUBLICITE - REFERENCEMENT II.18 LIVRAISONS EN RETARD P. 2

3 II.19 MOYENS DE DEFENSE DE L ADMINISTRATION - LITIGES III. DESCRIPTION DES EXIGENCES TECHNIQUES III.1 OBJECTIF DU MARCHE III.1.1 Contexte général III.1.2 Objectifs du marché III.1.3 Évolution vers une solution Community Cloud III.1.4 Parties du marché III.2 PLANNING DU MARCHE III.3 DESCRIPTION DE L'EXISTANT III.3.1 Situation actuelle : processus IT opérationnels III.3.2 Situation actuelle : processus de gestion IT III.3.3 ICT Service Portal III.3.4 Gestion des services (Service Management) III.4 STRUCTURE DE L OFFRE (PARTIE TECHNIQUE) III.5 ARCHITECTURE ET CARACTERISTIQUES DE LA SOLUTION IT PROCESS AUTOMATION III.5.1 Exigences générales de l outil IT Process Automation III.5.2 Architecture de la solution demandée III.5.3 Caractéristiques de l outil IT Process Automation III.5.4 Gestion des utilisateurs III.5.5 Journalisation et rapportage III.5.6 Possibilités avancées de Cloud Computing III.6 INTEGRATIONS DANS L INFRASTRUCTURE IT III.6.1 Intégrations avec les outils de management IT du SPF Finances III.6.2 Intégration à HP ucmdb III.6.3 Intégration à Service Management III.6.4 Intégration aux services Public Cloud III.7 INTEGRATION A L IT SELF SERVICE PORTAL III.8 MISE EN ŒUVRE DES WORKFLOWS ET PROCESSUS III.8.1 Scénarios d automatisation dans le cadre de ce marché III.8.2 Mises en œuvre à réaliser durant l exécution de la phase 2 de mise en œuvre III.9 DOCUMENTATION III.9.1 Analyse et documentation des processus III.9.2 Documentation produit III.9.3 Création/génération de Runbooks III.9.4 Gestion des connaissances et outil ad hoc III.10 LICENCES III.11 LANGUE III.11.1 Langue de l outil IT Process Automation III.11.2 Langue de l ICT Service Portal III.12 TRANSFERT DE CONNAISSANCES III.12.1 Formations III.12.2 Collaboration et coaching III.13 SERVICES III.13.1 Gestion du projet et méthodologie III.13.2 Services de mise en service des outils III.13.3 Assistance à l exploitation opérationnelle III.14 EXIGENCES A REMPLIR PAR LES PROFILS III.14.1 Exigences générales à remplir par les collaborateurs du projet III.14.2 Exigences spécifiques à remplir par le développeur Java III.15 ENGAGEMENTS DE SERVICE (SLA - SERVICE LEVEL AGREEMENT) III.15.1 Niveaux de SLA III.15.2 SLA de mise en production III.15.3 SLA de garantie et de maintenance III.15.4 SLA de services III.15.5 Périodes de validité des différents SLA III.15.6 Sanctions III.15.7 Éléments des SLA à aborder P. 3

4 III.15.8 Remarques ANNEXE A : FORMULAIRE D'OFFRE ANNEXE B : CURRICULUM VITAE ANNEXE C : MODELE DE REFERENCE ANNEXE D : FORMULAIRE DE QUESTIONS/REPONSES ANNEXE E : INVENTAIRE ANNEXE F : INFORMATIONS TECHNIQUES COMPLEMENTAIRES P. 4

5 Auteur de projet Nom: Service d'encadrement ICT Adresse: Boulevard du Roi Albert II 33 bte 95 à 1030 Bruxelles Jurgen Lisabeth, informaticus Tel.: 0257/61991 Frank Baelus, adviseur Tel.: 0257/62501 Réglementation en vigueur 1. Loi du 24 décembre 1993 (MB du ) 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 ) 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 ) é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. Autres documents possibles : - Dérogations, précisions et commentaires Néant P. 5

6 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é Marché de services. Objet des services: Community Cloud Building Blocks. Lieu de livraison: Service d'encadrement ICT I.2 Identité du pouvoir adjudicateur Service Public Fédéral Finances Service d Encadrement ICT Boulevard du Roi Albert II 33 bte 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, 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. P. 6

7 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. 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, pendant une période de trois ans maximum après la conclusion du présent marché, moyennant une procédure de négociation sans publicité, de confier à l'adjudicataire de nouveaux services similaires aux services décrits dans ce cahier des charges. I.6 Détermination des prix Le présent marché consiste en un marché à bordereau de prix. Le marché à bordereau de prix est celui dans lequel seuls les prix unitaires des prestations sont forfaitaires; le prix à payer est obtenu en appliquant les prix unitaires aux quantités de prestations effectuées. 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'offre doit mentionner le prix de TVA inclusif séparé de celle-ci pour chaque partie de l'offre. 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. I.7 Durée du marché Le marché a une durée de 5 année(s) qui débute à la date d'envoi du premier bon de commande. Cette période peut être prolongée, à la demande du pouvoir adjudicateur et moyennant approbation de cette décision par le groupe de pilotage, de 2 fois un an aux mêmes conditions et aux mêmes modalités que prévues dans le contrat de base. La durée maximale de la mise en œuvre du système est fixé à douze (12) mois à compter de la date de début du marché. L adjudicataire reste donc lié contractuellement pendant le délai de la période initiale, augmenté de prolongations éventuelles. Le pouvoir adjudicateur se réserve le droit de résilier annuellement le contrat à la date de l attribution du marché, moyennant un préavis de 3 mois. Cette résiliation ne peut donner lieu a un quelconque dédommagement. P. 7

8 I.8 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 29 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 tender.cloud@minfin.fed.be La séance d'information se déroulera le 31 août 2011 à 10 h. à cette adresse : SPF Finances Boulevard du Roi Albert II 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 tender.cloud@minfin.fed.be 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 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.9 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). P. 8

9 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. 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. P. 9

10 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 I.10 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. P. 10

11 I.11 Variantes libres Il est interdit de proposer des variantes libres. I.12 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. Het niet lichten van een optie kan geen aanleiding geven tot enigerlei vorm van schadevergoeding. Lorsqu'un équipement demandé comme option obligatoire, est prévu initialement sur le matériel standard, le soumissionnaire le mentionnera expressément dans son offre. I.13 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. I.14 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 qu'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 Bruxelles nathalie.orban@minfin.fed.be 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. P. 11

12 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 qui garantit le respect des conditions de l'article 81 ter de l'ar du 8 janvier 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 informations sur le site Internet suivant : Ou via le helpdesk e-procurement : FR: Liza Torossian, , e.proc@publicprocurement.be NL: Peter Christiaens, , e.proc@publicprocurement.be 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 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.15 Ouverture des offres La séance publique d'ouverture des offres électroniques se déroulera le 26 septembre 2011 à 11h., à l'adresse suivante : SPF Finances NORTH GALAXY, Boulevard du Roi Albert II, Bruxelles. C5. Petite salle. P. 12

13 I.16 Procédure d attribution du marché I.16.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. 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 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 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 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 P. 13

14 2 n a pas pour ces déclarations une dette en coti sations supérieure à 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 à 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, à 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 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..3. 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. 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. P. 14

15 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 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 Critères de capacité technique Premier critère relatif à la capacité technique du soumissionnaire. Le soumissionnaire prouvera la réalisation de 2 projets comparables au moins, pour un nombre d utilisateurs internes comparable (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). Par projets comparables, le SPF Finances entend les projets de mise en œuvre d un «IT Process Automation»- tool pour un client public ou privé d une envergure comparable à celle du SPF Finances. À cet effet, il fournira une liste des marchés les plus importants accomplis au cours des 3 dernières années. Il fournira également une liste des projets similaires réalisés au cours de la même période, et 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 soustraitée. P. 15

16 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.16.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.16.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 ci-aprè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. Tous les critères (et tous les sous-critères éventuels) reçoivent un coefficient de pondération auquel le score obtenu sera multiplié. Les critères mentionnés ci-dessous sont les seuls qui sont traités pour effectuer le choix parmi les offres. 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. Les seuls critères d'attribution ayant des pondérations qui y sont liées pour distinguer les offres évaluées comme étant régulières, sont les suivants : 1. Prix (35%) 2. Qualité de l'offre (5%) 3. Les fonctionnalités techniques de la solution proposée (35%) : a. Fonctionnalité de l outil IT Process Automation et ses possibilités de rapportage (50%) b. Possibilités d intégration dans l architecture du SPF Finances (40%) c. Architecture technique de la solution (10%) P. 16

17 4. Services proposés (15%) a. Extension de la fonctionnalité Self Service Portal et convivialité (40%) b. Installation, configuration et mise en service (15 %) c. Formation, collaboration et coaching (15 %) d. Personnel et CV (15 %) e. SLA (15%) 5. Démonstration de la solution (10%) Sur la base des critères ci-dessus, le SPF Finances invitera le cas échéant les soumissionnaires à participer a une Démonstration (pour d autres clauses, voir paragraphe Démonstration ). Les offres suivantes n'entrent pas en considération pour la démonstration (et sont par conséquent, à ce moment déjà, exclues pour l'attribution du marché) : Les offres qui n obtiennent 60 % de la totalité des points pour le total des sous-critères de 3. Fonctionnalités techniques de la solution proposée. Les offres qui n obtiennent pas 60% des points pour les sous-critères particuliers de 3. Fonctionnalités techniques de la solution proposée. Pendant cette démonstration, le soumissionnaire fera un exposé selon les exigences du paragraphe "démonstration" (voir I.16.4). Les informations fournies pendant cet exposé seront prises en compte pour l'évaluation finale. Après démonstration, les offres suivantes seront également exclues: Les offres qui n obtiennent pas 60 % des points pour les critères particuliers «5. Démonstration de la solution» qui ont un rapport à la démonstration. En aucun cas l'objectif n'est d'ajouter de nouveaux éléments, par le biais de la démonstration, ou d'introduire une nouvelle offre. Le critère «Prix» a été pondéré comme suit : formule générale dont : P = P max Pr min Pr offerte Pr min = prix le plus bas des offres jugées régulières entrant en ligne de compte pour l attribution du marché Pr offre = prix de l offre P = points octroyés au critère «Prix» P max = pondération maximale du critère «Prix» Disposition spécifique: calcul du prix en tenant compte de la valeur du co-sourcing Le coût total du projet sera égal au coût total du projet de l offre proposée plus le coût total de l utilisation des ressources internes du SPF Finances et qui se traduit par la formule suivante : P. 17

18 p + n =1 nbvten * nbdagenn CHJ n CT = CF * CT : coût total du projet CF : coût total du projet de la firme nbvte : nombre d équivalents temps plein d une catégorie bien définie que le SPF Finances doit fournir. Dans ce marché est 1 seule catégorie prévue, c.a.d. programmeur. nbjours : nombre de jours par an qu un équivalent temps plein va travailler. Sur un an, un VTE travaille 212 jours. CHJ : coût jour-personne qui varie en fonction de la catégorie demandée n : numéro séquentiel de la catégorie - L architecte - L application designer - L application analyst - Le database designer (example : coûte 274 eur par jour) - Le programmeur (example : coûte 174 eur par jour) - Le testeur (example : coûte 174 eur par jour) Exemple Le SPF Finances reçoit 2 offres pour délivrer le même produit. La firme 1 propose une offre avec un CF de et demande 4 profils ayant une valeur de 274 / jour et 1 profil ayant une valeur de 174 /jour, tous deux pour 1 an. CT = (4*1*212*274) + (1*1*212*174) CT = La firme 2 propose une offre avec un CF de et demande 1 programmeur pour 1 an. CT = (1*1*212*174) CT = En conclusion, la firme 2 remporte le meilleur score pour le prix, car le coût des ressources internes est moindre. La détermination du score final se fait comme suit: Les nouveaux chiffres d'évaluation obtenus, mais maintenant avec le critère "Démonstration" compris, seront additionnés des points obtenus selon le critère "prix". Le marché sera octroyé au soumissionnaire qui obtient le score final le plus élevé. I.16.4 Démonstration Afin de bien évaluer l outil IT Process Automation et d obtenir les informations utiles pour pouvoir évaluer les offres, le SPF Finances priera les soumissionnaires de développer les scénarios spécifiés dans la solution proposée, au cours d une séance de démonstration. Ces scénarios seront présentés, à des dates préalablement annoncées, aux collaborateurs représentant le SPF Finances. La démonstration se compose de : P. 18

19 Définition d un ensemble de workflows dans la solution. Deux semaines à l'avance, le SPF Finances communiquera le scénario à suivre. Présentation et démonstration des fonctionnalités de la solution, suivant le cahier des charges. Le SPF Finances attire l attention des soumissionnaires sur l importance de la démonstration pour l évaluation des offres. La démonstration de la solution proposée ne peut durer plus de 2 heures. Il est également entendu que les frais de participation à la démonstration sont à la charge du soumissionnaire. La démonstration se tiendra dans les locaux du SPF Finances. Les dates des démonstrations seront fixées par le SPF Finances. Voici quelques scénarios que le soumissionnaire devra présenter à l occasion de la démonstration : Intégration à Active Directory/Internet Information Server/MS SQL Lancement d un workflow à partir d un fichier batch Création d un utilisateur dans Active Directory. Création d un utilisateur dans MS SQL Lancement d un workflow à partir d une page web (IIS). Cette liste n'est pas limitative. P. 19

20 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. 20

21 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 fournitures 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/ Fax: 0257/ louis.collet@minfin.fed.be Le surveillant des fournitures: Nom: Monsieur Frank Baelus Adresse: Service d'encadrement ICT, Boulevard du Roi Albert II 33 bte 95 à 1030 Bruxelles Téléphone: 0257/ Fax: 0257/ frank.baelus@minfin.fed.be P. 21

22 II.4 Cautionnement Le cautionnement est fixé à 5% du montant total, hors TVA, du marché. Le montant ainsi obtenu est arrondi à la dizaine d euro supérieure. 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 , IBAN: BE , 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 P. 22

23 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 Boulevard du Roi Albert II 33 bte Bruxelles Le cautionnement est libérable à la demande de l adjudicataire après la réception définitive. 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 Délais d exécution De maximale looptijd voor de implementatie van het systeem is vastgesteld op twaalf (12) maanden te tellen vanaf de aanvangsdatum van de opdracht. II.6.3 Lieu d exécution du marché et particularités II L exécution des services L'exécution du marché se déroulera principalement au Service d Encadrement ICT. 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. P. 23

24 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. II 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 à : SPF Finances Service d Encadrement ICT Boulevard du Roi Albert II, Bruxelles P. 24

25 II.6.4 Personnel de l adjudicataire Pour ce marché, l adjudicataire devra désigner un chef de projet (également décrit, dans le cadre de PMfin 1, 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, 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é. 1 une méthodologie de projet unique au sein du SPF Finances qui est basée sur la méthode internationalement reconnue Prince2 P. 25

26 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.5 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. II.6.6 Moyens mis à disposition par le SPF Finances II 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 2 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 . 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 mises à 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. P. 26

27 II Tâches des collaborateurs du SPF Finances Dans le cadre des tâches auxquelles les collaborateurs du SPF Finances seront affectés, il convient de distinguer 2 blocs, à savoir les tâches génériques et les tâches réalisées en cosourcing. Les tâches génériques sont les tâches prises en charge par le SPF Finances en sa qualité de commettant de l adjudicataire, afin de permettre à ce dernier d exécuter le projet de manière optimale. Les tâches réalisées en co-sourcing sont une série de tâches qui peuvent en principe être exécutées de manière autonome par le personnel de l adjudicataire, mais dont le SPF Finances demande qu'elles soient exécutées par ses propres membres du personnel. Tâches génériques 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 de documents dans le cadre de l exécution : 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 est 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. Tâches réalisées en co-sourcing Le SPF Finances met en œuvre une structure de co-sourcing dans le but de : stimuler le transfert de connaissances entre le personnel de l adjudicataire et les collaborateurs internes du SPF Finances ; diminuer les frais de développement et de maintenance des projets. L adjudicataire s engage à en respecter les modalités, et seul le SPF Finances est habilité à prendre la décision de ne pas (ou plus) y faire appel pendant le déroulement du marché, qu il s agisse du marché complet ou de parties. Le SPF Finances ne donne aucune garantie concernant l aptitude des collaborateurs juniors ou seniors pour les différents profils. Il est probable qu il faudra, au début du projet, considérer un certain nombre de collaborateurs comme des collaborateurs juniors, et ce, certainement en ce qui concerne le niveau technique. L appel au co-sourcing ne décharge nullement de sa responsabilité le contractant, qui doit veiller à un encadrement suffisant du personnel à intégrer, et ne la diminue pas davantage. P. 27

28 En cas de problème grave entravant le bon déroulement du projet, l adjudicataire est tenu d en informer sans délai le pouvoir adjudicateur qui prendra les mesures adéquates à la résolution du problème (formation complémentaire, remplacement de la personne mise à disposition dans le cadre du co-sourcing, etc.). II.6.7 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 (sous «ICT et plans informatiques») et (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.8 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. P. 28

29 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. 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.9 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'il aurait 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 de l adjudicataire 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 dot il s agit: P. 29

30 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. 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. P. 30

31 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 non-respect par lui-même ou par les membres de son personnel d obligations qui lui incombent en vertu du présent article. II.6.10 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 Délai de livraison La durée maximale de la mise en œuvre du système est fixée à douze (12) mois à compter de la date de début du marché. 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 P. 31

32 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 Le SPF Finances procédera aux opérations de vérification complète des équipements constitutifs de chacune des étapes de réalisation telles qu elles sont définies dans le calendrier de réalisation du projet dans les 30 jours calendrier qui suivent la notification, par l adjudicataire, de leur achèvement. Ces opérations porteront sur l'adéquation et sur le bon fonctionnement des équipements. La vérification d aptitude a pour but de constater que les installations répondent aux quantités et spécifications imposées par le SPF Finances. Le contrôle du bon fonctionnement a pour but de constater que les équipements sont capables d assurer un fonctionnement correct dans des conditions normales d exploitation (en d autres termes que l installation satisfait aux niveaux de services pré-établis). Les activités de contrôle comprennent notamment : L établissement du fait que les livraisons et les services associés ont été effectués; Le contrôle que toutes les fonctionnalités sont opérationnelles et paramétrées; Le contrôle des capacités de prestation en termes de performance, de sécurité, de robustesse, de capacité de charges, etc. P. 32

33 L installation éventuelle d outils de test afin de pouvoir exécuter les contrôles mentionnés plus haut Le contrôle de la livraison de la documentation. Si les équipements satisfont aux contrôles prévus à cette fin dans les délais fixés, ils seront considérés comme appropriés et fonctionnant bien. Le calendrier des activités de contrôle sera fixé de commun accord. Si lors des opérations de vérification, les performances et/ou des fonctionnalités requises dans le cahier spécial des charges et/ou annoncées dans l offre ainsi que dans ses documents complémentaires, ne sont pas rencontrées ou ne le sont que partiellement, l adjudicataire s engage à effectuer à ses frais les modifications ou compléments nécessaires ou à remplacer tout ou partie des fournitures logicielles par la livraison de fournitures conformes, ceci dans les 30 jours calendrier qui suivent la date du procès-verbal de constatation de l impossibilité de prononcer la réception provisoire. Au-delà de ce délai, le SPF se réserve le droit d appliquer les amendes pour retard. Dans cette hypothèse, après que l adjudicataire aura effectué les modifications, les compléments ou remplacements nécessaires, l ensemble des tests de réception devra être ré-exécuté. Si les équipements sont jugés inappropriés et/ou ne fonctionnent pas bien dans les délais fixés, le SPF Finances peut : soit appliquer les mesures d office prévues à l article 66 du cahier général des charges annexé à l A.R. du 26 septembre 1996 établissant les règles générales d exécution des marchés publics et des concessions de travaux publics ; soit convenir avec l adjudicataire de dispositions particulières. 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ès-verbal 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 réception provisoire se déroulera à la demande de l adjudicataire et portera sur les services relatifs à la livraison des licences avant l installation et l utilisation des composants logiciels, l implémentation du système, l élaboration correcte des use-cases/workflows dans les solutions proposées ainsi que la réalisation des fonctionnalités souhaitées dans le portail web ICT Service Portal. Dans le cas ou la réception provisoire partielle d'un module a un impact sur un module 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 ce module. Après chaque réception provisoire partielle commence la période de garantie du module pour une période de 1 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é. P. 33

34 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. 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 du dernier module, 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 livraison 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. L'identité de ce(s) représentant(s) sera communiquée à l adjudicataire au début de la prestation des services. P. 34

35 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 Le prestataire de services reconnaît et accepte que tous les droits de propriété industrielle et intellectuelle (notamment, sans s y limiter, les droits d'auteur, les droits sur les banques de données et les droits sur les modèles), ainsi que tous les droits de propriété et tous les autres droits relatifs aux services ou produits dans le cadre de la mission à exécuter, notamment, sans s y limiter, les études, les schémas, les analyses, les plans, les rapports, les résultats d enquêtes, la documentation, les méthodes, les banques de données, les concepts et tout autre développement, protégés ou non par un droit de propriété intellectuelle, deviennent la propriété exclusive du SPF Finances depuis leur création. 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 soustraitants. 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 contrat, 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. 35

36 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 factures doivent mentionner explicitement les licences fournies. Les frais relatifs aux services (complémentaires / auxiliaires) prestés après la réception provisoire peuvent être facturés dès leur achèvement et leur acceptation. La facture doit être établie en euros. L'adjudicataire envoie ses factures (en deux exemplaires) à l'adresse suivante : SPF Finances Service central de facturation Boulevard du Roi Albert II 33 bte 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. 36

37 La révision des prix se calcule suivant la formule : S P = P * 0,8* S0 où : P = prix revu P 0 = prix initial S 0 = 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 S 0 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 : 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 dommages-intérêts. P. 37

38 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 B 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. 38

39 III. Description des exigences techniques Remarque importante : La structure de la partie III compte 5 volets : - une description des objectifs du marché et son planning (paragraphes III.1 à III.2) - un exposé général de la situation actuelle (paragraphe III.3) - les lignes de force de la structure de l offre (paragraphe III.4) - les spécifications techniques et les caractéristiques de la solution demandée (paragraphes III.5 à III.7) - la description des services demandés (à partir du paragraphe III.8) Les soumissionnaires sont priés de suivre dans leur offre la structure des paragraphes III.5 et suivants. Le soumissionnaire doit tenir compte des standards et principes ICT du SPF Finances, ainsi que du document qui décrit l architecture du SPF Finances : Architecture Building Blocks. Ce document se trouve à l adresse Internet suivante : Principes ICT : III.1 Objectif du marché III.1.1 Contexte général Depuis un certain temps, dans le cadre du projet Copernic de modernisation du secteur public, le Service Public Fédéral (SPF) Finances s'attache à rénover profondément les processus métier (business) et les applications qui supportent ces processus. À cette fin, le SPF développe des projets IT innovants, de grande envergure, qui forment la base de son infrastructure informatique. Un grand nombre de nouvelles applications qui ont été ou seront développées font usage de composants à la pointe de la technique ICT. Parallèlement au renouvellement des applications business, l'infrastructure ICT a fait l'objet d une modernisation radicale, et des investissements permanents sont consentis pour la maintenir à son niveau. Cela signifie que l on vise une architecture technique et applicative fondée sur des éléments standard tels que : Systèmes de stockage et réseau consolidés Systèmes d exploitation standard (virtualisés) Logiciels de base standard pour l authentification et le contrôle d accès, la gestion des bases de données, la messagerie et la collaboration, les serveurs d applications et web, la gestion de contenu d entreprise, etc. Un environnement de développement basé sur le langage JAVA, avec ses outils de développement et de test. Un logiciel de gestion consolidé (ou intégré). Pour gérer l ensemble avec efficience et efficacité, d importants efforts ont permis de consolider l environnement d exploitation (monitoring, job planning) et d améliorer le service par la mise en œuvre de processus ITIL (Information Technology Infrastructure Library) dont les objectifs sont les suivants: Atteindre un niveau de service planifié, constant et mesurable Améliorer la gestion des composants ICT Justifier les coûts de tous les services IT P. 39

40 Renforcer la maîtrise des risques par des actions proactives et par des contre-mesures adéquates lorsque les circonstances l'exigent. III.1.2 Objectifs du marché Dans le cadre du présent marché, le service d encadrement ICT du SPF Finances souhaite investir dans l automatisation des tâches IT opérationnelles, avec les objectifs suivants : Créer un environnement de gestion qui permette d offrir des services ICT de façon reproductible et automatisée, en faisant appel aux ressources internes du SPF Finances (on premise) et/ou à des ressources externes (public cloud) Introduire le self-service pour les utilisateurs ICT du SPF Finances (ou d autres organisations du secteur public qui souhaitent utiliser les services du SPF Finances) via l exécution automatique des changements décrits suivant le processus ITIL v3 support request fullfilment Améliorer l efficience et la qualité du service IT en automatisant les tâches IT sous la forme de workflows trans-technologiques Accélérer le service IT en réduisant considérablement le délai d exécution Réduire l exécution manuelle des tâches opérationnelles afin d éviter un maximum d erreurs humaines et de renforcer l efficience Améliorer la transparence opérationnelle et financière dans l utilisation des ressources du data center Jeter les bases du provisioning dynamique des ressources, afin de pouvoir adapter cellesci à la charge effective ou prévue, sans que les administrateurs de systèmes doivent intervenir en cas de pointe de charge Poser les bases d une collaboration avec d autres organisations dans le secteur public par la mise en place d une infrastructure private cloud qui puisse trouver place dans un community model Améliorer l efficience par l automatisation dans les domaines suivants : Event resolution et event handling Change orchestration Automatisation des tâches répétitives Concrètement, le SPF Finances souhaite acquérir une application de IT Process Automation (souvent appelée outil d orchestration ou run-book automation tool ), développer le self-service via un catalogue de services, réaliser un ensemble d intégrations de cette application IT process automation avec des systèmes de gestion, enfin procéder à la mise en œuvre effective de runbooks prédéfinis. L'application IT process automation doit permettre à l organisation ICT d automatiser différentes tâches IT opérationnelles afin de réduire la charge de travail du personnel IT technique et de support (face à la multiplication des demandes de services IT) et de renforcer l efficience opérationnelle dans un environnement technique et organisationnel complexe. L architecture des outils utilisés doit supporter le modèle de service self-service model. Il sera fait usage d'une solution de portail web qui permettra à l utilisateur final de sélectionner et de lancer les demandes traitées via l outil IT Process Automation. La priorité va à l automatisation de run-books clairement définis, composés de plusieurs actions élémentaires (sous-processus), au sein du data center. À cet égard, on attache une grande importance aux possibilités d intégration dans l infrastructure IT hétérogène en place au SPF Finances. P. 40

41 III.1.3 Évolution vers une solution Community Cloud L intention expresse est de prolonger les réalisations déjà menées à bien en matière de consolidation, de virtualisation, de mise en œuvre des processus ITIL et de mise en œuvre des outils de management. Par le présent marché, le SPF Finances souhaite mettre en place un ensemble de fondements qui doivent permettre de constituer graduellement une offre Community Cloud favorisant un service IT efficient, à l'intention des fonctionnaires internes du SPF Finances ainsi qu'à moyen terme pour les membres du personnel d'autres organisations du secteur public. III.1.4 Parties du marché Le marché décrit dans ce cahier de charges Community Cloud Building Blocks comporte les parties suivantes : Missions principales, avec obligation de résultat Fourniture des licences nécessaires pour un logiciel IT Process Automation et des licences pour les adapters/connectors Installation et configuration du logiciel proposé Analyse technique des workflows répertoriés dans le cahier des charges Mise en œuvre des workflows dans l outil et, le cas échéant, adaptation des descriptions de service sur l ICT Service Portal Développement et adaptation de la fonctionnalité de l ICT Service Portal Missions secondaires Maintenance et support pendant toute la durée du marché Formation des gestionnaires et des utilisateurs de l outil Abonnements aux mises à jour de la bibliothèque des workflows prédéfinis et des adapters/connectors Développement et adaptation de la fonctionnalité de l ICT Service Portal Gestion du projet Assistance opérationnelle après réception provisoire de la solution III.2 Planning du marché Voici une classification des phases de la réalisation du projet telle que le SPF Finances l envisage : a) une phase de prise de contact, à laquelle l'adjudicataire prendra connaissance en détail des systèmes existants : ucmdb, portail, systèmes back-end... b) une phase d analyse à laquelle les descriptions de processus seront validées et/ou élaborées dans BMPN (avec Visio et/ou ARIS(express)) c) une première phase de mise en œuvre (réalisation architecture de base) installation de l outil d automatisation intégrations avec ucmdb et HP SM intégrations avec systèmes de back-end intégration au portail ICT User P. 41

42 d) une deuxième phase de mise en œuvre (réalisation des workflows) adaptations au portail web ICT Service Portal mise en œuvre des workflows tests migration à la production e) une phase d extension (ne fait pas partie du scope du marché dans le présent cahier des charges) serveurs bare-metal automatisation du stockage (le projet ne fait appel aux storage pools qu au niveau des hyperviseurs faisant partie du scope) automatisation réseau (le projet ne fait appel aux ressources réseau prédéfinies au niveau des hyperviseurs faisant partie du scope) intégration des déploiements applicatifs multitier intégration des ressources (le cas échéant) Le présent marché ne concerne que les phases a) à d) de la liste ci-dessus. La phase d extension e) fera l objet de marchés ultérieurs. Les phases du projet ne doivent pas être exécutées successivement. Le soumissionnaire joindra à son offre un planning détaillé du projet. La mise en œuvre des phases a) à d) doit être achevée en 12 mois. Table : Calendrier indicatief du marché Période Jalon 1 (juillet 2011) Publication du cahier des charges Community Cloud Building Blocks 2 (octobre 2011) Démonstration de la solution proposée, dans le cadre de la procédure d évaluation 3 (décembre 2011) Attribution du marché 4 (février 2012) Début du projet et de la phase de prise de contact 5 (fév. mars 2012) Phase d analyse 6 (mars-avril 2012) Phase de mise en œuvre 1 7 (mai-déc. 2012) Phase de mise en œuvre 2 8 (jan et après) Phase d extension (ne fait pas partie du scope de ce projet) 9 (décembre 2012) Réception provisiore 10 année calendrier Assistance opérationnelle année calendrier Assistance opérationnelle année calendrier Assistance opérationnelle jusqu à décembre Assistance opérationnelle année calendrier Prolongation du contrat possible année calendrier Prolongation du contrat possible 2018 P. 42

43 Les responsabilités pour la bonne exécution de la mission sont présentées dans la matrice RACI ci-dessous: Phase de prise de contact SPF Steering Aanbieder Finances I C A/R Resources SPF Finances Phase d analyse I C A/R Phase d implementation 1 Phase d implementation 1 I A/R C I A/R R 1 développeur java pour la durée de la phase d implémentation 2 (= 8 mois) RACI : I=informed; C=consulted; R=responsible; A=Accountable III.3 Description de l'existant En ce qui concerne les descriptions relatives à ce marché, le SPF Finances distingue 2 types de processus : Les processus IT opérationnels, qui conduisent à des adaptations de l infrastructure ou des configurations de l infrastructure et qui, idéalement, sont gérés dans le cadre changement management, release management ou request fulfilment management. En guise d exemple, on songe à la configuration des utilisateurs sur les systèmes, à l'adaptation des ressources des systèmes, à la création, la modification ou le décommissionnement d'instances de certains composants (serveurs, bases de données...), etc. Les processus de gestion IT, fondés sur les bonnes pratiques ITIL. Dans le cadre du présent marché, les principaux sont incident management, configuration management, change management et service level management. Les paragraphes qui suivent passent en revue l'état actuel des processus des deux types. Le présent marché met l accent sur l automatisation des processus opérationnels. III.3.1 Situation actuelle : processus IT opérationnels Pour la gestion opérationnelle des technologies utilisées par le SPF Finances au data center, on a créé une organisation qui s'appuie sur des centres de compétence par technologie. Il existe des centres de compétence pour : Gestion réseau Gestion stockage et SAN Plusieurs groupes pour la gestion de système des serveurs : o GCOS8 o BS2000 o VM/VSE o Unix-Solaris o Unix-Aix o Serveurs Windows (y compris VMWare, MS-SQL Server et SharePoint) Plusieurs groupes pour la gestion des technologies de base o Gestion de base de données DB2 P. 43

44 o o o o o o Enterprise content management FileNet P8 Collaboration Lotus Domino Batch job-scheduling centralisé Monitoring Middleware Java et déploiement des applications Etc Chaque groupe est responsable de la bonne gestion et de l évolution des technologies de son domaine. Souvent, les tâches répétitives sont déjà automatisées dans une mesure limitée, généralement à l aide de scripts écrits dans les langages de scripting propres à la plate-forme. La communication entre les centres de compétence, en vue de la réalisation des tâches opérationnelles, passe de préférence par des support request tickets, qui pourront être établis via l'ict Service Portal et traités dans l'outil Service Management. Si un même support request ticket exige une intervention de plusieurs centres de compétence, la coordination est confiée à un coordinateur (souvent le chef de projet d'une équipe de développement) ; il est alors possible d'améliorer considérablement l efficience de l ensemble et de recourir à l automatisation pour raccourcir sensiblement le temps nécessaire à la réalisation des changements IT (par exemple création et mise à disposition de serveurs virtuels). L automatisation partielle déjà réalisée dans les équipes via le scripting pourra sans aucun doute servir de base. III.3.2 Situation actuelle : processus de gestion IT Pour la gestion des processus IT, le service d encadrement ICT du SPF Finances a mis sur pied une infrastructure de processus, services et outils basée sur les bonnes pratiques ITIL. Tous les processus Service Support et Delivery sont mis en œuvre suivant le modèle de processus de bonne pratique alignability. Depuis 2005, le SPF Finances utilise à cette fin la suite HP OpenView en guise de solution Service Management. Le module central, HP OpenView Operations, surveille les différents éléments d infrastructure (réseau, serveurs d applications WebLogic/Jboss, environnement de stockage, matériel, systèmes d'exploitation) du département ICT. HP OpenView Operations (Windows) centralise la corrélation des événements : ceux-ci, y compris les end-to-end monitoring events, sont filtrés avant d'être transmis (voir aussi les schémas de l'architecture IT Service Management en annexe). En cas d incident, une support request est automatiquement créée dans HP Service Desk. D autre part, les utilisateurs finaux et les autres collaborateurs IT peuvent soumettre des demandes via un portail web ( ICT Service Portal du SPF Finances) si elles concernent les services IT. À cette fin, l utilisateur final se connecte via IAM (plate-forme Identity and Access Management du SPF Finances). Cette application détermine en liaison avec HP Service Desk les services IT pour lesquels l'utilisateur concerné peut créer des demandes. L utilisateur sélectionne le service IT souhaité (p.ex. UNIX), avec la demande correspondante (p.ex. demande de création d un utilisateur Solaris). Ensuite, il spécifie les paramètres nécessaires, avant de valider le formulaire web. Ces démarches débouchent sur la création d une Service Request (SR ou demande ) dans l application HP Service Desk. Dans les deux cas, la Support Request est attribuée à l équipe technique (groupe de travail défini dans le service IT), qui se charge ensuite des actions à mener pour aboutir à une solution. Les demandes sont traitées à la main par chaque équipe. Voir Annexe H (les figures 1 et 2) en donne une représentation schématique. Dans le Service Catalog, les services IT sont divisés en 4 groupes : Business Services (p.ex. Service BCE) e-services (p.ex. Tax-on-Web) General Services (p.ex. téléphonie IP) P. 44

45 Infrastructure Services (p.ex. Active Directory) III.3.3 ICT Service Portal Les services IT du Service Catalog se retrouvent aussi sur l ICT Service Portal. Le portail, développé au SPF Finances, donne à ses utilisateurs la possibilité de : Créer une nouvelle service request pour un service du Service Catalog Faire une recherche dans une liste de questions fréquentes Consulter le statut de leurs service requests ouvertes Signaler l indisponibilité d'un service déterminé. L ICT Service Portal possède les fonctionnalités suivantes : Une page d accueil regroupant les principales informations à l intention de l utilisateur final Une page de statut qui permet de connaître plus en détail l'état des applications. Le portail signale les applications indisponibles et les maintenances programmées. L information provient directement des outils de monitoring. Le portail lit les informations sur les alarmes dans HP OpenView Service Desk Un request center avec le Service Catalog, où les utilisateurs peuvent soumettre les demandes via des formulaires structurés Une page avec les données connues de l utilisateur connecté. Concrètement, les éléments suivants sont affichés : - les données du LDAP central - les données des Configuration Items (CI) enregistrés pour cette personne - les données des support requests en cours et clôturées. Une page où les membres des groupes de travail techniques des départements ICT peuvent signaler une maintenance programmée. Les arrêts programmés sont : - signalés par un courriel bilingue aux personnes responsables d un service - publiés sur l ICT User Portal. Une page Knowledge base où les utilisateurs peuvent consulter une liste de questions fréquentes. Cette page doit faciliter l utilisation des services IT. III ICT Service Portal : architecture L ICT Service Portal est une application de portail web composée de plusieurs applications constitutives (portlets). Une des principales fonctionnalités est le support des demandes de service. Le portail permet aussi de consulter les statuts (indisponibilités programmées ou non) des services (applications, infrastructure ). Voici une représentation logique de l architecture de l application : P. 45

46 L application utilise la technologie de portail JBoss Portal. Le portail se compose d un ensemble de portlets qui peuvent être considérés comme des sous-applications distinctes. La technologie de portail veille à la bonne organisation des différents portlets. La présentation est confiée à des pages JSP. Quant à la couche de contrôle, elle fait appel à la technologie open source Struts Bridges. En ce qui concerne la couche business du portail, nous pouvons y distinguer deux tâches : D une part le générateur d écrans : la mise en page des écrans destinés à la saisie des différents types de demandes se fait dynamiquement, sur la base des définitions de layout conservées dans la base de données. Il est possible d adapter les écrans sans changer le code. Actuellement, environ 820 lay-outs d écran sont définis. La même base de données permet de configurer les règles de validation des différents champs des écrans. D autre part, la couche business sert d interface avec HP OpenView Service Desk, où a lieu la gestion finale des demandes de service. Toutes les informations liées à ITIL (Service requests, catégorie de service, CI ) sont centralisées dans la base de données CMDB/uCMDB. La communication avec HP OpenView Service Desk passe par les bibliothèques d API fournies par l outil pour l accès en lecture/écriture. L accès en lecture seule emprunte un accès direct à la base de données HP OpenView Service Desk. Quant à la communication avec l application HP Universal CMDB, elle est confiée à des services web ou des API (selon la nature des informations échangées). Jboss Agent est chargé de la sécurité de l application. Autorisation et authentification passent par FOD/SPF IAM. Le portail envoie la demande d identification à un JBoss Agent autonome. Celui-ci communique avec IAM Access Manager, qui fait appel au LDAP pour surveiller la sécurité. À l arrivée de la réponse du portail, le JAAS Security du portail est mis en correspondance avec les données reçues. P. 46

47 Remarque importante : La description de l architecture technique du portail reflète la situation à la date de la publication de ce cahier de charges. Le SPF Finances s attend cependant à des évolutions importantes entre la date de publication et le début des mises en œuvre telles qu elles sont prévues dans le marché décrit par le cahier de charges. Voici les principales évolutions prévues : Migration de HP OpenView Service Desk 4.5 à HP OpenView Service Manager version 9.21 (ou ultérieure) Migration de la technologie de portail au produit open source LifeRay sur serveur d applications WebLogic 10. Autres évolutions fonctionnelles : meilleure intégration à HP ucmdb, poursuite de l intégration au portail web ICT Service Portal. III Portlets disponibles Voici les principales fonctionnalités accessibles via les portlets : Un Service Catalog avec demandes de service Status services (alertes, maintenance) Données personnalisées en relation avec le matériel enregistré, données personnelles, demandes de service en cours Annonce des opérations de maintenance prévues, des indisponibilités des services. III Composants technologiques Java 1.5 JBoss GA serveur d applications (le passage à WebLogic Application server v10.3 est prévu) JBoss Portal (le passage à LifeRay Portal server v6 est prévu) JBoss Agent v4.2 (évolution prévue) Maven StarTeam (système de contrôle des versions) HP OpenView Service Desk 4.5 (le passage à HP Service Manager v9.21 ou version ultérieure est prévu) HP Universal CMDB P. 47

48 III.3.4 Gestion des services (Service Management) Les départements ICT du SPF Finances appliquent les processus ITIL (v2). 1 Service Support (processus de support aux services IT) 1.1 Configuration Management (gestion de configuration) 1.2 Incident Management (gestion d'incidents) 1.3 Problem Management (gestion des problèmes) 1.4 Change Management (gestion des changements) 1.5 Release Management (gestion des versions logicielles) 2 Service Delivery (gestion du service IT) 2.1 Service Level Management (gestion des niveaux de service convenus) 2.2 Capacity Management (gestion de capacité) 2.3 Availability Management (gestion de la disponibilité) Dans la pratique, les processus suivants sont utilisés intensivement au stade actuel : Configuration Management, Incident management, Problem Management, Change Management et Service Level Management (notamment élaboration d un catalogue de services). Les autres processus en sont encore à la phase initiale. Tous les processus sont mis en œuvre suivant le modèle de processus de bonne pratique alignability. L outil retenu est HP Openview Service Desk 4.5 service pack 28 (au 17/06/2011). À l attribution du marché, il est probable que HP Service Manager v9.21 (ou une version ultérieure) soit en production. III Terminologie Dans le cadre du présent cahier des charges, la terminologie utilisée est généralement celle de HP Service Desk. La terminologie pouvant différer dans HP Service Manager, voici une définition des termes utilisés : Terminologie HP Service Desk Support Request Enregistrement de la demande d assistance que l utilisateur soumet en cas de problème dans un service. Après résolution du problème, l élément est mis à jour à l'aide des informations pertinentes et clôturé. Alarme Avis généré automatiquement (p.ex. monitoring) pour signaler une perturbation possible du service. Terminologie HP Service Manager Interaction et incident Interaction : enregistrement de la demande de l utilisateur par l équipe Service Desk. Incident : sur la base du ticket interaction, l'agent Service Desk peut décider de créer un ticket incident et de procéder ensuite à l escalade. Plusieurs interactions peuvent être liées à un même incident. Incident : Il existe plusieurs moyens pour déclencher un incident : Service Desk ; monitoring tool ; enregistrement sur le site web. Sur la base de ces informations, on crée un incident avant de procéder à l escalade. P. 48

49 III Configuration management (gestion des configurations) HP OpenView Service Desk utilise une base de données MS SQL. Dans cette base de données, on trouve les informations concernant : Support Requests ; SLA définis pour les services IT ; templates utilisés par l ICT Service Portal. Des tableaux de cette DB forment ensemble la CMDB (Configuration Management Database), et contiennent notamment des données de Service Management : services ; organisation ; personnes et configuration items (CI), ainsi que les relations entre ces CI. Depuis 2007, le SPF Finances utilise aussi HP Universal CMDB (ucmdb). Pour les composants IT du data center, cette base de données d inventaire est surtout alimentée (parallèlement à d autres sources) par un outil d autodécouverte ( VMWare vcenter Application Discovery Manager ; elle contient tous les éléments de configuration du matériel et des logiciels. L utilisation d ucmdb permet d établir des liens entre les CI. Les deux bases de données d inventaire (CMDB et ucmdb) sont synchronisées. Le département ICT s est fixé pour objectif de tenir constamment à jour ce modèle logique de tous les composants de l ensemble de l infrastructure IT ( high level configuration management plan ). Le but est d'identifier tous les composants IT et leurs versions éventuelles et de les documenter dans l'outil. Le modèle servira de base à la gestion des incidents, problèmes, changements de configuration et versions logicielles. III Incident Management (gestion des incidents) Le processus incident management sert à enregistrer, gérer et traiter les incidents frappant tous les composants de l infrastructure ICT. Le même processus est utilisé pour l enregistrement, la gestion et le traitement des demandes adressées au département ICT, à la fois par les utilisateurs finaux et les collaborateurs ICT. Comme dans tous les processus ITIL, le support du processus est confié à HP OpenView Service Desk. III Change management (gestion des changements) Les nouveaux projets ICT génèrent de nouvelles applications, dont la mise en service peut exercer un impact important sur les activités journalières dans les administrations fiscales du SPF Finances. La gestion des changements a pour but d appliquer des méthodes et procédures standardisées pour limiter l impact des changements sur l existant. Cela doit permettre d'éviter des incidents, tout en garantissant une disponibilité maximale des applications et services existants pour les utilisateurs finaux. III Architecture et infrastructure d'automatisation des processus IT déjà en place au service ICT du SPF Finances L ICT Service Portal présente les demandes par service IT. La majeure partie des demandes sont traitées à la main par l équipe technique. Certaines sont cependant exécutées en mode tout automatique via le job-scheduler VTOM. Après la sélection d une demande, une Support Request est créée dans HP Service Desk. Via HP Service Desk, le responsable d équipe IT confirme l exécution de la demande (étape approbation). Cela déclenche la chaîne de job appropriée dans le job scheduler. Après exécution de la chaîne de job (donc de l IT process flow), la support request correspondante reçoit un nouveau statut avec les informations utiles. Dans les formulaires web, les demandes automatiques comportent des champs de sélection avec des valeurs prédéfinies (CI). Ces CI provenant d ucmdb, nous disposons de données correctes pour les scripts définis dans le job scheduler. P. 49

50 P. 50

51 III.4 Structure de l offre (Partie technique) Le cahier des charges Community Cloud Building Blocks couvre plusieurs volets, notamment la sélection d un outil IT Process Automation (avec ses intégrations dans l infrastructure IT), l extension de la fonctionnalité du portail web ICT Service Portal du SPF Finances, et la réalisation des scénarios d automatisation concrets. Le soumissionnaire est prié de rédiger son offre conformément à la structure de ce cahier de charges : Architecture de la solution (paragraphe III.5) Exigences techniques de l outil IT Process automation (paragraphe III.5) Intégrations avec l infrastructure IT technique (paragraphe III.6) Intégration à l'ict Service Portal (paragraphe III.7) Mise en œuvre des workflows et processus durant le projet (paragraphe III.8) Documentation (paragraphe III.9) Licences (paragraphe III.10) Emploi des langues (paragraphe III.11) Formation, collaboration et coaching (paragraphe III.12) Services pour le projet et l exploitation opérationnelle (paragraphe III.13) Exigences imposées aux profils des collaborateurs (paragraphe III.14) SLA (paragraphe III.15) III.5 Architecture et caractéristiques de la solution IT Process automation III.5.1 Exigences générales de l outil IT Process Automation Le SPF Finances souhaite acquérir une application IT Process Automation dans le cadre de ce cahier des charges. L outil doit permettre d automatiser les processus administratifs, business et opérationnels IT au département ICT du SPF Finances. Voici les caractéristiques importantes de l application : Workflow Un workflow permet de créer une représentation visuelle des processus dans l environnement IT. Pour supporter les workflows complexes, l application doit pouvoir faire face à certaines circonstances (traitement des situations d erreur/cascade d erreurs, branching ), sur la base des informations de run-time. Orchestration L'outil IT Process Automation joue un rôle de coordination et centralise le lancement des actions sur les systèmes IT de fournisseurs différents. À partir des résultats de ces actions, l application prend les décisions logiques qui s imposent pour poursuivre ou arrêter le processus. Cela permet de raccourcir le délai entre les actions successives. Intégration aux outils d infrastructure IT L application prévoit la possibilité de consulter, d analyser, de modifier l'information et de la déplacer entre les produits et plates-formes d'un environnement IT hétérogène. À ces fins, l outil comporte des intégrations avec les divers systèmes : réseau, base de données, monitoring et ticketing. Le soumissionnaire doit proposer une solution d automatisation, composée de logiciels et services de mise en œuvre, d'intégration et de développement Java répondant aux principes suivants : Intégrable dans l architecture et l infrastructure du SPF Finances Architecture ouverte P. 51

52 Évolutivité Efficience Gestion centrale de tous les processus automatisés Sécurisation de l accès aux données et de l exécution des workflows Garantie de qualité et de performance Solution de long terme, avec feuille de route technique claire et modèle financier prédictible. La solution demandée permet de moduler visuellement les processus IT opérationnels (workflows) dans l infrastructure IT du SPF Finances dans une application IT Process Automation. L outil suivra les processus et leur exécution. Cela permettra d automatiser l exécution des processus IT et des processus de management ITIL correspondants. Plusieurs déclencheurs doivent être possibles pour lancer un workflow, notamment : - les événements issus des données de monitoring de l infrastructure IT - les demandes émanant du portail web actuel ICT Service Portal du SPF Finances - courriels entrants - déclencheurs temporels : lancement des workflows suivant un calendrier prédéfini - exécution manuelle des workflows. La fonctionnalité du portail web existant du SPF Finances doit être étendue pour supporter efficacement les processus. Durant l exécution d un process flow, l outil supporte les différents processus ITIL définis au SPF Finances ; il est donc étroitement lié aux solutions Service Management existantes. Toutes les opérations (création, modifications ) effectuées par la solution d automatisation sur les éléments de configuration doivent être correctement tenues dans la base de données d'inventaire centrale, ucmdb (et dans CMDB). III.5.2 Architecture de la solution demandée Pour élaborer l architecture, on partira d un schéma conceptuel représentant les principaux éléments et leurs relations mutuelles. La figure ci-dessous illustre les fondements ( building blocks avec leurs relations mutuelles) qui importent pour le cahier de charges Community Cloud Building Blocks. Les blocs du côté droit du schéma (AD/DNS, WebLogic, etc ) sont présents à titre illustratif seulement. Ces exemples ne limitent pas les intégrations qui font partie du scope du marché.. P. 52

53 Le soumissionnaire est prié de : Décrire en détail l architecture de la solution offerte Expliquer comment la solution offerte est tournée vers l avenir Esquisser clairement les composants de l architecture de la solution proposée (serveurs, base de données, fat clients, web client ) Préciser si la solution fonctionne avec ou sans agents Spécifier les protocoles pour les échanges de messages entre les éléments (Web services, REST, http, smtp, ftp ) Indiquer comment l outil IT Process Automation doit s'intégrer dans l'infrastructure IT du SPF Finances. À cet égard, une attention particulière doit aller aux flux de données entre les éléments du schéma conceptuel : o o o o ICT Service portal Outil IT Process Automation Configuration management database(s) Monitoring tools et event resolution Expliquer au niveau conceptuel comment les interactions entre ces composants se déroulent dans les cas suivants : o Event/Incident resolution (Incident Management) Via le monitoring, on détecte un incident (p.ex. panne de serveur). Un workflow Incident resolution and recovery est lancé à l aide de l outil IT Process Automation. o Self Service (Change Management) Via le portail web ICT Service Portal, l utilisateur sélectionne une demande de service qui se traduit par un workflow change à exécuter (p.ex. création d une nouvelle base de données MS SQL) à l aide de l application IT Process P. 53

54 o Automation. Une attention suffisante ira aux relations avec Configuration Management (HP ucmdb). Automatisation des tâches répétitives Dans l outil IT Process Automation, un workflow est lancé automatiquement, à intervalle régulier, pour prendre un back-up d une base de données. III.5.3 Caractéristiques de l outil IT Process Automation III Caractéristiques techniques Deux installations du logiciel sont prévues : Dans un environnement de développement (ou environnement de test), au sein duquel il est possible de créer et de tester les workflows IT. Dans un environnement de production. Cet environnement pilotera l infrastructure ICT de production du SPF Finances. Il doit répondre à toutes les exigences de haute disponibilité et de disaster recovery visées au paragraphe III Le soumissionnaire doit : Indiquer sur quelles plates-formes le logiciel proposé sera supporté ; conformément aux fondements ICT documentés par le SPF Finances, le logiciel doit pouvoir fonctionner sous Solaris 10 (sparc et/ou x86) ou Windows 2008 R2 server. Préciser la plate-forme qui emporte la préférence du soumissionnaire. Spécifier les ressources (serveurs, stockage) à prévoir. Décrire les procédures qui permettront migrer les workflows de l environnement de développement vers l environnement de production. Ces migrations seront confiées au personnel interne du SPF Finances. III Haute disponibilité, disaster recovery, back-up et restore Le SPF Finances a mis au point un plan de Disaster recovery : deux sites (North Galaxy Bruxelles et Diamond Board-Anderlecht) se suppléent mutuellement. La plupart des éléments de l'infrastructure IT sont dédoublés. La solution IT Process Automation fera partie du plan DRP. L outil devra aussi exécuter différentes procédures DRP. L outil doit disposer des possibilités de back-up et restauration des données (fichiers propres à l outil et base de données). Le soumissionnaire doit expliquer : Comment la solution proposée répond aux exigences de haute disponibilité. Cela suppose notamment que la solution puisse fonctionner dans un environnement en clustering. La solution doit aussi pouvoir absorber facilement les pointes de charge. Le soumissionnaire indique dans quelle mesure la solution est évolutive. Comment la solution peut être mobilisée techniquement pour supporter les scénarios de disaster recovery. Comment les back-ups et restaurations seront effectués. Le soumissionnaire expliquera clairement ce qu il propose et les possibilités de la solution en la matière. Il doit aussi exposer les possibilités de back-up en ligne ainsi que la compatibilité de la solution avec le logiciel de back-up EMC Networker. P. 54

55 III Évolution de la plate-forme logicielle Le soumissionnaire est prié de : Décrire le cycle de vie de la solution à livrer (notamment cycle de release des nouvelles versions, mises à jour automatiques des intégrations ) Décrire l évolution des bibliothèques de workflows Décrire l évolution des connectors/adapters avec les plates-formes IT intégrées. III Fonctionnalité workflow et orchestration La création et la modification des process workflows doit passer par une interface graphique centrale, unique, visuelle, intuitive et conviviale. L outil permettra d'élaborer un workflow complet sans connaissance du scripting ni des détails techniques. Le soumissionnaire doit décrire de quelle façon les process workflows seront créés. III Définition d un workflow Un IT process workflow peut résulter de différents facteurs (URL, monitoring event, calendrier, web service, API...). Le soumissionnaire doit spécifier : Quelles méthodes l outil supporte pour lancer un workflow. Les paramètres d entrée nécessaires pour lancer un workflow doivent pouvoir être introduits via ces méthodes. Quelles informations peuvent générer une étape de processus en sortie. Quelles données (saisie utilisateur, variable d environnement, XML ) peuvent servir à lancer une étape de processus. Comment (variable, fichier, XML ) il est possible de transmettre des données entre les différentes étapes d un process flow. Le soumissionnaire explique comment l outil supporte les situations suivantes : Synchronisation entre plusieurs workflows parallèles Rapports de statut concernant l exécution des jobs unitaires (bon/erreur ) Intégration en temps réel des situations d erreur dans le processus event handling existant, basé sur HP OpenView Operations (event handling) Exécution d un workflow alternatif en cas d'erreur (branching) Templates standard pour décrire une étape du workflow (p.ex. lancer un assistant pour rassembler les données nécessaires) Un process flow doit pouvoir être lancé plusieurs fois simultanément. En guise d exemple, nous songeons aux compliancy checks (p.ex. contrôle de la version des clients installés) à effectuer sur une liste de serveurs Une étape du workflow doit à son tour représenter un sous-workflow existant. Quelles sont les possibilités de classification hiérarchique des workflows? Traitement d une approbation dans un process flow Traitement d une situation d attente (p.ex. attente d un événement, d une approbation, non-réception d une approbation dans le délai ) Traitement d une étape manuelle dans un process flow Exécution des compliancy checks : nous entendons par là une comparaison des politiques techniques avec la situation réelle et le traitement des anomalies Traitement des s (création, envoi, interprétation de la réponse ) P. 55

56 Support à l exécution d un calendrier prédéfini (p.ex. quotidien, hebdomadaire, exécution dans une période déterminée ) L outil offre un ensemble de process flows standard qui couvrent un grand nombre de workflows courants (p.ex. system health check ). Ils peuvent notamment servir de base à la création de nouveaux workflows. Le soumissionnaire : Dresse la liste des workflows prédéfinis et précise dans quels domaines on peut les utiliser Explique comment on peut tenir à jour les bibliothèques de workflows prédéfinis Spécifie les abonnements nécessaires pour utiliser les workflows prédéfinis. III Débogage d un workflow Après la conception d un workflow, une session de débogage peut être lancée dans l interface graphique. Cela signifie que le workflow peut être exécuté avec ou sans les différents systèmes de management. Cela permet de valider pas à pas le déroulement logique de tout le flow (ou d'une partie, à l'aide de breakpoints). Il est possible de forcer l exécution de certains branchements du workflow en paramétrant au préalable des variables/statuts. Le soumissionnaire est prié de préciser dans quelle mesure les fonctionnalités de débogage sont supportées. III Interface utilisateur graphique Dans la solution proposée, une distinction est faite entre : Une interface graphique pour la conception des workflows. Une interface graphique pour l administration de l outil. Cette interface permet de gérer efficacement l application (gestion des utilisateurs, définition des rapports, paramétrage ) Une interface graphique pour le monitoring opérationnel des workflows. Avec cette interface, les opérateurs peuvent suivre pas à pas l exécution des processus. Le pouvoir adjudicateur souhaite une vue sur l exécution future des processus planifiés, parallèlement aux rapports d exécution des processus passés. Une interface graphique pour les utilisateurs finaux. Cette interface permet de : o visualiser les workflows que l on peut lancer pour un certain type de CI et pour certains CI o connaître le statut d une action spécifique qui a été lancée o lancer des workflows à partir d un contexte spécifique o visualiser les FAQ qui permettent de choisir le workflow convenant à une situation existante (éventuellement avec la possibilité de lancer un workflow à partir d un knowledge item). Une interface portlet/widget/webparts qui permet de faire apparaître des éléments de la solution IT Process Automation sur des portails extérieurs. On songe en particulier à la solution HP BSM (Business Service Management) et à l IT Service Portal. L accès aux fonctionnalités des différentes interfaces doit dépendre des autorisations. L'offre doit préciser le mappage possible d'active Directory et/ou des groupes LDAP avec les droits d'utilisation. (voir aussi le paragraphe III.5.4 sur la gestion des utilisateurs). Le soumissionnaire doit spécifier : Le type d interface (client ou web) prévu pour chaque partie Les fonctionnalités offertes par type d interface P. 56

57 Les éventuels chevauchements de fonctionnalités dans les interfaces graphiques. III Gestion des versions La solution proposée permet de travailler en groupe sur un projet d automatisation. À cet effet, l outil doit disposer d un outil intégré pour la gestion des versions, avec un repository central. À cet égard, voici les fonctionnalités demandées : Les changements sont identifiés par un code, le numéro de révision. Tout changement est associé à un moment dans le temps et à la personne qui a effectué le changement. Chaque fois qu un changement est chargé dans le système de gestion des versions (check-in), il peut s accompagner d un commentaire décrivant la modification. Il doit être possible d'extraire les versions antérieures du système de gestion des versions (check-out). Il est possible de comparer les changements, de les rétablir et parfois de les conjuguer. Un fichier est attribué de façon exclusive à un utilisateur déterminé ; les autres ne peuvent intervenir en même temps sur le même process flow. Lorsque l utilisateur a fini d apporter des changements, le code source est remis à la disposition des autres. Ce mécanisme de verrouillage apparaît visuellement aux yeux des autres. Les nouvelles versions peuvent être promues de l environnement de développement vers l environnement de production. Le soumissionnaire doit indiquer comment la solution offerte met en place les fonctionnalités demandées. III.5.4 Gestion des utilisateurs La solution proposée doit utiliser une authentification basée sur le nom d utilisateur et le mot de passe. L intégration dans l infrastructure LDAP ou Active Directory existante du SPF Finances est requise. Les droits des utilisateurs de l outil sont gérés à l'aide d une interface graphique. La gestion est confiée à un ou plusieurs utilisateurs remplissant le rôle d'administrateur. Dans l outil, il est possible d'assumer plusieurs rôles (p.ex. administrateur, release administrator, utilisateur...). Selon le type de rôle, on peut attribuer des droits à plusieurs utilisateurs/groupes. Le soumissionnaire expliquera comment il entend répondre à ces impératifs. Le soumissionnaire expliquera par ailleurs : Comment l authentification des utilisateurs est réalisée via les comptes dans les outils, via Active Directory et/ou LDAP Quels types de droits on peut attribuer à des utilisateurs (lecture, consultation, création de workflow ) L interface qui le permet. Comment on peut déterminer les droits de l'utilisateur à l'aide des groupes LDAP ou Active Directory. Comment les droits d utilisation sont gérés pour les composants intégrés. Comment il est possible de réaliser un SSO (single sign-on) avec les outils utilisés conjointement : Service Desk/Service Manager, outil Business Service Management, ICT Service portal et IT Process Automation. P. 57

58 III.5.5 Journalisation et rapportage III Journalisation (logging) Les activités réalisées (qui, quand, quoi ) doivent faire l objet d une journalisation détaillée, à plusieurs niveaux paramétrables. Le soumissionnaire est prié d'expliquer : Comment la journalisation des erreurs et de l exécution est réalisée. Quels journaux (logs) sont disponibles et comment leur contenu peut être exploité. III Rapportage L information qui se trouve dans un outil n est utile que dans la mesure où elle est facilement accessible. L outil doit donc disposer de larges possibilités de rapportage. Dans l application, l outil est livré avec un ensemble de rapports prêts à l'emploi. Avec ces rapports, les gestionnaires de l'application peuvent notamment : Suivre les temps d exécution des (parties de) process flows Identifier les incidents les plus courants Visualiser les étapes de processus mal exécutées Savoir quels utilisateurs ont lancé quels processus La solution proposée doit permettre de créer des rapports sur mesure à partir des informations présentes dans l outil. Les gestionnaires de l outil doivent être en mesure d'adapter les rapports existants et d en créer de nouveaux. Le soumissionnaire est également invité à répondre clairement aux questions suivantes : Quels sont les types de rapports disponibles dans l outil? Quelles sont les possibilités de recherche permettant de rassembler des données par querying? Comment peut-on créer des rapports sur mesure? Quelles sont les possibilités d exportation des résultats des recherches et des rapports? III.5.6 Possibilités avancées de Cloud Computing La solution proposée doit pouvoir supporter les évolutions futures et les possibilités avancées en matière de Cloud Computing. Le soumissionnaire explique dans quelle mesure l outil supporte les fonctionnalités ci-dessous : Multi-tenancy À moyen terme, le SPF souhaite que les autres organisations du secteur public puissent aussi profiter des fonctionnalités offertes par la solution Community Cloud. Dans quelle mesure l outil proposé supporte-t-il cette façon de faire (bases de données multiples, instances des applications, sécurité )? Transparence opérationnelle et financière Quelles possibilités l outil offre-t-il pour détermine le coût des services prestés? L efficience opérationnelle exige une vision correcte de l état d exécution réel des processus IT et business, des volumes, des pourcentages de réussite, des Incidents Quelles sont les possibilités de la solution dans ce domaine? P. 58

59 Dynamic resource provisioning Quelles possibilités l outil offre-t-il pour gérer de façon dynamique les pools de ressources (stockage, mémoire, CPU, réseau ) de l infrastructure IT (provisioning/deprovisioning)? III.6 Intégrations dans l infrastructure IT III.6.1 Intégrations avec les outils de management IT du SPF Finances Le SPF Finances souligne que la solution offerte doit permettre d absorber les évolutions futures de l'infrastructure IT. À cet effet, le soumissionnaire explique comment la solution est ouverte à ces évolutions futures des systèmes intégrés. En raison de l hétérogénéité de l infrastructure technique du SPF Finances, le soumissionnaire doit fournir en standard un ensemble de bibliothèques (adapters, connectors) pour simplifier l intégration dans l infrastructure IT du SPF Fin. Cela concerne notamment les bibliothèques relatives à : Service Management ; Event Management ; Virtualisation ; Directory Services ; Storage ; Database et Middleware. Cette énumération n'est pas limitative. Le soumissionnaire doit indiquer clairement : Quelles intégrations sont supportées en standard et comment (technologie) elles sont réalisées. Les fonctionnalités offertes pour chaque intégration. Si la solution offerte possède des modules d intégration spécifiques (p.ex. module de provisioning, disaster recovery ), il convient de les décrire. Le soumissionnaire explique aussi le déroulement des nouvelles mises à jour (updates). À cet égard, une attention spécifique ira aux nouvelles versions publiées de la solution proposée. Le soumissionnaire expliquera aussi comment les nouvelles versions des intégrations existantes avec les composants IT sont incorporées dans la solution. Enfin, l offre décrira comment les upgrades des composants IT seront intégrées aux versions des intégrations offertes. Le tableau ci-dessous répertorie les systèmes de management IT pour lesquels le SPF Finances souhaite une intégration dans l'outil IT Process Automation. Cette énumération n'est pas limitative. Si le support d'une intégration n'est pas prévu, l'offre expliquera comment la réaliser. Dans le cadre de la phase 2 de mise en œuvre (workflows), un certain nombre d'intégrations sont nécessaires et font obligatoirement partie de l'exécution du marché décrit dans ce cahier de charges. Ces intégrations sont identifiées dans la dernière colonne du tableau ci-dessous. P. 59

60 Tableau : Groupe Application Version Use case Gestion des services (Service Management) HP Service Desk 4.5 HP Service Manager 9.0 X Event Management HP OpenView Operations 8.1 X HP Business Service Management 9.0 X HP Network Node Manager 7.53 Microsoft System Center Configuration Manager 2007R3- SP2 Microsoft System Center Operations Manager Virtualisation Solaris Zones VMWare vcenter 4.1 X VMWare vsphere 4.1 X CMDB HP Universal CMDB 9.0 X Système d exploitation Microsoft Windows 2008R2 X Oracle Solaris 10 X Directory Services LDAP 7.0 X Microsoft Active Directory 2008R2 X DNS 2008R2 X Stockage Symmetrix Command Line Interface 7.2 (SYMCLI) Clariion Navisphere naviseccli 6.29 Data Domain 4.9 SAN switch brocade Fabric 6.2 Celerra Manager 5.6 EMC Ionix Controlcenter 6.1 NetWorker nsradmin 7.5 Middleware BEA Weblogic Server 10.3 IBM WebSphere 6.1 JBoss 4.2 Base de données Oracle 11g IBM DB2 9.7 Microsoft SQL Server 2008R2 Applications IBM Lotus Domino 8.5 X Windows Sharepoint Services 3.0 X IBM Filenet P8 4.5 ; 5.0 Développement et Borland Starteam 2006 déploiement XebiaLabs DeployIT 3 Divers XML Command line/scripts sur serveurs distants (SSH) Job scheduler VTOM (API) 5.0 X Le tableau ci-dessous indique le numéro de version des outils IT utilisés au sein de IT Operations. La liste n est pas limitative. À la phase d analyse, il est possible que d autres intégrations s imposent en plus du tableau ci-dessus. Les intégrations offertes doivent supporter au minimum la version spécifiée. Le SPF Finances évolue avec les versions préconisées par le fournisseur des outils utilisés. X P. 60

61 III.6.2 Intégration à HP ucmdb HP Universal CMDB (ucmdb) joue un rôle primordial dans la solution Service Management du SPF Finances : en effet, cette base de données fournit des informations à jour concernant l infrastructure IT à toutes les applications, ainsi qu'aux processus de management ITIL. La base de données d inventaire de tous les Configuration Items (CI) est notamment alimentée parallèlement à d autres sources par l outil d autodécouverte VMWare vcenter Application Discovery Manager. À ce titre, elle reflète toujours l'état actuel de l infrastructure IT. Les modifications et/ou créations de nouveaux éléments d infrastructure (avec leurs attributs) par la solution proposée doivent être mises le plus rapidement possible à la disposition de l ucmdb. Cette intégration doit tenir compte du modèle CI déjà en place dans l'ucmdb. Pour réaliser l'intégration avec l ucmdb, nous distinguons les possibilités suivantes : 1. Possibilité 1 Un connecteur standard se charge de l intégration avec l ucmdb en supportant la communication en temps réel dans les deux directions. Cela signifie qu il faut supporter des échanges de données de l ucmdb vers l outil d automatisation DB (p.ex. chargement de données), et de l outil d automatisation DB vers l UCMDB (notamment mise à jour et création de nouveaux CI). 2. Possibilité 2 A défaut de connecteur standard, on peut opter pour le développement d'un composant (à base REST, SOAP Web services ou API de programmation), pour pouvoir procéder aux échanges de données en temps réel. 3. Possibilité 3 On peut éventuellement avoir recours au concept de réplication. Cela veut dire qu une sélection de la base de données de l outil IT Process Automation est synchronisée plusieurs fois par jour avec la base de données ucmdb. L'adaptation réciproque des modèles CI (types de CI, attributs et relations) des deux outils est indispensable à cette fin. Le soumissionnaire doit indiquer : Quelle solution il choisira pour permettre l exploitation des données de l'ucmdb centrale. Le soumissionnaire choisit une solution intégrée combinant éventuellement les possibilités 1, 2 et/ou 3. Les solutions en temps réel seront préférées. L offre décrira en détail comment l intégration avec HP ucmdb sera réalisée dans la solution proposée. Comment les données (CI et relations) de l ucmdb peuvent être modifiées durant l exécution d un workflow. III.6.3 Intégration à Service Management Avec l application IT Process Automation, nous souhaitons automatiser les tâches IT opérationnelles. Outre les processus IT techniques, les différentes étapes ITIL administratives (en particulier Incident, Change, Configuration et Problem Management) devront être incorporées dans le flux général. L outil IT Process Automation assure la coordination centrale entre d une part le pilotage de la solution Service Management (HP Service Manager) et d autre part les processus de l infrastructure IT technique. Le SPF Finances attache beaucoup d importance à une intégration étroite de l outil IT Process Automation dans l application IT Service Management. Le soumissionnaire doit expliquer comment la solution proposée supportera les étapes suivantes des processus ITIL : P. 61

62 Création d une support request dans HP Service Manager Mise à jour d une support request Clôture d une support request Création ou enregistrement d une Change Request (p.ex. création d une machine virtuelle) Approbation d une Change Request. Comme pour l intégration avec HP Universal CMDB, le soumissionnaire doit indiquer comment l intégration avec HP Service Manager sera réalisée sur le plan technique. III.6.4 Intégration aux services Public Cloud Bien que le SPF Finances ne souhaite pas faire appel à court terme à des prestataires de services d infrastructure public cloud, cette possibilité n est certainement pas exclue à plus longue échéance. La solution proposée doit permettre d inclure les services public cloud dans les workflows automatisés. Le soumissionnaire doit expliquer : Comment les opérations des services public cloud seront intégrées dans les processus automatisés à l aide de la solution Pour quels services public cloud le support est déjà prévu dans l outil. III.7 Intégration à l IT Self Service Portal L IT Self Service Portal occupe une place importante dans le concept Community Cloud que le SPF Finances souhaite mettre en place. Le portail web permet au demandeur du service de spécifier de façon conviviale toutes les informations utiles concernant sa demande. Les champs précomplétés (p.ex. à partir de l ucmdb) jouent un rôle important dans la convivialité de la solution et la réduction du risque d erreur de saisie. D autre part, l exactitude des données introduites doit être contrôlée à l avance pour pouvoir lancer correctement les processus d automatisation. Le but est d enrichir le portail web existant du SPF Finances (ICT Service Portal) avec les fonctionnalités qui permettront de supporter efficacement les processus d automatisation IT. Les fonctionnalités en question sont récapitulées ci-dessous. Extension des règles de validation Des règles de validation sont déjà en place dans la DB du Service Portal. Il reste à les mettre en œuvre dans la Business Layer (Screen Generator Validator). Les règles de validation portent sur des champs dépendants. Il convient d adapter le modèle DB et de le mettre en œuvre dans la Business Layer. Dans le formulaire web de demande, les possibilités de sélection ouvertes à l utilisateur sont limitées par des listes déroulantes (notamment données issues de l ucmdb). Il faut ajouter une fonctionnalité grâce à laquelle les possibilités de sélection dans les champs seront fonction des sélections opérées antérieurement par l utilisateur. Les règles de validation des données issues de sources extérieures (p.ex. ucmdb) restent à mettre en œuvre. Affinement de la sécurité Après connexion au portail web ICT Service Portal, celui-ci affiche tous les services que l utilisateur est autorisé à spécifier dans ses demandes. L accès dépend des organisations (dont P. 62

63 l utilisateur fait partie) définies dans le SLA pour ce service. Toutes les demandes de service sont présentées pour chaque service sélectionné. Cette approche doit être affinée jusqu au niveau de la demande de service. Cela veut dire que si l utilisateur sélectionne un service (p.ex. MSSQL), le portail n affichera que les demandes de service pour lesquelles l utilisateur est autorisé. La mise en œuvre de la fonctionnalité fera appel à la solution actuelle d authentification du portail web. Succession dynamique des formulaires Pour le traitement d une demande de service, on utilise actuellement un template (formulaire ou écran) comportant les champs de saisie nécessaires. Afin de renforcer la convivialité nécessaire pour rassembler les données destinées à l'outil IT Process Automation, il doit être possible de fonctionner avec une succession dynamique d écrans (templates). Cela permettra de mettre en place sur le portail une séquence d écrans apte à simplifier le processus de fourniture d information. À cet égard, on tiendra compte des dépendances qui peuvent exister entre les différents templates ; autrement dit, le template qui apparaît à un moment déterminé dépend des sélections opérées dans le template précédent. Les dépendances entre les templates sont conditionnées par le contenu d un champ ou d une combinaison de champs. Les données saisies sont validées après chaque formulaire. Présentation du résumé de la demande Lorsque l utilisateur a complété tous les champs de la demande de service, un résumé de la demande complète doit lui être présenté avant l envoi des informations à HP Service Desk, HP Service Manager et/ou à l outil IT Process Automation. Une page web récapitulative est affichée en guise de dernier formulaire/écran du workflow. Traitement de l approbation Quand l utilisateur a fini de compléter et de valider tout le formulaire de sa demande spécifique, une support request est créée dans HP Service Desk. Cette support request est automatiquement transmise au groupe de travail correct de HP Service Desk. En fonction des données de la support request, la support request doit parfois être approuvée avant d'être confiée à l'équipe technique (responsable de l'exécution effective du service demandé). Le soumissionnaire explique : Comment ce processus d approbation se déroule en liaison avec l outil IT Process Automation. Comment ce processus se déroule en liaison avec HP Service Manager et avec l outil IT Process Automation. Si le processus d approbation exige des modifications au portail web, celles-ci doivent être décrites, avec estimation de la charge de travail. Intégration dans l outil d orchestration Quand l utilisateur a fini de compléter et de valider tout le formulaire de sa demande spécifique, une support request est créée dans HP Service Desk. S'il s'agit d'une demande à traiter par l outil IT Process Automation, le champ External Command de la support request sera complété sur la base des données saisies. Ce champ contient la commande (et ses paramètres) qui lancera un workflow spécifique dans l outil d automatisation. Dans le cadre de cette partie du cahier des charges (paragraphe III.7), le soumissionnaire est prié de faire une analyse de chaque fonctionnalité décrite. L analyse tiendra compte de l architecture technique en place (voir III.3.3 et annexe Informations techniques complémentaires ). P. 63

64 III.8 Mise en œuvre des workflows et processus À la phase 2 de mise en œuvre (voir paragraphe III.2), les fonctionnalités ci-dessous doivent être développées en détail et effectivement mises en œuvre. Le pouvoir adjudicateur insiste sur le fait qu une seule solution générique doit couvrir les use cases/scénarios visés. III.8.1 Scénarios d automatisation dans le cadre de ce marché Les scénarios/workflows faisant partie du scope du projet sont : Automatisation des tâches opérationnelles répétitives Automatisation de la création et de la gestion des machines virtuelles dans l environnement VMWare ESX Automatisation des demandes émanant de l utilisateur final Automatisation de l event resolution et des workflows event recovery Les scénarios/workflows suivants ne font pas partie du scope de la mise en œuvre : bare-metal provisioning des serveurs automatisation du stockage (le projet ne fait appel aux storage pools qu au niveau des hyperviseurs faisant partie du scope) automatisation réseau (le projet ne fait appel aux ressources réseau prédéfinies au niveau des hyperviseurs faisant partie du scope) déploiements applicatifs multitier intégration des ressources (le cas échéant). La solution proposée doit cependant rester ouverte à ces extensions futures. Le soumissionnaire est prié d expliquer toutes les extensions de l architecture qui seront nécessaires pour supporter ces développements à venir. III.8.2 Mises en œuvre à réaliser durant l exécution de la phase 2 de mise en œuvre. À la phase 2 de mise en œuvre du projet, 4 sortes de processus sont concernés : 1. Au cœur du projet, on trouve l automatisation des tâches opérationnelles répétitives et élémentaires, à accomplir fréquemment dans la gestion journalière du centre informatique (voir paragraphe III.8.2.1). 2. Un scénario plus ambitieux cible la création automatisée d une machine virtuelle dans l environnement VMWare ESX, avec l administration nécessaire pour faire fonctionner correctement la machine virtuelle (voir paragraphe III.8.2.2). 3. L automatisation des demandes fréquentes de support aux utilisateurs finaux (voir paragraphe III.8.2.3). 4. L automatisation des actions diagnostiques et correctives à exécuter en fonction des événements corrélés (par HP OpenView Operations) et détectés par les systèmes de monitoring (voir paragraphe III.8.2.4). Ces 4 parties de la mission sont décrites plus en détail dans les pages qui suivent. Après analyse des use cases, les mises en œuvre suivantes sont à mener à bien pour chaque scénario : Validation et le cas échéant adaptation des descriptions de processus BPMN Réalisation des intégrations nécessaires avec les éléments d infrastructure IT dont on a besoin pour la mise en œuvre du use case (voir table III.6.1) Intégration du use case dans l outil IT Service Management du SPF Finances. Une attention particulière ira à l enregistrement des données qui permettront la gestion du cycle de vie complet du composant IT. On songe particulièrement à : o Enregistrement des données détaillées concernant l'objet de la demande o Enregistrement de la date probable à laquelle les composants IT demandés pourront être mis hors service. o P. 64

65 Réalisation de la fonctionnalité souhaitée dans le portail utilisateur dans l'outil IT Process Automation, et renvoi d information à la CMDB pour pouvoir réaliser les use cases avec succès (adaptation des formulaires, validation des données saisies, validation des autres données, création des workflows, etc.). Dans son offre, le soumissionnaire indique : pour chaque mise en œuvre demandée ci-dessous, s il est possible d'automatiser les tâches avec la solution proposée quelle sera l approche retenue pour chacune des mises en œuvre demandées. III Automatisation des tâches répétitives L ICT Service Portal permet d exécuter un grand nombre de demandes de service via des formulaires comportant les informations essentielles au bon traitement de la demande. La plupart des formulaires du portail concernent des tâches répétitives, qui exigent actuellement une intervention manuelle d une ou plusieurs équipes techniques. On trouvera un exemple de formulaire du portail à l annexe Informations techniques complémentaires. Le tableau ci-dessous contient des exemples pratiques de demandes enregistrées via le portail. Il ne s agit que d exemples : la liste n est pas limitative. Tous les formulaires ne figurent pas dans le tableau. P. 65

66 Groupe Services Service Nom du formulaire Infrastructure Services MSSQL Demande de modification Infrastructure Services MSSQL Demande de nouvelle base de données Infrastructure Services MSSQL Demande de nouvel utilisateur de base de données Infrastructure Services MSSQL Demande d exécution d un script Infrastructure Services NWS PATCH MANAGEM ENT Remove Patch Infrastructure Services NWS PATCH MANAGEM ENT Request Patch Information Infrastructure Services NWS PATCH MANAGEM ENT Server Patch Infrastructure Services ORACLE DATABASE Demande d intervention si le service Oracle Database n est pas disponible Infrastructure Services ORACLE DATABASE Demande de back-up d une base de données Oracle Infrastructure Services ORACLE DATABASE Demande de job scheduling en relation avec une base de données Oracle Infrastructure Services ORACLE DATABASE Demande de restore d une base de données Oracle Infrastructure Services ScanFin Demande d accès Infrastructure Services ScanFin Demande de modification Infrastructure Services Sharepoint Demande de création ou de modification d un site SharePoint. Infrastructure Services STOCKAGE Demande de protection des données par back-up : - local ou autre Infrastructure Services SupDev Demande de création d un projet Infrastructure Services SupDev Demande d installation d un logiciel Infrastructure Services SupDev Demande de droits d accès Infrastructure Services UNIX Installation d une application sous Solaris Infrastructure Services UNIX Adaptation d une application sous Solaris Demande de création d un BCV d une base de Infrastructure Services UNIX données en production sous Solaris Infrastructure Services UNIX Demande de création d un système de fichiers AIX Infrastructure Services UNIX Demande de création d un système de fichiers Solaris Infrastructure Services UNIX Demande de création d un groupe Solaris Infrastructure Services UNIX Demande de suppression d un groupe AIX Infrastructure Services UNIX Demande de suppression d un groupe Solaris Infrastructure Services UNIX Demande de suppression d un utilisateur AIX Infrastructure Services UNIX Demande de suppression d un utilisateur Solaris Infrastructure Services UNIX Demande de création d une FTP Box sous AIX Infrastructure Services UNIX Demande de chargement IE931 - IE932 Infrastructure Services UNIX Demande de changement au niveau logging pour des applications et systèmes sous AIX Infrastructure Services UNIX Demande de changement au niveau logging pour des applications et systèmes sous Solaris P. 66

67 Infrastructure Services UNIX Demande d un nouvel environnement AIX Infrastructure Services UNIX Demande de modification des droits sur un fichier ou dossier sous Solaris Infrastructure Services UNIX Demande de suppression d un système de fichiers Solaris Infrastructure Services UNIX Demande de modification de la taille d un système de fichiers AIX Infrastructure Services UNIX Demande de modification de la taille d un fichier Solaris Infrastructure Services UNIX Demande de restore des logs sous Solaris Infrastructure Services UNIX Demande d exécution d une commande avec droits Root sous AIX Infrastructure Services UNIX Demande d exécution d une commande avec droits Root sous Solaris Infrastructure Services UNIX Demande de droits SUDO pour un utilisateur Solaris Infrastructure Services UNIX Demande d adaptation des paramètres d un utilisateur Solaris Infrastructure Services Web services Demande de configuration de l authentification IAM Infrastructure Services WINDOWS Demande de nouveau serveur Infrastructure Services WINDOWS Demande de modification de serveur. Le fournisseur effectuera l analyse des processus de traitement à mener à bien pour accomplir chaque tâche élémentaire. Après l'analyse technique, en concertation avec le SPF Finances, on sélectionnera les tâches élémentaires à mettre en œuvre par l adjudicataire. La sélection sera entérinée par le comité de pilotage du projet. Elle fixera les conditions de l acceptation des livrables du projet. III Déploiement d une machine virtuelle sur la plate-forme VMWare vcenter Dans l environnement Windows, la création d une machine virtuelle doit être automatisée pour VMWare ESX. Voici les sous-processus à automatiser : Contrôle des spécifications Contrôle des ressources nécessaires (suivant les données de la demande Service Portal) On pourra faire appel à une base de données des ressources libres (p.ex. adresse IP). Cette base de données reste à créer, de même que le chargement des informations sur les ressources libres et la tenue à jour de ces informations durant l'exécution du workflow. Naturellement, la CMDB peut être exploitée à cette fin. Le soumissionnaire proposera l approche de son choix. Approbation par le groupe de travail responsable Déploiement de la machine virtuelle suivant un template prédéfini Logiciel de gestion d installation, notamment clients monitoring, back-up et antivirus Enregistrement du serveur dans DNS/AD Création de la documentation et publication sur un site SharePoint Création du CI pour la machine virtuelle dans ucmdb Communication de la disponibilité de la machine virtuelle au demandeur. III Réalisation des scénarios utilisateur final Sur le portail web ICT Service Portal, l utilisateur final complète les formulaires web pour les demandes suivantes : Réinitialisation de code PIN pour téléphone IP Cette fonction self-service est déjà en place sur le portail ICT Service Portal. On demande l intégration de la fonctionnalité dans l outil IT Process Automation. Demande et gestion de boîte aux lettres fonctionnelle Dans la pratique, il est fréquent qu une boîte aux lettres soit demandée dans un but P. 67

68 spécifique et utilisée conjointement par plusieurs personnes (p.ex. : help.intervat@minfin.fed.be ). Le soumissionnaire automatisera la création de ces boîtes aux lettres, en faisant particulièrement attention au traitement administratif (enregistrement de la personne qui a demandé la boîte, données de contact pour la demande, date probable à laquelle la boîte ne sera plus nécessaire). En fonction de la date finale probable, on lancera un workflow permettant de savoir si la boîte aux lettres est encore utilisée. Si ce n est pas le cas, la boîte aux lettres inutilisée est inactivée. III Mise en œuvre des workflows de traitements des monitoring events Dans HP OpenView Operations, des scripts permettent à l opérateur d exécuter des actions diagnostiques ou correctives. Le soumissionnaire est invité à remplacer certains de ces scripts par des workflows dans l outil IT Process Automation, dans le but de réduire la complexité de ces tâches et de les rendre plus faciles à gérer. III.9 Documentation III.9.1 Analyse et documentation des processus Avant d automatiser les processus, il faut en faire une analyse détaillée, identifier les acteurs et définir les activités. Pour les besoins de cette analyse de processus, le SPF Finances souhaite faire usage de BPMN (Business Process Modelling Notation). Des analyses de processus opérationnels et gestionnels au format BPMN sont disponibles. La modélisation des processus sera de préférence confiée à l outil de modélisation ARIS. Le soumissionnaire fournira les détails nécessaires concernant : L approche retenue pour l analyse et les aspects méthodologiques La hiérarchie des schémas BPMN que le soumissionnaire juge nécessaires à la réussite de la mise en œuvre La façon d établir la correspondance entre les modélisations BPMN et les workflows définis. III.9.2 Documentation produit Le SPF Finances recevra une documentation complète de la solution proposée, tant en termes de description des processus que de logiciel. La documentation peut être livrée sous forme électronique. L outil IT Process Automation doit disposer d une documentation produit intégrée. Celle-ci doit être facilement accessible à l utilisateur. Le soumissionnaire expliquera comment il entend s y prendre. Les documents à caractère légalement contraignant doivent être disponibles en français et/ou en néerlandais. L anglais est également accepté pour la documentation technico-administrative. Toute la documentation doit être tenue à jour gratuitement durant la période de maintenance. Le soumissionnaire est prié de : Préciser la documentation livrée avec l outil La méthode d actualisation de la documentation. P. 68

69 Le SPF Finances peut copier les manuels pour les besoins de leur diffusion interne. III.9.3 Création/génération de Runbooks En fonction du process flow créé, la documentation pourra être générée facilement. Les personnes compétentes pourront ajouter elles-mêmes des informations complémentaires à la documentation. Il en résultera un IT Process Runbook, conservé dans la base de données centrale de l outil et imprimable à tout moment. Le soumissionnaire expliquera comment il entend répondre à ces exigences. III.9.4 Gestion des connaissances et outil ad hoc Dans l outil IT Automation Tool, des workflows seront créés par des spécialistes techniques afin de résoudre des situations d erreur spécifiques. Parallèlement, l équipe de monitoring opérationnel doit être en mesure de sélectionner le workflow correct pour remédier à ces erreurs (suivant des instructions...). Cela se fera sur la base d informations présentes dans l outil. Le soumissionnaire doit préciser : Comment documenter la connaissance des workflows dans l outil Comment accéder à cette connaissance par la fonctionnalité de recherche. III.10 Licences Le soumissionnaire garantit que toutes les licences dont le SPF Finances a besoin pour l exploitation propre sont comprises. Les factures doivent mentionner explicitement les licences fournies. Le fournisseur ne peut imposer de limitations à l utilisation des licences par le SPF Finances. Le transfert des licences entre systèmes comparables doit être possible. La solution proposée doit comprendre les licences suivantes : Licences serveur pour l installation de l application sur serveur. La licence doit permettre la gestion des workflows dans la solution proposée. Des licences seront prévues pour : o Répondre aux impératifs de haute disponibilité et de disaster recovery dans l environnement de production o Mettre sur pied un environnement de production et un environnement de test Toutes les licences pour les connecteurs ou adaptateurs nécessaires à la réalisation des scénarios de ce marché (voir III.8). Licences pour Noeuds "cibles" Les licences pour les systèmes cibles sur lesquels tourne le software de management et avec lequel une fonctionnalité spécifique est réalisée Par exemple: les serveurs Active Directory pour la gestion de tous les accounts pour tous les serveurs Windows. Le nombre de noeuds cibles dans le cadre de cette mission est établi comme suit : Operating system Totale des nœuds Target nœuds in scope Windows 2003/2008R Windows XP virtuele desktops ESX hosts 78 0 P. 69

70 HP-UX 2 0 AIX et Linux 23 0 Solaris Autre systems Out of scope 0 (mainframes et regionle servers) Netwerkdevices Out of scope 0 Licences clients pour l utilisation de l outil par les gestionnaires, les développeurs des workflows et les opérateurs. Il convient de faire une distinction entre les named users (administrateurs) et les concurrent/floating users (opérateurs et autres utilisateurs). On fera une distinction entre le prix d achat des licences et le support des licences. Le modèle de licence doit être expliqué en détail pour tous les éléments. Voir à ce sujet les renseignements dans le tableau de prix. P. 70

71 III.11 Langue III.11.1 Langue de l outil IT Process Automation L outil doit remplir les conditions suivantes : Disponible dans les deux langues nationales (néerlandais et français) ou Disponible en anglais. L outil peut naturellement satisfaire ces deux conditions en même temps. III.11.2 Langue de l ICT Service Portal Tous les textes et labels de l ICT Service Portal doivent obligatoirement s afficher dans la langue de l utilisateur (néerlandais ou français). La langue de l utilisateur est désignée au moment de l authentification de l intéressé. Les éventuelles traductions sont entièrement à la charge du soumissionnaire. III.12 Transfert de connaissances III.12.1 Formations Le SPF Finances souhaite donner à ses collaborateurs les formations dont ils auront besoin pour gérer eux-mêmes et faire évoluer tous les aspects des outils mis en œuvre ainsi que les intégrations réalisées. Chacune des formations requises doit être proposée en français et en néerlandais. Une formation en langue anglaise est également admise pourvu qu elle s adresse aux gestionnaires de systèmes. Un maximum de 10 personnes participeront à chaque session. La formation se déroulera dans les locaux du SPF Finances. Durant la formation, les participants se verront présenter les fonctionnalités et les différentes interfaces (client et web). La formation mettra fermement l accent sur l utilisation pratique des outils. Le soumissionnaire doit fournir le matériel pédagogique nécessaire (dias, syllabus ) aux participants à la formation. La formation sera organisée à 4 niveaux : Gestionnaires de système de l outil IT Process Automation : le soumissionnaire propose une formation aux gestionnaires du système. La formation doit donner aux gestionnaires une idée complète de l environnement et les mettre en mesure de gérer tout l environnement, dans tous ses aspects. La formation destinées aux gestionnaires de système de l outil IT Process Automation doit couvrir tous les aspects relatifs à la conception, à la mise en œuvre et à l exécution des workflows et run-books. Elle abordera aussi tous les aspects de l intégration (éventuellement via réplication) dans la base de données Configuration management. Gestionnaires des systèmes techniques : le soumissionnaire propose une formation pour les gestionnaires des systèmes techniques (Windows, Unix, stockage, réseaux, DBA, middleware, collaboration ) qui utiliseront les nouveaux systèmes d automatisation. Cette formation doit donner aux gestionnaires des centres de compétence les moyens de comprendre les modifications à leur système et d effectuer les indispensables changements dans les configurations et les installations de logiciels clients. P. 71

72 Développeurs de l ICT Service Portal : le soumissionnaire propose une formation qui conduit à connaître tous les aspects de l intégration avec l outil IT Process Automation, comprendre les modifications de l ICT Service Portal et maîtriser toutes les API nécessaires à l intégration entre l ICT User Portal et l outil IT Process Automation. Service desk et Operations Center (remarque : le Service desk et l Operations Center opèrent en conformité avec les principes ITIL) : le soumissionnaire propose une brève formation, deux fois en français et deux fois en néerlandais, pour des groupes de 10 personnes maximum. La formation est organisée de telle façon que les membres du Service desk et de l Operations Center acquièrent une connaissance suffisante pour remplir leur fonction, ainsi que le bagage nécessaire pour transférer cette connaissance à leurs collaborateurs ('train the trainer ). Pour les formations ci-dessus, le soumissionnaire décrit les objectifs, le contenu et la forme. III.12.2 Collaboration et coaching Le SPF Finances souhaite une étroite collaboration entre son personnel et celui de l adjudicataire, dans la perspective des objectifs du projet. Outre la formation, le contrat prévoit un coaching afin que le personnel du SPF Finances puisse acquérir assez de connaissances et de compétences pour prêter son concours au projet et entretenir le système, y compris les futures mises en œuvre. Le soumissionnaire doit décrire l'approche qu'il entend adopter pour veiller au transfert de connaissances durant tout le projet. Il doit aussi expliquer comment la collaboration entre son personnel et celui du SPF Finances sera planifiée. Dans son offre, le soumissionnaire doit indiquer les compétences que ces personnes doivent posséder pour pouvoir se charger du projet en fin de parcours. Il est évident que ce coaching aura pour cadre les locaux du SPF Finances. Dans leur mission, les collaborateurs de l adjudicataire se serviront des instruments de gestion informatique mis en œuvre par le SPF Finances. Il s agit essentiellement des outils HP OpenView Service desk/hp Service Manager, des applications Internet correspondantes, et des outils HP OpenView des systèmes de surveillance. Le SPF Finances organisera la formation à ces instruments à l intention des collaborateurs de l adjudicataire. III.13 Services Il est rappelé au soumissionnaire, comme mentionné à la partie II du présent cahier des charges, qu il doit joindre le curriculum vitae nominatif de toutes les personnes participant au projet, suivant le modèle de CV de l annexe C. Remarque importante : Le soumissionnaire garantit que sauf cas de force majeure, les personnes dont le curriculum vitae est joint à l'offre seront effectivement disponibles pour mener à bien le projet, pendant toute la durée de celui-ci. III.13.1 Gestion du projet et méthodologie 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 s'appuie sur la norme internationale Prince 2. La méthodologie est appuyée par l outil de projet ProjectMaster. P. 72

73 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. P. 73

74 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, les moyens nécessaires par phase (financiers, humains et autres). Ce planning sera tenu à jour. Une 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 suivi 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 constituera pour notre propre PID une source d'information à propos des produits et des unités de travail dont le soumissionnaire aura la charge. 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 : P. 74

75 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. Le 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. Équipe de projet 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). P. 75

76 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. Réunion de coup d'envoi ( kick-off ) Dans le mois calendrier qui suit 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 kickoff). 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. Réunion du comité de pilotage Après la réunion de coup d'envoi, le premier comité de pilotage fixe la date de ses réunions suivantes. Le sponsor ou le chef de projet peuvent toujours convoquer un comité de pilotage en dehors des dates fixées. 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). Qualité Le PID réserve une large place à la qualité. Dans le PID, le soumissionnaire explique comment il entend surveiller la qualité. Par ailleurs, le SPF Finances peut demander au QUAC (Quality Assurance Control Comité) ou à un tiers un contrôle supplémentaire du respect des normes et des standards. 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, 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 P. 76

77 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 de 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 remet 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. Gestion des changements 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 décide du bien-fondé et de l'opportunité du changement envisagé. Il peut se faire assister du PMO (opérationnel) et/ou d'un expert (externe). L'accord formel du comité de pilotage conditionne l'exécution des changements envisagés. Le cas échéant, le soumissionnaire se fera assister dans l'actualisation du PID. III.13.2 Services de mise en service des outils Ces services couvrent toutes les activités de mise en service et de démarrage de l outil. Ils doivent notamment couvrir les éléments suivants : Installation et configuration sur mesure de tous les composants de l outil. Support au démarrage et à la mise en service du programme. Fourniture de la documentation destinée aux utilisateurs et aux gestionnaires du programme. Ces services doivent être assurés en étroite collaboration avec les équipes concernées du pouvoir adjudicateur, en particulier l équipe responsable des projets d automatisation. Le logiciel doit être installé avec la collaboration des gestionnaires de systèmes du SPF Finances. Le soumissionnaire doit prévoir la documentation nécessaire à l installation du logiciel afin que le personnel du maître d ouvrage puisse par la suite se charger lui-même de l installation. Dans son offre, le soumissionnaire inclut un plan d installation et de configuration bien étudié pour le lancement de la mise en service. Le soumissionnaire doit élaborer le plan et le tenir à jour. Le soumissionnaire décrira les exigences imposées en matériel et des spécifications du logiciel avant l installation de la solution. À cet égard, il doit tenir compte explicitement des spécifications des plates-formes standard visées dans les fondements ICT du SPF Finances. La fourniture du matériel ne fait pas partie du présent marché. P. 77

78 III.13.3 Assistance à l exploitation opérationnelle Après la réception provisoire (après la deuxième phase de mise en œuvre), le soumissionnaire prévoit pour le SPF Finances une assistance technique représentant une charge maximale de 90 jours/homme par an (pendant 4 ans). Le soumissionnaire est invité à proposer un prix unitaire. Le SPF Finances pourra faire appel à cette assistance par tranches minimales d'un demi-jour. Le SPF Finances se réserve le droit d utiliser tous les jours non prévus, et de les utiliser suivant une répartition non proportionnelle. L assistance technique comprend un examen régulier du bon état des packages logiciels, l installation des mises à jour et la simplification ultérieure de la gestion. Exceptionnellement, pour des opérations de maintenance ou upgrade des systèmes concernés, des prestations en dehors des heures ouvrables normales sont possibles. III.14 Exigences à remplir par les profils III.14.1 Exigences générales à remplir par les collaborateurs du projet Les profils proposés par le soumissionnaire pour ce marché doivent faire preuve des qualités suivantes : autonomie initiative flexibilité travail en équipe, aptitude à la communication orale et écrite connaissance du français et/ou du néerlandais Une bonne connaissance d ITIL est un plus, de même que l'expérience du travail par processus. L adjudicataire produit les CV qui répondent aux conditions imposées. III.14.2 Exigences spécifiques à remplir par le développeur Java Outre les exigences générales imposées à tous les collaborateurs du projet, le ou les développeurs Java doivent remplir des critères supplémentaires (aussi bien pour les profiles proposer par le soumissionair, ainsi que pour les profiles prévu par SPF Finances) : Langage de programmation JAVA J2EE Connaissance et expérience pratique de JBoss Portal et du serveur d applications JBoss Connaissance et expérience pratique des services web et des protocoles REST Connaissance de Maven, Struts, XML et des technologies web La connaissance de HP Service Manager est un plus La connaissance de HP Universal CMDB est un plus. Tous les expertises qui permettent de parcourir les étappes suivent : Analyse l étude Programmation Contrôle l'intégrité des composants de l'application Teste les programmes Documentation et publication des programmes Maintenance des programmes P. 78

79 Documentation des programmes Paramétrage des packages Diagnostic et choix de la méthode de résolution Construction, évaluation et intégration de la solution Interaction avec les bases de données Confirmation de la solution Outre ce qui est déjà décrit dans la partie B du cahier des charges, le co-sourcing doit avoir pour but de constituer une équipe cohérente, pendant la durée du projet comme après la réception provisoire. Concrètement, cela signifie que : Pendant la durée du projet, des collaborateurs du SPF Finances seront intégrés à l'équipe du projet. Après la réception provisoire, ces mêmes personnes doivent disposer de connaissances suffisantes et pouvoir compter sur leur soutien mutuel pour assumer elles-mêmes l'exploitation. Dans son offre, le soumissionnaire expliquera clairement comment il entend procéder : méthodes de collaboration, liaison (éventuelle) avec les formations, répartition des tâches, suivi et évaluation des compétences, etc). Le nombre d équivalents temps plein pour le présent marché pour des développement en java s'élève à 1 ETP pour la durée du phase d implémentation 2 (= 8 mois). Ce nombre d'etp est contraignant ; l'offre ne peut y déroger. Un ETP représente 212 jours/homme (de 7h36 minutes) par an. Le soumissionnaire utilisera les profils visés ci-après. Le soumissionnaire dispose des latitudes suivantes, à condition d'argumenter ses choix dans son offre : Pour un profil déterminé, il peut demander zéro, un ou plusieurs collaborateurs La charge de travail peut être variable, mais le soumissionnaire doit veiller à ne jamais mobiliser simultanément plus de1 employé du SPF Finances en co-sourcing. Dans son offre, le soumissionnaire indique comment les collaborateurs demandés se répartissent par rapport au nombre total d ETP et à leurs tâches. Il décrit aussi les connaissances que ces personnes doivent posséder, sachant qu'il ne peut exiger de compétences dépassant le cadre des standards ICT. III.15 Engagements de service (SLA - Service level agreement) À partir de la date où une réception provisoire est prononcée jusqu'à l'expiration de la période de maintenance, l'adjudicataire s'engage à maintenir les niveaux de services convenus dans les SLA pour les systèmes. Le SPF Finances ne transigera pas sur les exigences en matière de service. III.15.1 Niveaux de SLA Le SPF Finances souhaite définir trois niveaux de SLA, adaptés aux différentes phases/services : a) SLA portant sur la mise en production des éléments b) SLA portant sur la période de garantie et la période de maintenance c) SLA portant sur les services assurés par le personnel mis à disposition. III.15.2 SLA de mise en production Durant la mise en production des différents éléments, le SPF Finances validera les SLA (livrables et composants) par rapport aux objectifs définis et consolidés dans les phases d'analyse au début du projet. P. 79

80 L'adjudicataire doit proposer une méthode de validation qui garantit la cohérence par rapport aux objectifs fixés, en termes de fonctionnalités disponibles, de performances à fournir, de données à traiter, etc, sans oublier les résultats à atteindre lors des phases de déploiement. Remarque importante : En ce qui concerne la mise en production et la qualité de la production, le SPF Finances demande un engagement de résultat aux conditions énoncées dans le présent cahier des charges. Des mesures correctives seront proposées pour les cas de différence entre les objectifs et les résultats, avec application du SLA que le soumissionnaire doit proposer pour ce genre de situation. Les sanctions doivent être complémentaires aux pénalités prévues pour les phases de réalisation des modules. Il importe par ailleurs que le SLA spécifie le traitement à réserver aux délais : le SPF Finances attache une grande importance aux mesures à prendre en cas de dépassement des délais de mise en production des différents modules. III.15.3 SLA de garantie et de maintenance À partir de la mise en production et jusqu'à la fin du marché, le soumissionnaire veille au respect du niveau de service défini dans les SLA. Ce SLA porte notamment sur : la fiabilité, ou le temps moyen entre pannes ; la disponibilité du personnel du soumissionnaire ; les performances (notamment les temps de réponse - dans 90 des cas - pour une consultation, une mise à jour, avec description précise de l'environnement de mesure des performances) ; sécurité et intégrité des données; la maintenance et l'assistance : Le délai d intervention maximum en cas de panne, garantie de disponibilité de l application; le délai maximum de réparation et/ou de résolution du ou des problèmes ; Le soumissionnaire est libre de compléter cette liste à sa guise. III.15.4 SLA de services Dans son offre, le soumissionnaire est invité à exposer les mesures qu'il prendra pour garantir la qualité et le niveau de service, ainsi que la qualité du développement, du suivi et de l'accompagnement du projet, du suivi et du respect des plannings, des livrables, etc. III.15.5 Périodes de validité des différents SLA On distingue les périodes suivantes : Mise en production : à partir du premier élément jusqu à la fin de la mise en production du dernier élément. Garantie et maintenance : à partir du début de la première période de garantie jusqu à la fin du marché. Services : pendant toute la durée du marché. III.15.6 Sanctions Le non-respect d'un élément de SLA est sanctionné d'une pénalité. Il n'entre pas dans les intentions du SPF de réduire ses coûts par le biais des pénalités, mais seulement d'inciter l'adjudicataire à respecter tous ses engagements afin que les utilisateurs ne soient pas lésés. P. 80

81 Les pénalités de non-respect d'un élément de SLA doivent être proposées par le soumissionnaire, en pourcentage du prix de l'exécution des différents éléments. Ce montant de base du calcul reste d'application pendant toute la période de garantie. III.15.7 Éléments des SLA à aborder Remarque : TOUS les SLA seront affinés pendant l'exécution du projet. Pour chaque SLA, l'offre décrira : Objectifs du SLA Scope Date de début et conditions de modification Rôles et responsabilités o SPF Finances o Fournisseur Services offerts Procédure de traitement des réclamations o du SPF Finances, adressées à l'adjudicataire o de l'adjudicataire, adressées au SPF Finances Rapportage Concertation Informations de contact Normes et pénalités du SLA (y compris mesures, définition des normes) En outre, pour garantie et maintenance et disponibilité et performances, le SLA couvrira : Processus et procédures o Gestion des incidents o Gestion des problèmes o Gestion des changements o Gestion des configurations III.15.8 Remarques Les SLA sont obligatoirement mesurés par périodes de 3 mois (dans la limite des possibilités). Le SPF Finances peut, s'il le souhaite, faire contrôler et exécuter les mesures du SLA, à ses frais, par un bureau d'étude indépendant. P. 81

82 ANNEXE A : FORMULAIRE D'OFFRE Objet de la soumission : «Community Cloud Building Blocks» Cahier spécial des charges : «Community Cloud Building Blocks» Identification du soumissionnaire Société Raison sociale ou dénomination : Forme juridique : Nationalité : Siège social Rue : N : Boîte : Localité : Code postal : Pays : Numéro de téléphone : Numéro de fax : Numéro de TVA : Numéro d entreprise : et pour laquelle Monsieur/Madame (*) (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 : Adresse postale : P. 82

83 Par la présente, j accepte/je n accepte pas (biffer la mention inutile) l utilisation des moyens de communication électronique ( ) 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: A Le Le soumissionnaire ou le fondé de pouvoir : (nom) (fonction) P. 83

84 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. 84

85 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 : compréhension - actif - passif (biffer les mentions inutiles) commentaires Néerlandais : compréhension - actif - passif (biffer les mentions inutiles) commentaires Anglais : compréhension - actif - passif (biffer les mentions inutiles) commentaires Autres (seulement si pertinent) P. 85

86 Annexe C : Modèle de référence 1. Nom du projet. 2. Nom de 3. Secteur d'activité l entreprise. 4. Nom du 5. Coordonnées contact. 6. Portée 7. Buts poursuivis du développement ou du projet. 8. Date de début 9. Date de fin (par phase) Budget (EUR) A. Matériel B. Logiciels C. Services 11. Résumé et brève description du rôle et de la part des éventuels A. Nom de la ou des entreprises B. Partie du marché C. Compétence sous-traitants 12. Complexité << Nombre d utilisateurs, nombre de systèmes IT hors PC (nombre de mainframes, minis et serveurs) / >> 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. A. Matériel B. Logiciels A. Matériel B. Logiciels Instrument/méthode. Profil 1 Profil 2 Profil 3 Profil 4 Profil 5 C. Environnement de développement C. Environnement de développement Profil P. 86

87 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 de page langue Question P. 87

88 ANNEXE E : INVENTAIRE COMMUNITY CLOUD BUILDING BLOCKS 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. 1. Prix des outils livrés dans le cadre du projet (partie III.10) Inventaire Nombre Prix unitaire (hors TVA) Prix total (hors TVA) Tarif TVA Prix total (TVAC) Licences serveur pour PRODUCTION et DR Licences serveur pour DEVELOPPEMENT / TEST Licences utilisateurs named users PROD et DR Licences utilisateurs named users DEV / TEST Licences utilisateurs pour concurrent/floating users PROD et DR Licences utilisateurs pour concurrent/floating users DEV / TEST Licences connectors/adapters pour PRODUCTION et DR (*) Licences connectors/adapters pour DEV / TEST (*) Licences nœuds «cibles» 150 Abonnement bibliothèque de workflows standard (prix par an) Total hors TVA 4 ans (*) Les détails des prix des connecteurs proposés doivent être annexés au tableau de prix. Les connecteurs pour le phase d implémentation 2 doivent être prévus. Ils doivent être mentionnés dans le tableau (voir III.6.1) P. 88

89 2. Prix pour l achat des licences supplémentaires (partie III.10) Environnement Description Prix hors TVA DEV PRODUCTION et DR prix. Licence pour un serveur supplémentaire Licence pour un named user Licence pour un concurrent/floating user Licence pour un connector/adapter (prix à spécifier par connector/adapter) (*) Licence pour un nœud «cible» supplémentaire Licence pour un serveur supplémentaire Licence pour un named user Licence pour un concurrent/floating user Licence pour un connector/adapter (prix à spécifier par connector/adapter) (*) Licence pour un nœud «cible» supplémentaire Tarif TVA Prix TVAC (*) Les détails des prix des connecteurs proposés doivent être annexés au tableau de 3. Prix pour la maintenance annuelle des licences Environnement Description Prix hors TVA DEV PRODUCTION et DR Maintenance annuelle pour une licence serveur Maintenance annuelle pour un named user Maintenance annuelle pour un concurrent/floating user Maintenance annuelle pour les connectors/adapters (prix annuel à spécifier par connector) (*) Maintenance annuelle pour un nœud «cible» Maintenance annuelle pour une licence serveur Maintenance annuelle pour un named user Maintenance annuelle pour un concurrent/floating user Maintenance annuelle pour les connectors/adapters Tarif TVA Prix TVAC P. 89

90 prix. (prix annuel à spécifier par connector) (*) Maintenance annuelle pour un nœud «cible» (*) Les détails des prix des connecteurs proposés doivent être annexés au tableau de 4. Prix des services Environnement Description 1 Services de prise de contact et d analyse III Services d installation et configuration des outils III Services de mise en service et tests (y compris tests de haute disponibilité et disaster recovery) III Services de dossier de configuration et documentation - - III.9 5 Services pour la mise en œuvre des workflows III.8 6 Services pour l intégration à HP ucmdb (**) III Services pour l intégration à Service Management (**) III Services d exploitation opérationnelle (maximale 90 jours/homme par an), prix unitaire par jour III Assistance en dehors des heures ouvrables normales pendant l exploitation, prix unitaire par jour III Services de développement Java pour l intégration au portail utilisateur (240 jours/homme) III.7 (*) 1 jour/homme = 8 heures Nombre estimé jours/homme (*) (**) Pas d application, si un connecteur/adaptor est prévu Prix hors TVA par jour / homme Tarif TVA Prix TVAC par jour / homme P. 90

91 5. Prix des formations (partie III.12.1) Description Nombre Prix hors TVA (par session) Prix Total (hors TVA) Tarif TVA Prix Total (TVAC) 1 Formation (par session) pour les gestionnaires de systèmes de l outil IT Process Automation 2 2 Formation (par session) pour les gestionnaires des systèmes techniques 2 3 Formation (par session) pour les développeurs de l ICT Service Portal 2 4 Formation (par session) pour les collaborateurs du Service Desk et de l Operations Center 4 Le soumissionnaire précise le taux de TVA applicable. Fait à : Date : Nom : P. 91

92 ANNEXE F : Informations techniques complémentaires 1. Service Management Application Architecture Le schéma suivant représente les interactions entre outils, processus et groupes de travail dans le modèle général ITIL de l organisation ICT du SPF Finances. Gebruiker stelt incident vast vraagt wijziging ALARMS Netwerk Hardware Software Applicaties - real time - end-to-end integr Compuware agentless ITIL cyclus detectie diagnose verwerking DETECTIE DIAGNOSE OPLOSSINGEN klachten (incidents & problems) Tel, Mail Web HP-NNM HP-OVOw BAC/BPM Service desk agent Operator Operator AlarmPoint HP Openview servicedesk CMDB discovery CSSC NETWORK STORAGE Enz ucmdb firma firma firma firma firma management tools Batch (+backup) VTOM Operator WIJZIGINGEN (change & release) P. 92

93 2. Intégrations à la Service Management Application Architecture Gegevensflows en integraties met (u)cmdb, NNM, OVOW en SD/SM Integraties: - FSC Serverview - DELL OpenManage - HP SIM - VMWare ESX - EMC Controlcenter - EMC Networker - Centricstor - Nagios - CPMS8 (GCOS8) IAM integratie - persons - FODFIN organizations - access control portal Supplier integration: - Econocom (MyPC) - BULL (TMA) - BladeFrame PanOS - SCOM (AD, SQLserver) - Filenet - IBM Domino via SNMP of via agent Monitor info: - NNM(i) - BPM - OVOw - VTOM Inventaris informatie (complementair aan auto-discovery) Project management Starteam P. 93

94 3. ICT Service Portal Request Center 4. ICT Service Portal Etat des demande de service MSSQL P. 94

95 5. ICT Service Portal Formulaire Demande de nouvelle base de données P. 95