• Aucun résultat trouvé

III. DESCRIPTION DES EXIGENCES TECHNIQUES

III.2 E XIGENCES DU MARCHÉ

III.2.9 SLA

III.2.3.4 Licence site

À terme, le SPF Finances souhaite obtenir une licence de type « site » pour la solution ESB, c’est-à-dire une licence lui permettant d’utiliser la solution ESB sur autant de processeurs que nécessaires sans devoir acheter une « licence processeur » pour chaque processeur utilisé.

Le SPF Finances définit une licence de type « site » comme une « licence processeur » sur laquelle la limitation d’utilisation sur un seul core a été levée. Il s’agit donc d’une licence permettant d’utiliser le logiciel, dans toutes ses versions :

● sur de multiples et différentes plate-forme hardware physiques et virtuelles ainsi que sur différents OS, sur différents environnement (développement, acceptance, production , …) et sur différents sites physiques (North Galaxy, South Galaxy, …) pour de multiples instances de la solution ESB, et ce sans limite ni restriction d’aucune sorte

● par et pour toutes les applications, flux de données, utilisateurs et partenaires, tant internes qu’externes, présents et à venir, connus ou inconnus, du SPF Finances et ce sans limite ni restriction d’aucune sorte

Le soumissionnaire expliquera à partir de quelle quantité de « licences processeurs » détenues par le SPF Finances pour l’environnement de production (en ce incluses les licences offertes décrites au point précédent Volumétrie) il estime que l’ensemble de ces licences sont équivalentes à une licence de type « site ».

III.2.3.5 Tableau de prix

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

● Prix de l’offre de base de la solution ESB

Prix d’une « licence processeur » pour l’ensemble des composants de la solution ESB destinée respectivement à l’environnement de développement, d’acceptance et de production. Cette licence permet également d’installer et d’utiliser tous les outils de développement, de configuration, d’édition et de consultation liés aux différents composants de la solution ESB sur cinq stations de travail supplémentaires, sans distinction sur l’environnement

○ Fonction de volumétrie V() pour la solution ESB

○ Nombre de « licences processeurs » à posséder pour être en licence « site »

III.2.4 Maintenance logicielle et support

Durant toute la durée du marché, l’adjudicataire s’engage à fournir au SPF Finances toutes les mises à jour, y compris les mises à jour qualifiées de « majeures » par l’adjudicataire, de tous les logiciels composant la solution ESB. Ceci porte sur l’ensemble de l’offre logicielle. Cependant, le SPF Finance sera seul habilité à décider s’il réalise une mise à jour ou non, si cette mise à jour est partielle ou complète et si cette mise à jour se fait dans tous les environnements ou seulement certains.

En cas de changement dans le packaging (regroupement de logiciels formant un tout), le nouveau packaging ne sera pas imposé au SPF Finances si cela a pour effet de supprimer des fonctions déjà

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

L’adjudicataire fournira un support sur la solution ESB dans son ensemble ainsi que sur chacun des composants de la solution ESB. De plus, il sera le point de contact unique en ce qui concerne les aspects de support.

Le soumissionnaire montrera qu'il bénéficie du support nécessaire de la part des différents

fournisseurs des composants de la solution ESB afin d'avoir la possibilité de signaler les problèmes inattendus liés au logiciel et de les faire résoudre.

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

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

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

● En se basant sur des projets analogues présentés dans la section “Sélection qualitative”

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

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

III.2.5 Transfert de connaissances

Dans le cadre de la reprise en interne de la gestion de la solution ESB mise en place, le transfert de connaissances se fera à plusieurs niveaux. D’une part, via des formations et des manuels et, d’autre part, en collaborant étroitement avec le personnel interne du SPF Finances dans la mise en place de la solution ESB et de la réalisation du projet pilote.

A l’issue des formations et suite au travail collaboratif de mise en place de la solution ESB et de réalisation du projet pilote, le personnel du SPF Finances devra être capable de réaliser par lui-même un deuxième projet pilote de nature similaire au projet pilote présenté dans le présent cahier des charges. Si ce deuxième pilote n’est pas réalisable suite à des formations ou un transfert de

connaissances inadapté, l’adjudicataire fournira à ses frais les remédiations nécessaires au personnel du SPF Finances.

III.2.5.1 Formations et manuels

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

● Les formations auront lieu dans les locaux du SPF Finances, en collaboration avec ICT Academy2

● Chaque formation sera organisée en français et en néerlandais

● La documentation technique sera de préférence bilingue français / néerlandais

● Les formations se donneront par groupe de maximum dix personnes

● Le personnel interne sera capable de gérer, exploiter et faire évoluer la solution ESB de manière autonome à l’issue de ces formations (autant au niveau opérationnel que fonctionnel) Les manuels d’utilisation de chaque composant et outil de la solution ESB seront fournis. Ces

manuels devront décrire aussi bien l’installation, la configuration, la maintenance et l’exploitation de ces composants et outils.

Le soumissionnaire présentera les prix des formations de la façon suivante : pour chaque groupe-cible (opérateurs, programmeurs, architectes-analystes et chefs de projet), le soumissionnaire indiquera le prix d’un cycle complet de formation pour un groupe de maximum 10 personnes de ce groupe-cible.

Le prix porte donc bien sur un cycle de formation complet pour un groupe entier et n’est donc pas un prix par séance, par jour, par personne, …

Ce prix comprend la documentation des produits ainsi que tous les supports de cours nécessaires.

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

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

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

III.2.5.2 Transfert continu des connaissances

Dans un souci de transfert de connaissance, la mise en place de la solution ESB se fera en étroite collaboration avec le personnel interne du SPF Finances. Cela induit que toutes les connaissances nécessaires à cette mise en place, analyses et réflexions seront transmises au fil de l’eau,

centralisées par l’adjudicataire et accessibles par toute personne attachée au projet.

De même, tout développement faisant partie de la solution ESB (par exemple développement de connecteur, de règles de médiation, …) ou du projet pilote se fera en collaboration avec des développeurs internes.

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

2

III.2.6 Projet pilote

Le projet pilote se place dans le cadre des décisions d’octroi de bourses d’études et a pour but de proposer aux institutions compétentes un service leur permettant de vérifier si les conditions légales en matière de montant maximum des revenus autorisés sont remplies.

Pour l’instant, les institutions voulant délivrer une bourse d’étude envoient un fichier texte contenant les numéros de registre national des candidats à l’octroi d’une bourse d’étude via FTP au SPF Finances. Ce fichier est ensuite traité par un batch qui va rechercher les informations utiles dans une table dédiée de TAXI.

Il est possible d’obtenir le même type d’informations via le Webservice « Taxi aanslag -- IPCAL service ». Cependant, ce service n’est pour l’instant utilisé que par la BCSS.

Le projet pilote consistera à utiliser la solution ESB pour combiner et exposer au mieux les solutions existantes tout en y ajoutant les mécanismes d’authentification, d’autorisation et d’audit adéquats.

Bien que les institutions délivrant des bourses d’études soient les premières concernées, les services exposés devront également être accessibles par d’autres partenaires du SPF Finances.

L’analyse, le design et la réalisation de ce pilote se feront en collaboration étroite avec les équipes internes du SPF Finances.

Ce projet pilote n’est pas un proof-of-concept mais bien un projet à part entière qui a pour vocation d’être mis en production. Il devra respecter les standards en place et devra utiliser pleinement les fonctionnalités de la solution ESB tels que, par exemple, entrées dans le catalogue et l’annuaire de service, définition et suivi de SLA, monitoring technique et business, gestion de la sécurité, ...

III.2.7 Renforcement de la démarche SOA

L'adjudicataire évaluera le niveau de maturité SOA du SPF Finances dès le kick-off du projet. Pour cela, il utilisera le modèle de maturité ouvert et indépendant publié par Inaganti et Sriram sur bptrends.com 3

Après la mise en place de la solution ESB et la réalisation du projet pilote, une nouvelle évaluation sera effectuée pour déterminer l'évolution du niveau de maturité. L'adjudicataire rédigera ensuite des recommandations sur les actions à entreprendre pour continuer à améliorer le niveau de maturité SOA.

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

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

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

Q53. Les services au sens SOA du terme sont destinés à être réutilisés. Cependant, les attentes et le comportement des différents consommateurs peuvent varier fortement.

Dans ce contexte, la gestion de SLA différents et potentiellement contradictoires devient problématique. Dans ce contexte, il est demandé au soumissionnaire de décrire sa vision et les bonnes pratiques à mettre en œuvre en ce qui concerne la gestion des SLA des services dans une architecture de type SOA

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

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

III.2.8 Organisation du projet

III.2.8.1 Gestion du projet et méthodologie

III.2.8.1.1 PMFin

L'adjudicataire aura recours à PMFin, notre méthodologie et procédure de gestion des projets.

PMFin est la méthodologie de projet unique et standard du SPF Finances. Elle repose sur la norme internationale Prince 2. La méthodologie est appuyée par l’outil de projet ProjectMaster.

III.2.8.1.2 PID

Le soumissionnaire est invité à soumettre un ‘Project initiation document’ (PID) résumant les principales tâches qui doivent permettre de réaliser le projet.

Ce document est pour nous un produit, une unité de travail au sein de notre propre PID.

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

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

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

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

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

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

• Dépendances avec d'autres projets

• Plan de qualité

• Plan de communication (avec aspects ‘change management’)

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

Après la réunion de coup d'envoi (‘kick-off’), le PID est finalisé, complété, enfin soumis à la validation du comité de pilotage, sponsor compris.

Le soumissionnaire doit décrire sa structure et ses capacités en termes d'organisation des services professionnels : services offerts, portée géographique, niveaux et qualités du personnel.

Le plan doit spécifier les tâches, leur durée et le nombre de personnes concernées, pour chaque (partie de) phase. Le plan doit aussi détailler la collaboration attendue de la part du personnel du SPF Finances.

Après l'attribution du projet, le soumissionnaire élaborera un PID et un plan de projet complets et détaillés, qu'il présentera à la structure de gestion du projet du SPF Finances.

L'approbation formelle du PID (planning de projet compris) ci-dessus par le comité de pilotage du projet est indispensable avant d'entamer la phase suivante.

Il appartient au soumissionnaire de veiller à la tenue à jour du PID pendant toute la durée du projet.

Toute modification du plan de projet doit être approuvée formellement par le comité de pilotage du projet.

Le PID du soumissionnaire constituera pour notre propre PID une source d'information à propos des produits et des unités de travail dont le soumissionnaire aura la charge.

III.2.8.1.3 Structures de gouvernance

Tous les projets sont pilotés et gérés au sein des structures de gestion de projet du SPF Finances.

Celles-ci sont représentées dans le schéma suivant :

III.2.8.1.3.1 Chef de projet

Chaque projet du SPF Finances est dirigé par un chef de projet interne (business). Celui-ci est nommé par le Sponsor, en concertation avec le comité de pilotage.

Le soumissionnaire désignera son propre coordinateur de projet externe (chef de projet externe).

Celui-ci et le chef de projet assument l'entière responsabilité de la bonne exécution du projet.

III.2.8.1.3.2 Comité de pilotage

Le comité de pilotage détient de larges compétences : il surveille le scope et les objectifs du projet, approuve le PID et le plan de projet détaillé ainsi que toutes leurs modifications, surveille l'avancement du projet, confirme l'acceptation des livrables (produits, livraisons partielles), évalue la qualité des produits partiels et finaux, et se prononce dans tous les litiges et/ou problèmes soulevés par le chef de projet. Il s'occupe de tous les aspects contractuels, administratifs et techniques de l'exécution du marché (garantie, respect des SLA, qualité de l'exécution, etc).

À cette fin, le chef de projet et le coordinateur de projet externe feront régulièrement rapport au comité de pilotage : situation, progression, risques et problèmes…

Le comité de pilotage regroupe le sponsor, un profil senior du soumissionnaire, le chef de projet et le coordinateur de projet externe, ainsi qu'un représentant des utilisateurs.

D'autres personnes peuvent être invitées, notamment le PMO opérationnel, le coordinateur de projet ICT, le responsable du ‘work package’ ou des personnes travaillant sur des aspects spécifiques du projet.

III.2.8.1.3.3 Équipe de projet

L'équipe de projet se compose de différents profils (internes et externes), dont chacun rapporte au responsable de son unité de travail (‘work package’) ou au chef de projet.

Idéalement, les rôles suivants font partie de l'équipe : coordinateur de projet ICT (qui assure la liaison avec le service d'encadrement ICT), change coordinator (chargé de la gestion des changements) (P&O et Communication), coordinateur externe (contractant).

III.2.8.1.3.4 PMO opérationnel

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

III.2.8.1.3.5 Réunion de coup d'envoi (‘kick-off’)

Dans un délai maximum de << 2 semaines, 3 semaines, 1 mois, 6 semaines… >> suivant l'attribution du marché, l'adjudicataire et le SPF Finances doivent tenir une première réunion du comité de pilotage, appelée réunion de coup d'envoi (ou de kick-off). La réunion officialise le début du projet.

Au cours de cette première rencontre, si cela s’impose au vu du cahier des charges, on examine le PID, on présente la composition des équipes et leurs compétences professionnelles, l'agenda des réunions de rapportage et des réunions du comité de pilotage, les modalités de gestion de projet, le planning de la réalisation du marché, on explique les principes du SLA, etc.

Un document rédigé en deux exemplaires par l'adjudicataire et validé par le pouvoir adjudicateur entérine officiellement le début du projet dès que la réunion de coup d'envoi a eu lieu.

III.2.8.1.3.6 Réunion du comité de pilotage

Dès la réunion de coup d'envoi, le premier comité de pilotage fixe la date de ses réunions suivantes, en principe << une fois par mois / tous les 2 mois / tous les 3 mois / … >>.

Le sponsor ou le chef de projet peuvent toujours convoquer un comité de pilotage en dehors des dates fixées.

III.2.8.1.3.7 Autres réunions

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

III.2.8.1.4 Qualité

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

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

III.2.8.1.5 Rapports

À l'occasion des réunions visées ci-dessus, ainsi qu'à des moments convenus, l'adjudicataire établira les rapports nécessaires concernant les moyens mobilisés (personnel, méthodes, matériel, logiciels), l'avancement du projet, sa situation…

Périodiquement, à savoir << une fois par mois / tous les 2 mois / tous les 3 mois / … >>, suivant un calendrier mis au point de commun accord lors de la réunion de coup d'envoi, l'adjudicataire rédigera un rapport complet d'avancement du projet (situation de chaque phase de la réalisation) à l'intention du comité de pilotage. Le rapport évoquera les problèmes éventuels et les solutions proposées.

L'adjudicataire rédigera aussi des rapports de coordination et de travail sur l'avancement du projet (situation de chaque phase de la réalisation), les problèmes éventuels et les solutions proposées. Les réunions auront lieu ponctuellement, à la demande des parties. Le rythme de ces rencontres

dépendra de la progression des phases du projet. Le lieu des réunions sera précisé par le SPF Finances avec les dates.

Le soumissionnaire et le coordinateur de projet désigné par lui mettront à la disposition du chef de projet toutes les informations nécessaires pour surveiller le déroulement réel des activités du soumissionnaire et la situation par rapport au planning.

Ce rapportage destiné au chef de projet suivra une fréquence hebdomadaire, sur la base d'une situation représentée sur le schéma Gantt du projet, complétée d'une brève description écrite, avec les points principaux, les problèmes éventuels et leur solution.

Tous les détails des modalités de rapportage doivent être communiqués au début du projet.

Tous les aspects relatifs au fond (planning, risques, qualité, réception, ressources) seront d'abord évoqués au sein de l'équipe de projet.

Si le chef de projet le juge nécessaire, les problèmes seront soumis à l'examen et à la délibération du comité de pilotage.

Chaque mois, le chef de projet remettra au comité de pilotage un rapport mensuel sur l'avancement du projet. Le cas échéant, le chef de projet peut inviter le coordinateur de projet externe à la réunion du comité de pilotage afin de l'éclairer plus en détail sur certains points.

III.2.8.1.6 Gestion des changements (voir aussi partie II, Gestion des changements (request for change))

Tout changement (scope, résultats/produits visés, planning, budgets) au projet doit faire l'objet d'une demande de changement spécifiant le motif et l'impact du changement.

Le comité de pilotage évalue le bien-fondé et l'opportunité du changement envisagé. Il peut se faire assister du PMO (opérationnel) et/ou d'un expert (externe).

L'accord formel du fonctionnaire dirigeant conditionne l'exécution des changements envisagés. Le cas échéant, l’adjudicataire devra actualiser PID.

Documents relatifs