Download - Cahier spécial des charges - SPF Finances · 2016-07-12 · Cahier spécial des charges S&L/DA/2016/060 1/223 Cahier spécial des charges : Appel d'offres ouvert relatif à l'entretien

Cahier spécial des charges S&L/DA/2016/060 1/223

Cahier spécial des charges :

Appel d'offres ouvert relatif à l'entretien au développement et au test des applications pour le compte du SPF Finances

Publication au niveau européen

Cahier spécial des charges n° S&L/DA/2016/060

Ouverture des offres : 6 SEPTEMBRE 2016 à 14h30


Table des matières A. DEROGATIONS GENERALES .......................................................................................10 B. DISPOSITIONS GÉNÉRALES ........................................................................................11

B1. OBJET ET NATURE DU MARCHE. ............................................................................................................ 11 B2. DUREE DU CONTRAT. ............................................................................................................................... 12 B3. POUVOIR ADJUDICATEUR – INFORMATIONS COMPLEMENTAIRES. .................................................. 13 B4. DOCUMENTS REGISSANT LE MARCHE .................................................................................................. 13

B4.1. Législation .......................................................................................................................... 13 B4.2. Documents du marché ....................................................................................................... 13

B5. INCOMPATIBILITES - CONFLITS D’INTERETS. ....................................................................................... 14 B5.1. INCOMPATIBILITES ................................................................................................................................ 14 B5.2. CONFLITS D'INTERETS .......................................................................................................................... 14 B6. FORUM DE QUESTIONS-REPONSES. ..................................................................................................... 14

C. ATTRIBUTION ................................................................................................................16 C1. DROIT ET MODALITES D’INTRODUCTION ET OUVERTURE DES OFFRES ......................................... 16

C1.1. Droit et mode d’introduction des offres .............................................................................. 16 C1.1.1. Offres introduites par des moyens électroniques ........................................................... 16 C1.1.2. Modification ou retrait d’une offre déjà introduite ........................................................... 17 C1.2. Ouverture des offres .......................................................................................................... 17 C2.3. Durée de validité de l’offre. ................................................................................................ 21 C2.4. Documents et attestations à joindre à l’offre ..................................................................... 21

C4. PRIX. ........................................................................................................................................................... 21 C5. DROIT D’ACCES – SELECTION QUALITATIVE – REGULARITE DES OFFRES – CRITERES

D’ATTRIBUTION ........................................................................................................................................ 21 C5.1. Droit d’accès et sélection qualitative ............................................................................ 21 C5.1.1. Droit d’accès ................................................................................................................... 22 C5.1.2. Sélection de qualité ........................................................................................................ 25 Critères de sélection relatifs aux moyens financiers du soumissionnaire (article 67, 3° de l’arrêté royal du 15 juillet 2011) ............................................................................................................... 25 Critère de sélection se rapportant à la compétence technique du soumissionnaire (article 72, 7° de l’arrêté royal du 15 juillet 2011) .............................................................................................. 26 C5.2. Régularité des offres .................................................................................................... 29 C5.3. Critères qui seront utilisés lors de l’évaluation des offres ................................................. 29 C5.3.1. Liste des critères d’attribution ......................................................................................... 29

d. EXÉCUTION ....................................................................................................................38 D1. FONCTIONNAIRE DIRIGEANT. ................................................................................................................. 38 D2. REVISION DE PRIX. ................................................................................................................................... 38 D3. RESPONSABILITE DU PRESTATAIRE DE SERVICES............................................................................. 39 D4. 4 RECEPTION DES SERVICES PRESTES ............................................................................................... 39

D4.1. La livraison et l’installation ................................................................................................. 39 D4.2. Spécifications techniques .................................................................................................. 39 D4.3. Suivi de la bonne exécution des livraisons et des services .............................................. 39 D4.4. Contrôle et encadrement du marché ................................................................................. 40

D4.5. RECEPTION PROVISOIRE PARTIELLE ................................................................................................. 41 D4.7. Réception définitive ........................................................................................................... 42 D4.8. Frais de réception .............................................................................................................. 42

D5. CAUTIONNEMENT ..................................................................................................................................... 42 D5.1. Constitution du cautionnement .......................................................................................... 42 D5.2. Libération du cautionnement ............................................................................................. 44 D6. Conditions de l’exécution ...................................................................................................... 44 D6.1. Clause d’exécution ............................................................................................................ 44 D6.2. Clause d’évolution technologique ...................................................................................... 45 D6.3. Lieu d’exécution du marché et particularités ..................................................................... 45 D6.4. Personnel de l’adjudicateur ............................................................................................... 45 D6.5. Sous-traitants..................................................................................................................... 47

D8. FACTURATION ET PAIEMENT. ................................................................................................................. 52 D9. LITIGES. ...................................................................................................................................................... 52 D10. AMENDES ET PENALITES. ..................................................................................................................... 53

D10.1. Pénalités .......................................................................................................................... 53 D10.2. Amendes .......................................................................................................................... 53


D10.3. Imputation des amendes et pénalités .............................................................................. 54 E. PRESCRIPTIONS TECHNIQUES ....................................................................................55

E.1. INTRODUCTION ........................................................................................................................................ 55 E.2. CONTEXTE ET PRINCIPES GENERAUX DU MARCHE ........................................................................... 57

E.2.1. Contexte général .............................................................................................................. 57 E.2.1.1. Encadrement du marché ............................................................................................... 57

E.2.1.1.1. COLLABORATION ............................................................................................................................ 58 E.2.1.1.2. CONDITIONS DE L’EXECUTION...................................................................................................... 58 E.2.1.1.3. DESCRIPTION DES APPLICATIONS ............................................................................................... 59 E.2.1.1.4. SEPARATION DES ASPECTS « ENTRETIEN », « DEVELOPPEMENT » ET « TESTS » ............... 59 E.2.1.1.6. AMELIORATION DE LA QUALITE DES APPLICATIONS (DISPONIBILITE, PERFORMANCE,

OPTIMISATION, DOCUMENTATION, QUALITE DU CODE, CONSOMMATION DE RESSOURCES,…). 60 E.2.1.1.7. INTEGRATION ENTRE LES APPLICATIONS FONCTIONNELLEMENT LIEES ENTRE ELLES ..... 61 E.2.1.1.9. MAITRISE DES COUTS .................................................................................................................... 61 E.2.1.1.10. ÉVALUATION DES PRESTATIONS EXECUTEES ......................................................................... 61

E.2.1.2. Cycle de maintenance ................................................................................................... 61 E.2.1.3.1. IMPLICATION DU PERSONNEL INTERNE ET RENFORCEMENT DE LA MAITRISE .................... 64 E.2.1.3.2. CO-SOURCING ................................................................................................................................. 64 E.2.1.3.3. DOCUMENTATION ........................................................................................................................... 65 E.2.1.3.4. FORMATION ..................................................................................................................................... 66

E.2.2. Contexte technique ........................................................................................................... 66 E.2.3. Contexte organisationnel .................................................................................................. 67 E.2.1.2. Project Initiation Document (PID) .................................................................................. 68 E.2.3.2. Structures de gouvernance ............................................................................................ 69 E 2.3.3. Chef de projet ................................................................................................................ 69 E 2.3.4. Comité de pilotage ......................................................................................................... 70 E 2.3.5. Équipe de projet ............................................................................................................. 70 E 2.3.6. Réunion de coup d’envoi (kick-off) ................................................................................ 70 E 2.3.7. Réunion du groupe de pilotage...................................................................................... 71 E 2.3.8. Autres réunions .............................................................................................................. 71 E 2.3.9. Qualité ............................................................................................................................ 71 E 2.3.10. Rapports ...................................................................................................................... 71 E 2.3.11. Gestion des modifications ............................................................................................ 72 E.2.4. SLA ................................................................................................................................... 73 E.2.4.1. Introduction .................................................................................................................. 73 E.2.4.2. Principe d’élaboration des SLA dans le cadre de ce marché et déliverables correspondants ......................................................................................................................... 73 E.2.4.3. Encadrement SLA ........................................................................................................ 76 E.2.4.4.Service Levels et engagements de résultats correspondants dans le cadre de ce marché ........................................................................................................................................ 79 E.2.4.5. Service Levels relatifs à la gestion de projet : délai, exhaustivité et planification79 E.2.4.5.2.1.Composition minimale offre lots de 1 à 6 ................................................................. 80 E.2.4.5.2.2. Description ............................................................................................................... 80 E.2.4.6. Niveaux de service phase de développement : conformité à la méthodologie FUP, aux standards ICT et qualité du code ..................................................................................... 81 E.2.4.7. Mise en production des Servicelevels ....................................................................... 83 E.2.4.8. Service levels exigences non fonctionnelles ........................................................... 84 E.2.4.8.1.1. Périodes d’ouverture du service (service window) et périodes de maintenance dans le cadre de ces SLA .................................................................................................................... 84 E.2.4.8.1.2. Service Windows par catégorie d’applications ........................................................ 84 E.2.4.9. Service Levels en matière de traitement d’incidents, d’interventions correctrices et réactives ; .............................................................................................................................. 86 E.2.4.10. Service Levels concernant les services du personnel mis à disposition par l’adjudicataire. ........................................................................................................................... 90 E.2.4.11. Service Levels relatifs au lot 6 Testing. .................................................................. 91 E.2.4.11.2.1. PI-Actualized-testing-effort- burn- down-rate (management KPI) ......................... 91 E.2.4.11.3.1. PI-Test execution coverage ................................................................................... 91 E.2.4.11.3.2. PI-Test build coverage ........................................................................................... 92 E.2.4.11.3.3. PI-Defect detection ratio ........................................................................................ 92 E.2.4.11.4.1. PI-Test-efficiency ................................................................................................... 92 E.2.4.11.4.2. PI-Test-case-automation ....................................................................................... 93 E.2.4.12. Périodes d’application des différents SLA ............................................................. 93


E.2.4.13. Amendes ..................................................................................................................... 93 E.2.4.14. SLA monitoring, rapportage et analyse, Concertation du Service Management 94 E.2.4.14.1.1. Base de contrôle au sein du SPF Finances .......................................................... 94 E.2.4.14.1.2. Assistance dans le cadre du monitoring par l’adjudicataire .................................. 94 E.2.4.14.2.1. Service Level Reporting (SLR) général – exemple de rapports ............................ 95 E.2.4.14.2.2. PI-SLR ................................................................................................................... 96 E.2.4.14.2.3. Concertation de Service Management .................................................................. 96 E.2.4.15. Remarque de clôture ................................................................................................. 97

E.3. DESCRIPTION DU MARCHE .................................................................................................................... 98 E.3.1. Composante « Développement et Support » (Lots 1 à 5) ................................................ 98

E.3.COMPOSANTE « TESTS (LOT 6). ........................................................................................................... 104 LE LOT 6 DU PRESENT MARCHE EST RELATIF A DES ACTIVITES DE TESTS SPECIFIQUES AUX

APPLICATIONS NON FISCALES DU SPF FINANCES. .......................................................................... 104 E.3.2.1. Marchés ....................................................................................................................... 104 Exécution des tests ................................................................................................................... 104 E.3.2.2. Contexte. ...................................................................................................................... 104

E.3.2.2.1. ENVIRONNEMENT ORGANISATIONNEL ...................................................................................... 104 E.3.2.2.2. REFERENCE .................................................................................................................................. 105 LE SOUMISSIONNAIRE POURRA TROUVER UNE DESCRIPTION DE LA METHODOLOGIE SOUS LA

REFERENCE : .......................................................................................................................................... 105 E.3.2.2.3. METHODES DE TRAVAIL .............................................................................................................. 105 E.3.2.2.4. ARSENAL DE TESTS TOOLS ........................................................................................................ 106

E.3.2.3. Profils. .......................................................................................................................... 108 Compétences communes ....................................................................................................... 108

E.3.2.3.1. TESTEUR ........................................................................................................................................ 108 F. ANNEXES ...................................................................................................................... 114 Annexe 1 : FORMULAIRE D’OFFRE ................................................................................ 115 Annexe 2 : Modèle de référence ...................................................................................... 121 Annexe 3.a.: Curriculum Vitae – Individuel .................................................................... 122 Annexe 3.b.: Curriculum Vitae – Synthèse ..................................................................... 124 ANNEXE 4 : SLA Template............................................................................................... 145 ANNEXE 5 : Tableau KPI .................................................................................................. 152 ANNEXE 6 : Description des applications ...................................................................... 153

LOT 1 – ENTRETIEN (SPECIFIQUE) DE ZACHEUS, E-NOTARIAT, FINPROF, E-DEDUCTION (SAFS CV), AVIS DE SAISIE (FCA). ............................................................................................................................ 154 I. Zacheus ............................................................................................................................. 154 a. Description fonctionnelle ................................................................................................... 154

Objectif .............................................................................................................................. 155 b. Cycle de vie récurrent ........................................................................................................ 156 c. Indications concernant l'entretien évolutif futur ................................................................. 156 II. e-Notariat ........................................................................................................................... 157 a. Description fonctionnelle ................................................................................................... 157 b. Cycle de vie récurrent ........................................................................................................ 159 c. Indications concernant l'entretien évolutif futur ................................................................. 159 III. Finprof ............................................................................................................................ 160 a. Description fonctionnelle ................................................................................................... 160 b. Cycle de vie récurrent ........................................................................................................ 162 c. Indications concernant l'entretien évolutif futur ................................................................. 162 IV. e-Deduction (SAFS CV) ................................................................................................. 163 a. Description fonctionnelle ................................................................................................... 163 b. Cycle de vie récurrent ........................................................................................................ 164 c. Indications concernant l'entretien évolutif futur ................................................................. 165 V. Avis de saisies (FCA) ........................................................................................................ 166 a. Description fonctionnelle ................................................................................................... 166

SCHEMA :........................................................................................................................................................ 166 b. Cycle de vie récurrent ........................................................................................................ 166 c. Indications concernant l'entretien évolutif futur ................................................................. 166

LOT 2 - ENTRETIEN (SPECIFIQUE) DE STIPAD,... ....................................................................................... 167 I. Stipad ................................................................................................................................. 167 a. Description fonctionnelle ................................................................................................... 167 b. Cycle de vie récurrent ........................................................................................................ 168


c. Indications concernant l'entretien évolutif futur ................................................................. 170 LOT 3 – ENTRETIEN (SPECIFIQUE) DE FSP, PANDORA, CAUTIONNEMENTS SOLIDAIRES (SP10A),

FAILLITES (SP10B), GROOTBOEK/GRAND LIVRE, CDC DMAT. .......................................................... 171 I. Fonds spécial de Protection (FSP) .................................................................................... 171 d. Description fonctionnelle ................................................................................................... 171 e. Cycle de vie ....................................................................................................................... 172 f. Indications concernant l'entretien évolutif futur ................................................................. 173 II. Pandora ............................................................................................................................. 175 a. Description fonctionnelle ................................................................................................... 175 b. Cycle de vie ....................................................................................................................... 176 c. Indications concernant l'entretien évolutif futur ................................................................. 177 III. Cautionnements solidaires - Cautions (SP10A) ........................................................... 183 a. Description fonctionnelle ................................................................................................... 183 b. Cycle de vie récurrent ........................................................................................................ 183 c. Indications concernant l'entretien évolutif futur ................................................................. 183 IV. Faillites (SP10B) ............................................................................................................ 185 a. Description fonctionnelle ................................................................................................... 185 b. Cycle de vie ....................................................................................................................... 185 c. Indications concernant l'entretien évolutif futur ................................................................. 185 V. Grootboek – Grand Livre ................................................................................................... 187 a. Description fonctionnelle ................................................................................................... 187 b. Cycle de vie ....................................................................................................................... 187 c. Indications concernant l'entretien évolutif futur ................................................................. 187 VI. CDC Dmat ...................................................................................................................... 188 a. Description fonctionnelle ................................................................................................... 188 b. Cycle de vie ....................................................................................................................... 188 c. Indications concernant l'entretien évolutif futur ................................................................. 188

LOT 4 - ENTRETIEN (GENERAL) ................................................................................................................... 189 I. COMFOR ........................................................................................................................... 190 a. Description fonctionnelle ................................................................................................... 190 b. Cycle de vie ....................................................................................................................... 190 c. Indications concernant l'entretien évolutif futur ................................................................. 190 II. eSUCC ............................................................................................................................... 191 a. Description fonctionnelle ................................................................................................... 191 b. Cycle de vie ....................................................................................................................... 191 c. Indications concernant l'entretien évolutif futur ................................................................. 191 III. eSUCC – STAT.............................................................................................................. 193 a. Description fonctionnelle ................................................................................................... 193 b. Cycle de vie ....................................................................................................................... 193 c. Indications concernant l'entretien évolutif futur ................................................................. 193 IV. eSUCC CONSULT ........................................................................................................ 194 b. Cycle de vie ....................................................................................................................... 194 c. Indications concernant l'entretien évolutif futur ................................................................. 194 V. RE (remboursements enregistrement) .............................................................................. 196 a. Description fonctionnelle ................................................................................................... 196 b. Cycle de vie ....................................................................................................................... 196 c. Indications concernant l'entretien évolutif futur ................................................................. 196 VI. RE CONSULT ................................................................................................................ 197 a. Description fonctionnelle ................................................................................................... 197 b. Cycle de vie ....................................................................................................................... 197 c. Indications concernant l'entretien évolutif futur ................................................................. 197 VII. RESPO .......................................................................................................................... 198 a. Description fonctionnelle ................................................................................................... 198 b. Cycle de vie ....................................................................................................................... 198 c. Indications concernant l'entretien évolutif futur ................................................................. 198 VIII. Paperloco ....................................................................................................................... 200 a. Description fonctionnelle ................................................................................................... 200 b. Cycle de vie ....................................................................................................................... 200 c. Indications concernant l'entretien évolutif futur ................................................................. 200 IX. Hypothèques maritimes et fluviales ............................................................................... 201 d. Description fonctionnelle ................................................................................................... 201


e. Cycle de vie ....................................................................................................................... 201 f. Indications concernant l'entretien évolutif futur ................................................................. 201 X. MyRent .............................................................................................................................. 202 a. Description fonctionnelle ................................................................................................... 202 b. Cycle de vie ....................................................................................................................... 202 c. Indications concernant l'entretien évolutif futur ................................................................. 202 XI. Extraction Cadnet-Loco (ECL) ....................................................................................... 203 a. Description fonctionnelle ................................................................................................... 203 b. Cycle de vie ....................................................................................................................... 203 c. Indications concernant l'entretien évolutif futur ................................................................. 203 XII. Locostat ......................................................................................................................... 204 a. Description fonctionnelle ................................................................................................... 204 b. Cycle de vie ....................................................................................................................... 204 c. Indications concernant l'entretien évolutif futur ................................................................. 204 XIII. Regeval .......................................................................................................................... 205 a. Description fonctionnelle ................................................................................................... 205 b. Cycle de vie ....................................................................................................................... 205 c. Indications concernant l'entretien évolutif futur ................................................................. 205 XIV. URBAIN ......................................................................................................................... 206 a. Description fonctionnelle ................................................................................................... 206 b. Cycle de vie ....................................................................................................................... 206 c. Indications concernant l'entretien évolutif futur ................................................................. 206 XV. REGONDES 2 ............................................................................................................... 207 a. Description fonctionnelle ................................................................................................... 207 b. Cycle de vie ....................................................................................................................... 207 c. Indications concernant l'entretien évolutif futur ................................................................. 207 XVI. DER ............................................................................................................................... 208 a. Description fonctionnelle ................................................................................................... 208 b. Cycle de vie ....................................................................................................................... 208 c. Indications concernant l'entretien évolutif futur ................................................................. 208 XVII. Service Web d’optimisation des échanges d’informations avec les partenaires externes 209 a. Description fonctionnelle ................................................................................................... 209 b. Cycle de vie ....................................................................................................................... 209 c. Indications concernant l'entretien évolutif futur ................................................................. 209 XVIII. Adhésion à la 4e voie.................................................................................................. 210 a. Description fonctionnelle ................................................................................................... 210 b. Cycle de vie ....................................................................................................................... 210 c. Indications concernant l'entretien évolutif futur ................................................................. 210 XIX. WS Consultimmo ........................................................................................................... 211 a. Description fonctionnelle ................................................................................................... 211 1. on properties ...................................................................................................................... 211 2. on transactions .................................................................................................................. 211 3. Parcel Navigator ................................................................................................................ 211 b. Cycle de vie ....................................................................................................................... 211 c. Indications concernant l'entretien évolutif futur ................................................................. 211 XX. Output services AGDP ................................................................................................... 212 a. Description fonctionnelle ................................................................................................... 212 b. Cycle de vie ....................................................................................................................... 212 c. Indications concernant l'entretien évolutif futur ................................................................. 212 XXI. Hypo ............................................................................................................................... 213 a. Description fonctionnelle ................................................................................................... 213 b. Cycle de vie ....................................................................................................................... 213 c. Indications concernant l'entretien évolutif futur ................................................................. 213 XXII. Hypocomptabi ............................................................................................................ 214 a. Description fonctionnelle ................................................................................................... 214 b. Cycle de vie ....................................................................................................................... 214 c. Indications concernant l'entretien évolutif futur ................................................................. 214 XXIII. Hyporeg ...................................................................................................................... 215 a. Description fonctionnelle ................................................................................................... 215


b. Cycle de vie ....................................................................................................................... 215 c. Indications concernant l'entretien évolutif futur ................................................................. 215 XXIV. Stiron Fraude.............................................................................................................. 216 a. Description fonctionnelle ................................................................................................... 216 b. Cycle de vie ....................................................................................................................... 216 c. Indications concernant l'entretien évolutif futur ................................................................. 217 XXV. MyMinfin ..................................................................................................................... 218 a. Description fonctionnelle ................................................................................................... 218 b. Cycle de vie ....................................................................................................................... 218 c. Indications concernant l'entretien évolutif futur ................................................................. 218 XXVI. Zoomit ........................................................................................................................ 219 a. Description fonctionnelle ................................................................................................... 219 b. Cycle de vie ....................................................................................................................... 219 c. Indications concernant l'entretien évolutif futur ................................................................. 219 XXVII. Doctran ....................................................................................................................... 220 a. Description fonctionnelle ................................................................................................... 220 d. Cycle de vie ....................................................................................................................... 221 e. Indications concernant l'entretien évolutif futur ................................................................. 221 XXVIII. Mandats FedIAM .................................................................................................... 222 a. Description fonctionnelle ................................................................................................... 222 b. Cycle de vie ....................................................................................................................... 223 c. Indications concernant l'entretien évolutif futur ................................................................. 223


Abréviations, acronymes et termes utilisés ABB Architecture Building Blocks: description des standards et technologies ICT

utilisés par le SPF Finances Cobifin Cobit Finances: l’IT governance framework du SPF Finances, basé sur Cobit Cobit Control OBjectives for Information and related Technology: un framework créé

par ISACA pour la gestion de l’informatique (IT) et l’IT governance

FUP Finance Unified Process: le software development process framework du SPF

Finances, basé sur Rational Unified Process (RUP). OIT Organisation internationale du Travail ITIL Information Technology Infrastructure Library: cadre de référence pour l’organisation des processus de gestion d’une organisation ICT KPI Key Performance Indicator: variables destinées à analyser les performances

d’une entreprise

QUAC Quality Assurance Comité: valide tous les délivrables quant à leur conformité aux normes et règles d’acceptation PMFin Project Management Finances: la méthodologie de project management du

SPF Finances, basée sur Prince2

Prince2 PRojects IN Cont Environments, version 2: une méthodologie de project

management reconnue au niveau international et très utilisée

PTC Performance Test Center: département d’ICT QA&ITPS, pour les tests de

charge et de performance Méthodologie PTC la méthodologie de test utilisée par le SPF Finances pour les tests de

charge et de performance, basée sur STBoX et FUP/RUP-D5 QA&ITPS Quality Assurance and IT Process Support: département du service ICT du

SPF Finances

RUP Rational Unified Process: un software development process framework itératif SLA Service Level Agreement: partie d’un contrat de service standard qui définit

formellement un service

SWOT Strengths, Weakness, Opportunities and Threats: modèle d’analyse structuré

destiné à définir la stratégie optimale

STBox Software Testing method Based on eXperience: approche pragmatique de

testing basée sur un workflow TCC Test Competence Center: département d’ICT QA&ITPS, pour les tests

fonctionnels


TMap Test Management approach: méthodologie de test de software qui indique ce qui est à tester et comment le gérer

TMv4 Test Management approach – version 4: la méthodologie de test utilisée par le

SPF Finances pour les tests fonctionnels, basée sur TMap et FUP/RUP-D5


SERVICE PUBLIC FÉDÉRAL Finances

Service d'encadrement Logistique Division Achats

North Galaxy - Tour B4 - boîte 961 Boulevard du Roi Albert II, 33

1030 BRUXELLES

CAHIER SPÉCIAL DES CHARGES n° S&L/AO/2016/060 APPEL D'OFFRES RELATIF À L'ENTRETIEN, AU DÉVELOPPEMENT ET AU

TEST DES APPLICATIONS POUR LE COMPTE DU SPF FINANCES

A. DEROGATIONS GENERALES

IMPORTANT

En application de l'article 9, paragraphe 4 de l'AR du 14 janvier 2013 établissant les règles générales d’exécution des marchés publics et des concessions de travaux publics, l'attention des soumissionnaires est attirée sur le fait que dans ce cahier, il est dérogé à l'article : - 154 de l’arrêté royal du 14 janvier 2013 relatifs aux amendes.


B. DISPOSITIONS GÉNÉRALES

B1. Objet et nature du marché. Le SPF Finances souhaite renforcer ses équipes de maintenance et de développement avec des équipes et profils externes (task manager, technical architect, business analyst, junior JEE-technology developer et senior JEE-technology developer). Le SPF Finances souhaite également renforcer son équipe de testing avec une équipe externe combinant différents profils (testeur, spécialiste en test tools, spécialiste en méthodologies de test et quality assurance coordinator). Avec les équipes internes, les équipes et profils concernés seront responsables :

de la maintenance des applications de l’ensemble des Administrations générales et Services d’encadrement

du développement de nouvelles applications

du testing de ces applications Outre la maintenance, le développement et/ou le testing des applications concernées, ce marché comprend également :

le support du business dans l’établissement et l’élaboration de spécifications fonctionnelles et techniques

l’adaptation et/ou la création de la documentation nécessaire pour chaque projet

la surveillance de tous les aspects liés à la qualité

le support opérationnel de la production et du service desk

la fourniture du matériel de formation nécessaire pour les utilisateurs (si d’application)

l’accompagnement de l’équipe concernée du SPF Finances dans l’acquisition et le transfert de compétences, en vue de la suite de la maintenance de cette application au terme du marché (partiel)

Toutes ces tâches doivent être accomplies conformément aux standards, méthodologies et processus du SPF Finances (y compris le respect d’éventuelles évolutions futures de ceux-ci) et sur la base des SLA indiqués : Le marché est subdivisé en 6 lots :

lot 1: entretien (spécifique) de Zacheus, e-Notariat, Finprof, e-Deduction (SAFS CV), Avis de saisie (FCA).

lot 2: entretien (spécifique) de Stipad.

lot 3: entretien (spécifique) de FSP, Pandora, Cautionnements solidaires (SP10A), Faillites (SP10B), Grootboek/Grand Livre, CDC Dmat.

lot 4: entretien (général)

lot 5: nouveaux développements (en général), y compris redéveloppement significatif d’applications existantes.

lot 6: testing (général) : testing fonctionnel et tests techniques spécifiques (charge et performance).


IMPORTANT Le lot 6 « testing » ne pourra être attribué à un adjudicataire des lots 1 à 5 « entretien et développement » et vice-versa. Les lots 1, 2 et 3 « entretien spécifique » ne pourront être attribué à un adjudicataire des lots 4 et 5 « entretien et développement généraux » et vice-versa. Le lot 4 ne pourra être adjugé à un adjudicataire du lot 5 et vice versa.

Il s’agit d’un marché à bordereau de prix (A.R. Du 15 juillet 2011, art. 2, 5°). Aucune variante n’est autorisée.

Ce marché est composé de six lots. L’estimation budgétaire annuelle (TVAC) pour ces lots est la suivante : Lot 1 : 1000000€ Lot 2 : 1000000€ Lot 3 : 1000000€ Lot 4 : 1.500.000€ Lot 5 : 1.500.000€ Lot 6 : 1000000€ Ces montants sont donnés à titre indicatif, ils ne constituent pas un engagement pour le SPF FINANCES.

B2. Durée du contrat.

Le contrat prend cours le 1er jour ouvrable qui suit la date de la notification de l’attribution du marché et est conclu pour une durée de sept (7) ans. Cette durée de sept (7) ans est la période pendant laquelle les commandes peuvent être passées auprès du prestataire de services. Chaque partie peut mettre fin au contrat à la fin de chaque année de mise en œuvre à condition que la notification à l’autre partie soit faite par lettre recommandée:

au moins (3) trois mois avant la fin de l’année en cours si le pouvoir adjudicateur met fin au contrat,

au moins (6) six mois avant la fin de l’année d’exécution en cours si l’adjudicataire met fin au contrat.

Par ailleurs, le pouvoir adjudicateur se réserve le droit, moyennant un préavis de 30 jours de calendrier à signifier par lettre recommandée, de mettre fin à tout ou une partie de chacun des contrats en cas d’abandon d’un lot, en tout temps, de plein droit et sans indemnité pour le prestataire.


Dans ces deux cas, la partie qui subit la résiliation du contrat ne peut réclamer de dommages et intérêts.

B3. Pouvoir adjudicateur – Informations complémentaires. Le pouvoir adjudicateur est l'État belge, représenté par le Ministre des Finances. Pour des renseignements complémentaires sur le cahier spécial des charges ou pour toute remarque, les candidats-soumissionnaires peuvent prendre contact via l’adresse e-mail : [email protected]

B4. Documents régissant le marché

B4.1. Législation

La loi du 15 juin 2006 relative aux marchés publics et à certains marchés de travaux, de fournitures et de services

La loi du 17 juin 2013 relative à la motivation, à l’information et aux voies de recours en matière de marchés publics et de certains marchés de travaux, de fournitures et de services

L’arrêté royal du 15 juillet 2011 - arrêté royal relatif à la passation des marchés publics dans les secteurs classiques

L’arrêté royal du 14 janvier 2013 - arrêté royal établissant les règles générales d'exécution des marchés publics et des concessions de travaux publics

Le Règlement Général sur la Protection du Travail (RGPT) et le Code sur le bien-être au travail;

La réglementation de l’Union européenne relative aux marchés publics de services;

La loi du 4 août 1996 relative au bien-être des travailleurs lors de l’exécution de leur travail;

Toutes les modifications à la loi et aux arrêtés précités, en vigueur au jour de l’ouverture des offres.

B4.2. Documents du marché

Les avis de marché et avis rectificatifs publiés au Bulletin des Adjudications ou au Journal Officiel de l'Union européenne qui ont trait à ce marché, font partie intégrante du présent marché. Le soumissionnaire est censé en avoir pris connaissance et en avoir tenu compte lors de l’établissement de son offre ;

Le cahier spécial des charges n° S&L/DA/2016/060.

Les offres approuvées des soumissionnaires.

mailto:[email protected]


B5. Incompatibilités - conflits d’intérêts.

B5.1. Incompatibilités

L’attention des soumissionnaires est attirée sur l’article 8 de la loi du 15 juin 2006 et sur l’article 64 de l’arrêté royal du 15 juillet 2011 relatif aux incompatibilités.

B5.2. Conflits d'intérêts

Dans le cadre de la lutte contre les conflits d'intérêts, en particulier afin d'éviter le mécanisme du tourniquet (`revolving doors'), tel que défini dans la loi du 8 mai 2007 portant assentiment à la Convention des Nations unies contre la corruption, faite à New York le 31 octobre 2003, le soumissionnaire s'abstient de faire appel à un ou plusieurs anciens collaborateurs (internes ou externes) du SPF Finances, dans les deux ans qui suivent son/leur démission, départ à la retraite ou tout autre type de départ du SPF Finances, d'une quelconque manière, directement ou indirectement, pour l'élaboration et/ou l'introduction de son offre ou toute autre intervention dans le cadre de la procédure de passation, ainsi que pour certaines tâches à réaliser dans le cadre de l'exécution du présent marché. La disposition qui précède ne s'applique toutefois que lorsqu'un lien direct existe entre les précédentes activités prestées pour le pouvoir adjudicateur par la ou les personnes concernées et ses/leurs activités dans le cadre du présent marché. Toute infraction à cette mesure pouvant être de nature à fausser les conditions normales de la concurrence est passible d'une sanction conformément aux dispositions de l'article 9 de la loi du 15 juin 2006 relative aux marchés publics et à certains marchés de travaux, de fournitures et de services (ou, pour un marché dans les domaines de la défense et de la sécurité, de l'article 10 de la loi du 13 août 2011 relative aux marchés publics et à certains marchés de travaux, de fournitures et de services dans les domaines de la défense et de la sécurité). Concrètement, cette sanction consiste, selon le cas, soit à écarter l'offre, soit à résilier le marché.

B6. Forum de questions-réponses. Le pouvoir adjudicateur organisera un forum de questions-réponses pour le présent marché. Ce forum sera organisé comme suit : - les soumissionnaires potentiels doivent faire connaître leurs questions au pouvoir

adjudicateur le 5 août 2016 à 16h, à l’adresse e-mail suivante : [email protected]. Ils mentionneront la référence et l’objet du marché. Seules les questions parvenant au pouvoir adjudicateur avant cette date seront traitées sur le forum.

- le pouvoir adjudicateur mettra en ligne l’ensemble des questions ainsi que leurs réponses

le plus vite possible sur le site Web du SPF Finances (site : http://finances.belgium.be/fr/marches_publics/ )

Ce document sera partie intégrante des documents du marché.


http://finances.belgium.be/fr/marches_publics/


En l’absence de questions, aucun document ne sera publié. Si les entreprises intéressées constatent des imperfections, des imprécisions, etc. dans le cahier spécial des charges, elles sont invitées à le faire savoir par écrit avant le 5 août 2016 à 16h, et ce, selon les mêmes modalités que pour l’envoi des questions. Le SPF Finances accorde en particulier une grande importance à l’égalité de traitement des soumissionnaires et rédige les spécifications de ses cahiers des charges en conséquence. Si une société intéressée estime malgré tout ses chances diminuées ou réduites à néant par certaines spécifications du présent cahier spécial des charges, elle est invitée à en faire part par écrit ou à le signaler au plus tard lors de la séance d’information. Au besoin, le SPF adaptera le cahier des charges, s’il le juge nécessaire, pour en tenir compte.


C. ATTRIBUTION

C1. Droit et modalités d’introduction et ouverture des offres

C1.1. Droit et mode d’introduction des offres

En application de l’article 52, § 2, de l’arrêté royal du 15 juillet 2011, le pouvoir adjudicateur impose l’utilisation de moyens électroniques pour l’introduction des offres. Par conséquent, les offres doivent être introduites par voie électronique via l’application e-tendering (voir ci-dessous pour plus d’informations).

C1.1.1. Offres introduites par des moyens électroniques Lorsque des moyens électroniques sont utilisés pour l’introduction de l’offre, la signature électronique doit être conforme aux règles du droit européen et du droit national y correspondant relatives à la signature électronique avancée accompagnée d’un certificat qualifié et valide, et réalisée au moyen d’un dispositif sécurisé de création de signature (article 52, § 1er, 1° de l’arrêté royal du 15 juillet 2011). Les offres qui sont introduites par des moyens électroniques, doivent être envoyées via le site internet e-tendering https://eten.publicprocurement.be/ qui garantit le respect des conditions de l’article 52 de l’arrêté royal du 15 juillet 2011. Vu que l’envoi d’une offre par e-mail ne correspond pas aux conditions de l’article 52 de l’arrêté royal du 15 juillet 2011, il n’est pas admis d’introduire une offre de cette manière. Si nécessaire, les attestations comme demandées dans les documents du marché, sont scannées en PDF, afin de les joindre à l’offre. Certains documents à joindre qui ne peuvent pas être produits ou qui peuvent être difficilement produits par des moyens électroniques peuvent être délivrés sur papier avant la date limite de réception. En introduisant son offre entièrement ou partiellement via des moyens électroniques, le soumissionnaire accepte que les données qui résultent du fonctionnement du système de réception de son offre, soient enregistrées. Plus d'informations peuvent être obtenues sur le site: http://www.publicprocurement.be ou via le numéro de téléphone du helpdesk du service e-procurement : +32 (0)2 790 52 00.

IMPORTANT 1. Il est recommandé au soumissionnaire de s’enregistrer au plus tard la veille de

l’ouverture des offres afin de pouvoir prendre contact avec le helpdesk du e-procurement pour résoudre d’éventuels problèmes d’accès au site https://eten.publicprocurement.be/.

2. Il doit être tenu compte de la taille du fichier introduite par voie électronique ; celui-ci ne doit pas dépasser 350 Mo.

https://eten.publicprocurement.be/

http://www.publicprocurement.be/

https://eten.publicprocurement.be/


C1.1.2. Modification ou retrait d’une offre déjà introduite Lorsqu’un soumissionnaire souhaite modifier ou retirer une offre déjà envoyée ou introduite, ceci doit se dérouler conformément aux dispositions de l’article 91 de l’arrêté royal du 15 juillet 2011. La modification ou le retrait d’une offre déjà introduite est possible via des moyens électroniques qui satisfont au prescrit de l’article 52, § 1er de l’arrêté royal du 15 juillet 2011 ou sur papier. Afin de modifier ou de retirer une offre déjà envoyée ou introduite, une déclaration écrite est exigée, correctement signée par le soumissionnaire ou par son mandataire. L'objet et la portée des modifications doivent être indiqués avec précision. Le retrait doit être inconditionnel. Le retrait peut également être communiqué par téléfax, ou via un moyen électronique qui n’est pas conforme à l’article 52, § 1er de l’arrêté royal du 15 juillet 2011, pour autant que : 1° ce retrait parvienne au président de la séance d’ouverture des offres avant qu’il n'ouvre la

séance 2° et qu’il soit confirmé par lettre recommandée déposée à la poste au plus tard le jour avant

la séance d’ouverture.

C1.2. Ouverture des offres

La séance d’ouverture des offres aura lieu le 6 septembre 2016 à 14h30 , dans une des salles de réunion du North Galaxy, accessible via l’entrée « visiteurs », boulevard du Roi Albert II, 33 à 1030 BRUXELLES. Chaque offre doit parvenir au président de la séance avant qu’il ne déclare la séance ouverte. Seules les offres qui parviennent au président de la séance avant qu’il ne déclare la séance ouverte, peuvent être acceptées. Toutefois, une offre tardive est acceptée pour autant que le pouvoir adjudicateur n’ait pas encore conclu le marché et que l’offre ait été envoyée sous pli recommandé au plus tard quatre jours calendrier avant la date de la séance d’ouverture.

C2. Les offres

C2.1. Données à mentionner dans l’offre

L’attention des soumissionnaires est attirée sur l’article 8 de la loi du 15 juin 2006 et sur l’article 64 de l’arrêté royal du 15 juillet 2011 relatif aux incompatibilités. Il est fortement recommandé au soumissionnaire d’utiliser le formulaire d’offre joint en annexe. Dans cette optique, l’attention du soumissionnaire est attirée sur l’article 80 de l’arrêté royal du 15 juillet 2011, qui stipule: « Lorsqu’aux documents du marché est joint un formulaire destiné à établir l’offre, le soumissionnaire en fait usage. À défaut d’utiliser ce formulaire, il supporte l’entière responsabilité de la parfaite concordance entre les documents qu’il a utilisés et le formulaire ».


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. Les documents d’ordre technique qui sont joints à l’offre 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. 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 à son offre. Le soumissionnaire indique clairement dans son offre quelle information est confidentielle et/ou se rapporte à des secrets techniques ou commerciaux et ne peut donc pas être divulguée par le pouvoir adjudicateur. Le formulaire d’offre est joint au cahier des charges. Les biffures, ratures, additions et corrections, dans l’offre comme dans ses annexes, doivent être signées (et non parafées) par le soumissionnaire ou son fondé de pouvoir. À défaut, l’offre est considérée comme irrégulière. Les soumissionnaires sont tenus de respecter explicitement toutes les dispositions administratives et contractuelles du présent cahier des charges. Toute réserve ou absence d’engagement par rapport à une de ces dispositions peut entraîner l’irrégularité de l’offre.

Les renseignements suivants seront mentionnés dans l’offre:

A . Formulaire d’offre ;

- la signature de la personne ou les personnes, selon le cas, ayant mandat pour signer

l’offre

- la qualité de la personne ou des personnes, selon le cas, qui signe(nt) l’offre ;

- la date à laquelle la personne ou les personnes précitée(s), selon le cas, a/ont signé

l’offre ;

- le numéro d’immatriculation complet du soumissionnaire auprès de la Banque Carrefour

des Entreprises (pour les soumissionnaires belges) ;

- le numéro d’inscription à l’ONSS ;

- le numéro et le libellé du compte du soumissionnaire ouvert auprès de la Banque de la

Poste ou d’un autre établissement financier ;

- les noms, prénoms, la qualité ou profession, la nationalité et le domicile du

soumissionnaire ou lorsque celui-ci est une société, sa raison sociale ou dénomination,

sa forme juridique, sa nationalité et son siège social ;

- tous les éléments et documents nécessaires pour l’évaluation des offres ;

B. L’inventaire des prix

- le prix unitaire forfaitaire par profil par jour-homme en lettres et en chiffres (hors TVA) ;

- le prix unitaire forfaitaire par profil par jour-homme en lettres et en chiffres (TVA

comprise) ;


C. Documents de sélection

- Documents relatifs aux critères de sélection permettant d’évaluer la capacité

financière et économique du soumissionnaire.

La déclaration quant aux chiffres d’affaires concernant les prestations auxquelles se

réfère le marché réalisée au cours des trois dernières années (2013, 2014 et 2015).

- Documents relatifs au critère de sélection permettant d’évaluer la capacité

technique du soumissionnaire.

Une fiche à compléter (annexe 2) pour un minimum de 3 références de prestations

exécutées, au cours des trois dernières années satisfaisant aux conditions cumulatives

suivantes (voir point C 5.1.2. Sélection de qualité) :

Pour les lots 1, 2 et 3 « Entretien spécifique »

Le soumissionnaire remplira dans son offre l’annexe obligatoire 3 a et b (CV et tableau de

synthèse) pour ce qui concerne les profils demandés. L’entreprise ne pourra être

sélectionnée si des renseignements exigés ne figurent pas dans l’annexe 3 a et b à

remplir obligatoirement.

(Voir point C.5.1.2 Sélection de qualité)

Pour les lots 4 et 5 « entretien général et nouveaux développements »

Le soumissionnaire remplira dans son offre l’annexe obligatoire 3a et b (CV et tableau de


sélectionnée si des renseignements exigés ne figurent pas dans l’annexe obligatoire.


Pour le lot 6 « tests »

Le soumissionnaire remplira dans son offre l’annexe obligatoire 3a et b (CV et tableau de


sélectionnée si des renseignements exigés ne figurent pas dans l’annexe obligatoire.


D. Proposition technique :

La proposition suit la structure du volet E « Prescriptions techniques »

IMPORTANT Le soumissionnaire est tenu d’introduire les documents suivants sous peine de nullité de l’offre : 1. Concept MASTER SLA 2. Dossier Accords et Procédures (DAP) 3. Service Quality Plan (SQP) 4. Service Improvement Plan (SIP) 5. Exemple de rapportage 6. Modèle d'offre


IMPORTANT

1. Le formulaire d’offre complété, daté et signé ;

2. Pour toute offre introduite par un mandataire, l’acte authentique ou sous seing privé

(ou une copie de cet acte) joint par le mandataire prouvant qu’il est habilité à engager l’entité

pour laquelle il soumissionne. Le mandataire peut également mentionner le numéro de

l'annexe au Moniteur belge à laquelle est publié le mandat.

Signature de l’offre

Le soumissionnaire signe l’offre et les autres annexes jointes à l’offre (art. 82 §1 A.R.

15/07/2011).

Concernant les mandataires:

Toute offre introduite par des mandataires doit indiquer l'entité au nom de laquelle

agissent les mandataires.

Celui qui a signé l’offre 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 de 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 (article 82

A.R. 15/07/2011)

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.

Concernant les documents d’ordre technique

L’offre technique ne peut contenir aucune précision administrative ni indication de prix. Il

ne sera tenu aucun compte des indications administratives dans une autre partie

que la partie A. ou C, ou de prix figurant dans une autre partie que la partie B.

Le soumissionnaire mentionne clairement dans son offre les différences par

rapport au cahier des charges et aux besoins fonctionnels. Sans cette précision

explicite, le cahier des charges prévaudra en cas de litige.


C2.3. Durée de validité de l’offre.

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

C2.4. Documents et attestations à joindre à l’offre

Les soumissionnaires joignent à leur offre : - tous les documents demandés dans le cadre des critères de sélection et des critères

d’attribution (voir rubrique 5 du volet C. Attribution) ; - les statuts ainsi que tout autre document utile prouvant le mandat du (des) signataire(s).

C4. Prix. Le présent marché est un marché à bordereau de prix. Le prestataire de services est censé avoir inclus tous les frais possibles dans son prix unitaire forfaitaire par profil par homme-jour, à l’exception de la TVA. Le prix proposé constituera un montant forfaitaire avec possibilité de révision de prix pendant la durée totale du marché telle qu’elle résulte du point 2. Révision de prix, du volet «D. Exécution ». L’inventaire ainsi que le formulaire d’offre, joint au modèle de soumission (en annexe 1), doit, sous peine de nullité, être entièrement et correctement rempli. Tous les prix seront obligatoirement mentionnés en euros.

C5. Droit d’accès – Sélection qualitative – Régularité des offres – Critères d’attribution

C5.1. Droit d’accès et sélection qualitative

Les soumissionnaires sont évalués sur la base du droit d’accès et de la sélection qualitative tels que mentionnés ci-après. Seules les offres des soumissionnaires qui satisfont au droit d’accès et à la sélection qualitative sont prises en considération pour participer à la comparaison des offres sur la base des critères d’attribution repris au point 5.3.du volet C. Attribution du présent cahier spécial des charges, dans la mesure où ces offres sont régulières sur le plan formel et matériel.


C5.1.1. Droit d’accès Par le dépôt de son offre, le soumissionnaire atteste qu’il ne se trouve pas dans un des cas d’exclusion figurant ci-dessous. Le pouvoir adjudicateur vérifiera l’exactitude de cette déclaration sur l’honneur implicite dans le chef du soumissionnaire dont l’offre est la mieux classée. A cette fin, il demandera au soumissionnaire concerné par les moyens les plus rapides, et dans le délai qu’il détermine, de fournir les renseignements ou documents permettant de vérifier sa situation personnelle. Le pouvoir adjudicateur demandera lui-même les renseignements ou documents qu’il peut obtenir gratuitement par des moyens électroniques auprès des services qui en sont gestionnaires. Critère d’exclusion pour cause de constat d’infraction à l’interdiction du travail illégal Est exclu de l’accès au marché, à quelque stade que ce soit de la procédure, tout candidat ou soumissionnaire pour lequel il est établi qu’il a occupé, en tant qu’employeur, des ressortissants de pays tiers en séjour illégal au sens de la loi du 11 février 2013 prévoyant des sanctions et des mesures à l’encontre des employeurs de ressortissants de pays tiers en séjour illégal. Cette disposition s’applique de la même manière à l’égard de l’entité à laquelle le candidat ou le soumissionnaire fait appel lorsque la capacité de cette entité est déterminante pour la sélection du candidat ou du soumissionnaire, selon le cas. L’exclusion de la participation aux marchés publics vaut pour une durée pouvant aller jusqu’à cinq ans. 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 ordre en ce qui concerne ses obligations vis-à-vis de l’Office national de Sécurité sociale. Il est considéré comme étant en ordre en ce qui concerne les obligations précitées, s’il apparaît, qu’au plus tard la veille de la date limite de réception des offres, il :

1° a transmis à l’Office National de Sécurité Sociale 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

2° n’a pas pour ces déclarations une dette en cotisations supérieure à 3.000 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 à 3 000 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, à la fin du trimestre civil visé au deuxième alinéa, à l’égard d’un pouvoir adjudicateur au sens de l’article 2, 1° de la loi du 15 juin 2006, ou d’une entreprise publique au sens de l’article 2, 2° de la loi du 15 juin 2006, une ou plusieurs créances certaines, exigibles et libres de tout engagement à l’égard de tiers pour un montant au moins égal, à 3 000 euros près, à celui pour lequel il est en retard de paiement de cotisations.


IMPORTANT Il est rappelé au soumissionnaire ou au candidat qui possède une dette fiscale professionnelle supérieure à 3.000 euros et qui peut se prévaloir d’une créance à l’égard d’un pouvoir adjudicateur ou d’une entreprise publique qu’il convient au soumissionnaire ou au candidat d’établir qu’il possède une telle créance et que celle-ci soit certaine, exigible et libre de tout engagement à l’égard de tiers. A cette fin, le soumissionnaire est invité à communiquer dans son offre l’existence d’une ou de créances pouvant être prises en considération par le pouvoir adjudicateur ainsi que le caractère certain, exigible et libre de tous engagements à l’égard de tiers.

§ 2. Au plus tard la veille de la date limite de réception des offres, le soumissionnaire étranger doit

1° être en règle avec ses obligations relatives au paiement des cotisations de sécurité

sociale selon les dispositions légales du pays où il est établi 2° être en ordre avec les dispositions du § 1er, s’il 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.

§ 3. A quelque stade de la procédure que ce soit, le pouvoir adjudicateur peut s’informer,

par tous 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 Conformément à l’article 20 de la loi du 15 juin 2006, est exclu de l’accès au marché, à quelque stade que ce soit de la procédure d’attribution, le soumissionnaire qui a fait l’objet d’une condamnation prononcée par une décision judiciaire ayant force de chose jugée dont le pouvoir adjudicateur a connaissance pour : 1° participation à une organisation criminelle telle que définie à l’article 324bis du Code

pénal 2° corruption, telle que définie aux articles 246 et 250 du Code pénal 3° fraude au sens de l’article 1er de la convention relative à la protection des intérêts

financiers des communautés européennes, approuvée par la loi du 17 février 2002 4° blanchiment de capitaux tel que défini à l’article 5 de la loi du 11 janvier 1993 relative à

la prévention de l’utilisation du système financier aux fins du blanchiment de capitaux et du financement du terrorisme.

En vue de l’application du présent paragraphe, le pouvoir adjudicateur a le droit de demander aux soumissionnaires de fournir les renseignements ou documents nécessaires. Lorsqu’il a des doutes sur la situation personnelle de ces candidats ou soumissionnaires, il peut s’adresser aux autorités compétentes belges ou étrangères pour obtenir les informations qu’il estime nécessaires à ce propos. Troisième critère d’exclusion Est exclu de l’accès au marché, à quelque stade que ce soit de la procédure d’attribution, le soumissionnaire qui :


1° est en état de faillite, de liquidation, de cessation d'activités, de réorganisation judiciaire ou dans toute situation analogue résultant d'une procédure de même nature existant dans d'autres réglementations nationales ;

2° qui a fait l’aveu de sa faillite ou fait l’objet d’une procédure de liquidation, de réorganisation judiciaire ou de toute autre procédure de même nature existant dans d’autres réglementations nationales.

Quatrième critère d’exclusion

Est exclu de la participation au marché public, le soumissionnaire qui a fait l’objet d’une condamnation prononcée par une décision judiciaire ayant force de chose jugée pour tout délit affectant sa moralité professionnelle. Cinquième critère d’exclusion Le soumissionnaire ne peut pas, en matière professionnelle, avoir commis une faute grave, constatée par tout moyen dont le pouvoir adjudicateur pourra justifier. En outre, le soumissionnaire, par la signature de son offre, s’engage à respecter les normes définies dans les conventions de base de l’Organisation Internationale du Travail (OIT) et, en particulier: 1° l’interdiction du travail forcé (conventions n° 29 concernant le travail forcé ou obligatoire,

1930, et n° 105 sur l’abolition du travail forcé, 1957) 2° le droit à la liberté syndicale (convention n° 87 relative à la liberté syndicale et la

protection du droit syndical, 1948)

3° le droit d’organisation et de négociation collective (convention n° 98 relative au droit d’organisation et de négociation collective, 1949) ;

4° l’interdiction de toute discrimination en matière de travail et de rémunération (conventions n° 100 sur l’égalité de rémunération, 1951 et n° 111 concernant la discrimination (emploi et profession), 1958)

5° l’âge minimum fixé pour le travail des enfants (convention n° 138 sur l’âge minimum, 1973), ainsi que l’interdiction des pires formes de travail des enfants (convention n° 182 sur les pires formes de travail des enfants, 1999).

Le non-respect des conventions susmentionnées sera donc considéré comme faute grave en matière professionnelle au sens de l’article 61, §2, 4° de l’AR du 15 juillet 2011. Les dispositions qui précèdent s’appliquent sans préjudice des autres dispositions reprises à l’article 61 de l’arrêté précité. Sixième critère d’exclusion Le soumissionnaire doit être en règle avec le paiement de ses impôts et taxes selon la législation belge ou celle du pays où il est établi. Est en règle par rapport aux obligations susmentionnées applicables en Belgique, le candidat ou le soumissionnaire qui n’a pas pour l’ensemble de ses obligations fiscales professionnelles une dette supérieure à 3.000 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 fiscale professionnelle est supérieure à 3.000 euros, le candidat ou le soumissionnaire est considéré comme étant en règle s'il établit, avant la décision de sélection ou d'attribution du marché, selon le cas, qu'il possède à l’égard d’un pouvoir adjudicateur au sens de l’article 2,1°, de la loi ou d’une entreprise publique au sens de l’article 2,2°, de la loi, à la fin de la période fiscale visée précédemment, une ou des créances certaines, exigibles et libres de tout engagement à l'égard de tiers pour un montant au moins égal, à 3.000 euros près, à celui pour lequel il est en retard de paiement de ses dettes fiscales professionnelles. Pour le soumissionnaire ou le candidat belge, le pouvoir adjudicateur procédera lui-même, à la vérification des obligations en matière d’impôts et de taxes.

IMPORTANT Il est rappelé au soumissionnaire ou au candidat qui possède une dette fiscale professionnelle supérieure à 3.000 euros et qui peut se prévaloir d’une créance à l’égard d’un pouvoir adjudicateur ou d’une entreprise publique qu’il convient au soumissionnaire ou au candidat d’établir qu’il possède une telle créance et que celle-ci soit certaine, exigible et libre de tout engagement à l’égard de tiers. A cette fin, le soumissionnaire est invité à communiquer dans son offre l’existence d’une ou de créances pouvant être prises en considération par le pouvoir adjudicateur ainsi que le caractère certain, exigible et libre de tous engagements à l’égard de tiers.

Pour que le soumissionnaire étranger ou le candidat étranger soit considéré comme étant en règle celui-ci joint à sa demande de participation ou à son offre, selon le cas, une attestation dont il résulte qu'il est en règle par rapport à ses obligations fiscales professionnelles selon les dispositions légales du pays où il est établi. Cette attestation doit se rapporter à la dernière période fiscale précédant la date de réception ultime des demandes de participation ou des offres, selon le cas. Septième critère d’exclusion Sera exclu de la participation au marché public, le soumissionnaire qui s’est rendu gravement coupable de fausses déclarations en fournissant des renseignements exigibles en application du présent chapitre ou qui n’a pas fourni ces renseignements.

C5.1.2. Sélection de qualité

Critères de sélection relatifs aux moyens financiers du soumissionnaire (article 67, 3° de l’arrêté royal du 15 juillet 2011) Le soumissionnaire doit avoir réalisé au cours de chacun des trois derniers exercices comptables (2013, 2014, 2015) un chiffre d’affaires annuel relatif aux activités directement liées aux services décrits dans le présent cahier spécial des charges, d’au moins : Pour le lot 1 : 500.000,00 EUR Pour le lot 2 : 500.000,00 EUR Pour le lot 3 : 500.000,00 EUR Pour le lot 4 : 1.000.000,00 EUR Pour le lot 5 : 1.000.000,00 EUR Pour le lot 6 : 1.000.000,00 EUR


Il joindra à son offre une déclaration relative à ces chiffres d’affaires réalisés pendant les trois derniers exercices. Les entreprises étrangères doivent joindre également à leur offre les comptes annuels approuvés des trois dernières années ou un document reprenant tous les actifs et tous les passifs de l’entreprise. Au cas où l’entreprise n’a pas encore publié de compte annuel, un bilan intermédiaire certifié conforme par le comptable ou par le réviseur d’entreprise ou par la personne ou l’organisme qui exerce ce type de fonction dans le pays concerné suffit.

Critère de sélection se rapportant à la compétence technique du soumissionnaire (article 72, 7° de l’arrêté royal du 15 juillet 2011) Pour les lots 1 à 5 « entretien et développement » : Le soumissionnaire doit disposer, au cours des trois dernières années (2013, 2014, 2015), au minimum de 3 références similaires, d’une charge annuelle d’au moins : Pour le lot 1 : 500 hommes/jours Pour le lot 2 : 500 hommes/jours Pour le lot 3 : 500 hommes/jours Pour le lot 4 : 1000 hommes/jours Pour le lot 5 : 1000 hommes/jours Pour démontrer le caractère similaire, le soumissionnaire remplit le tableau en annexe 2 du présent marché autant de fois que de références présentées, en indiquant au minimum l’objet de la référence, le montant, la charge jours/hommes la date d’exécution des prestations et le destinataire public ou privé. Ces références sont en outre étayées : - pour ce qui concerne les références publiques : d’une attestation de bonne exécution

établie ou contresignée par l’autorité concernée ; - pour ce qui concerne les références privées : d’une déclaration sur l’honneur du candidat

attestant que lesdites références ont été dûment exécutées, conformément aux exigences reprises ci-dessus.

Pour le lot 6 « tests » : Le soumissionnaire doit disposer, au minimum de 3 références (2013, 2014, 2015) de services exécutés, au cours des 3 dernières années satisfaisant aux conditions cumulatives suivantes :

Sur les marchés informatiques où le contenu est similaire à celui du présent marché

Comprenant au minimum des activités d’assurance qualité et de tests de performance et fonctionnel (system testing)

Pour démontrer cela, le soumissionnaire remplit le tableau en annexe 2 du présent marché autant de fois que de références présentées, en indiquant au minimum l’objet de la référence, le montant, la charge jours/hommes la date d’exécution des prestations et le destinataire public ou privé. Ces références sont en outre étayées :


- pour ce qui concerne les références publiques : d’une attestation de bonne exécution établie ou contresignée par l’autorité concernée ;

- pour ce qui concerne les références privées : d’une déclaration sur l’honneur du candidat attestant que lesdites références ont été dûment exécutées, conformément aux exigences reprises ci-dessus.

Critère de sélection se rapportant à la compétence technique du soumissionnaire (article 72, 7° de l’arrêté royal du 15 juillet 2011)

IMPORTANT Pour ce critère de sélection, l’annexe 3a et 3b doit obligatoirement être remplie, sans quoi l’entreprise ne pourra être sélectionnée.

Pour les lots 1, 2 et 3 « Entretien spécifique » Le soumissionnaire doit disposer du personnel suffisamment compétent pour pouvoir exécuter le marché convenablement. Les personnes qui exécuteront réellement le marché devront, sous peine de nullité de l’offre, satisfaire aux profils demandés, tels que décrits au point « E.3.1.2. Profils » de l'offre. Le soumissionnaire doit prévoir une équipe qui se compose au minimum des ETP (équivalents temps plein) suivants pour chaque lot.

Profil Capacité minimal

e

Task Manager 1

Architecte technique 1

Business Analist 2

Développeur technologie JEE Junior 2

Développeur technologie JEE Senior 2

Le soumissionnaire remplira dans son offre l’annexe obligatoire 3 (CV et tableau de synthèse) pour ce qui concerne les profils demandés. L’entreprise ne pourra être sélectionnée si des renseignements exigés ne figurent pas dans l’annexe obligatoire. Pour démontrer ses capacités, il joindra à son offre tous les CV nécessaires qui correspondent aux profils de compétences présentés. Les CV joints devront absolument respecter le modèle fourni par le pouvoir adjudicateur. Par exemple, lorsque l’on soumissionne pour les lots 1, 2 et 3, il est nécessaire de disposer d’une équipe composée au minimum de 8 personnes pour chaque lot, soit 24 personnes au total.

IMPORTANT Le soumissionnaire qui propose dans son offre une équipe qui ne satisfait pas la capacité minimale ne sera pas sélectionné.

Pour les lots 4 et 5 « entretien général et nouveaux développements » Le soumissionnaire doit disposer du personnel suffisamment compétent pour pouvoir exécuter le marché convenablement. Les personnes qui exécuteront réellement le marché


devront, sous peine de nullité de l’offre, satisfaire aux profils demandés, tels que décrits au point « E.3.1.2. Profils » de l'offre. Le soumissionnaire doit prévoir une équipe qui se compose au minimum des ETP (équivalents temps plein) suivants pour chaque lot pour lequel il soumissionne.

Profil Capacité minimal

e

Task Manager 1

Technical Architect 2

Business Analist 3



Le soumissionnaire remplira dans son offre l’annexe obligatoire 3 (CV et tableau de synthèse) pour ce qui concerne les profils demandés. L’entreprise ne pourra être sélectionnée si des renseignements exigés ne figurent pas dans l’annexe obligatoire. Pour démontrer ses capacités, il joindra à son offre tous les CV nécessaires qui correspondent aux profils de compétences présentés. Les CV joints devront absolument respecter le modèle fourni par le pouvoir adjudicateur. Lorsque l’on soumissionne à la fois pour le lot 4 et 5, on peut proposer les mêmes personnes pour l’équipe minimale de 14 personnes, puisque l’adjudicataire du lot 4 ne peut être le même que celui du lot 5 et vice versa.


Pour le lot 6 « tests » Le soumissionnaire doit disposer du personnel suffisamment compétent pour pouvoir exécuter le marché convenablement. Les personnes qui exécuteront réellement le marché devront, sous peine de nullité de l’offre, satisfaire aux profils demandés, tels que décrits au point « E.3.2.3. Profils » de l'offre. Le soumissionnaire doit prévoir une équipe qui se compose au minimum des ETP (équivalents temps plein) suivants pour chaque lot pour lequel il soumissionne.

Profil Capacité minimale

Testeur 4

Spécialiste en test tools 2

Spécialiste en méthodologie de test

2

Quality Assurance Coordinator 2

Par exemple, lorsque l’on soumissionne pour le lot 6, il faut disposer au minimum d’une équipe de 10 personnes.



C5.2. Régularité des offres

Les offres des soumissionnaires sélectionnés seront examinées du point de vue de leur régularité. Les offres irrégulières sont exclues. Seules les offres régulières seront prises en considération pour être confrontées aux critères d’attribution.

C5.3. Critères qui seront utilisés lors de l’évaluation des offres

Les offres régulières des soumissionnaires sélectionnés seront examinées dans le cadre d’un certain nombre de critères. Ces critères seront pondérés afin d’obtenir un classement final.

IMPORTANT Le pouvoir adjudicateur se réserve le droit de faire appel, pour l’analyse des offres, à un ou plusieurs expert(s) externe(s) au SPF Finances.

C5.3.1. Liste des critères d’attribution Pour les lots 1 à 5 « entretien et développement » : Par lot, le soumissionnaire retenu sera celui qui a introduit l’offre la meilleure compte tenu des critères d’attribution suivants :

Critères Points

I Prix 60

II Mode d’exécution 40 (min 24)

II.1

:

plan d'approche 20

II.2

:

transfert des connaissances 20

IMPORTANT Le soumissionnaire doit obtenir au moins 60 % pour les critères II sous peine d’exclusion de l’offre.

Pour le lot 6 « tests » : Pour ce lot, le soumissionnaire retenu sera celui qui a introduit l’offre la meilleure compte tenu des critères d’attribution suivants :


Critères Points

I Prix 90

II Partenariat – garantie

expertise sur nos standards

10

C5.3.2. Méthode de détermination de l’offre la plus intéressante.

L’évaluation des critères se fera comme suit :

Pour les lots 1 à 5 « entretien et développement » :

I Le prix 60 points

Concernant l’évaluation du critère d’attribution « Prix », la formule suivante sera appliquée pour calculer les points :

Mo = P x 60/140 Où : Mo est le nombre de points obtenus par le soumissionnaire pour le critère « Prix» ; P est le résultat obtenu après l’addition des différents profils pour l’offre analysée ;

Prix profils Points

Task Manager P1 (sur 10 points)

Technical Architect P2 (sur 20 points)

Business Analist P3 (sur 30 points)

Développeur technologie JEE Junior P4 (sur 40 points)

Développeur technologie JEE Senior P5 (sur 40 points)

Total intermédiaire (P1+P2+P3+P4+P5) P (140 points)

Tous les prix doivent être exprimés en euro, TVAC et pour une journée de 8h. Les compétences minimales et activités attendues sont décrites plus loin dans le texte. Prix profil Task Manager (10 points) Le critère « Prix » est pondéré de la façon suivante :

où :

Proffre = prix de l'offre, Prmin = le prix de l’offre la moins chère dans les offres régulières. P1 = points attribués au critère « Prix profil Task Manager » pour ce profil

Les prix sont exprimés TVAC. Prix profil Lead Technical Architect (20 points) Le critère « Prix » est pondéré de la façon suivante :

offre P1 :

Pr

min Pr 10 x


où :

Proffre = prix de l'offre, Prmin = le prix de l’offre la moins chère dans les offres régulières. P2 = points attribués au critère Prix profil « Technical Architect »

Les prix sont exprimés TVAC. Prix profil Business Analist (30 points) Le critère « Prix » est pondéré de la façon suivante :

où :

Proffre = prix de l'offre, Prmin = le prix de l’offre la moins chère dans les offres régulières. P3 = points attribués au critère Prix profil « Business Analist »

Les prix sont exprimés TVAC. Prix profil Développeur technologie JEE Junior (40 points) Le critère « Prix » est pondéré de la façon suivante :

où :

Proffre = prix de l'offre, Prmin = le prix de l’offre la moins chère dans les offres régulières. P4 = points attribués au critère prix profil « Développeur technologie JEE Junior »

Les prix sont exprimés TVAC. Prix profil Développeur technologie JEE Senior (40 points) Le critère « Prix » est pondéré de la façon suivante :

où :

Proffre = prix de l'offre, Prmin = le prix de l’offre la moins chère dans les offres régulières. P5 = points attribués au critère prix profil « Développeur technologie JEE Senior »

Les prix sont exprimés TVAC.

offre P5

Pr

min Pr 40 x

offre P4

Pr

min Pr 40 x

offre P3

Pr

min Pr 30 x

offre P2 :

Pr

min Pr 20 x


II. Le mode d’exécution 40 points

IMPORTANT Le soumissionnaire qui n’obtient pas 60% pour le critère d’attribution « mode d’exécution » ne sera pas pris en considération pour l’attribution du marché, et l’offre sera par conséquent considérée comme irrégulière. Les points des critères d’attribution « mode exécution » s’obtiennent en additionnant les points obtenus pour les sous-critères d’attribution 1 et 2.

Le critère d’évaluation « mode d’exécution » est réparti en deux (2) sous-critères. Lors de l’attribution des points à un sous-critère, on tiendra compte des critères suivants :

- la présence, la précision, l’ampleur, l’univocité et l’exhaustivité de la description et de la proposition

- la cohérence interne des propositions

- la clarté et à l’évidence de l’argumentaire et de la démonstration (en se basant

essentiellement sur les standards et pratiques réputés du marché IT).

- la mesure dans laquelle la proposition répond aux besoins réels du SPF Finances, tels que décrits dans le présent cahier des charges et compte tenu des standards et fondements « Fondements ICT » et des documents connexes (voir site Web SPF Finances « Sur le SPF – Historique de la modernisation – ICT »).

Les soumissionnaires qui ne sont pas familiarisés aux méthodologies spécifiques du SPF Finances (PMFin, FUP et Cobifin) peuvent se référer dans leurs réponses aux méthodologies standards sous-jacentes (Prince2, RUP et Cobit). Une description excessivement longue ou des informations superflues entraînent la perte de points pour le sous-critère concerné.

IMPORTANT Le soumissionnaire est invité à faire clairement référence à ce sous-critère dans son offre. Le nombre de pages consacrées à la description de la méthodologie pour le sous-critère 1 et le sous-critère 2 est limité à 20 pages chacun (police Arial 11) sous peine de non-prise en considération de la méthodologie décrite, et de l’attribution de 0 point (impossible à évaluer).

Sous-critère 1 : Le plan d'approche (20 points) On entend par « plan d’approche » la description détaillée de la vision, de la stratégie et de la méthodologie utilisées pour traduire le cycle de maintenance pour un marché partiel spécifique en un projet concret et établir l’offre pour ce marché partiel. La méthodologie utilisée pour la détermination du prix du marché partiel revêt ici une grande importance.


À cet effet, le soumissionnaire décrira son interprétation et élaboration du cycle de maintenance décrit au paragraphe « E.2.1.2 Cycle de maintenance ». Les descriptions demandées doivent être données à l’aide de processus, de méthodologies, de modèles de calcul et d’outils éventuellement utilisés, et ce, de manière complète, claire et transparente. Le soumissionnaire décrira comment, pour un marché partiel (cycle de maintenance) de ce marché :

il établit sa pré-analyse et son évaluation ;

il organise sa work breakdown structure (WBS) ;

il estime la charge de travail ;

il établit son plan de projet (intervalles de temps, dépendances…) ;

il réalise une analyse de risque ;

il établit une offre ;

il la traduit en termes de composition de l’équipe et/ou de profils ;

il calcule le prix de ce marché partiel ;

il établit une offre.

IMPORTANT Le soumissionnaire est invité à joindre un modèle d’offre qui illustre clairement ces principes sous peine de nullité de l’offre. Voir point 2.1.2. Cycle de maintenance.

Le soumissionnaire peut, s’il l’estime nécessaire et si cela est suffisamment pertinent, joindre des informations supplémentaires concernant ce critère d’attribution. Pour ce critère, l’évaluation suivante sera appliquée :

20 points : très bon 16 points : bon 12 points : satisfaisant 8 points : mauvais 4 points : très mauvais 0 point : inexistant ou impossible à évaluer

Sous-critère 2 : Transfert de connaissances (20 points) Puisqu’une étroite collaboration avec les équipes internes de développement et de maintenance et le transfert de connaissances vers ces équipes constituent un aspect important de ce marché, le soumissionnaire est invité à décrire sa vision et sa stratégie en la matière. Dans son offre, le soumissionnaire devra décrire comment il pense regrouper et diffuser les connaissances et informations relatives aux projets (partiels) de manière organisée. Et comment il envisage de garantir la transparence nécessaire avec le personnel ICT et les représentants du business et faire en sorte que ce personnel soit suffisamment impliqué à tout moment du cycle du projet. Dans sa réponse, il décrira sa stratégie et sa méthodologie en matière de transfert de connaissances. En vue de garantir une acquisition optimale des connaissances par les membres du SPF Finances, il devra indiquer les responsabilités de toutes les personnes impliquées en la matière. Les modalités de la coopération sont décrites dans le paragraphe « E.2.1 Contexte général ». Plusieurs formes possibles de transfert de connaissances sont abordées dans le


paragraphe « E.2.1.3. Transfert des connaissances ». Le soumissionnaire est invité à répondre aux questions qui y sont posées et à donner sa vision des principes concernés si nécessaires. Le pouvoir adjudicateur voit comme scénarios de coopération possibles :

l’intégration de collaborateurs internes dans l’équipe mise à disposition par l’adjudicataire (co-sourcing)

l’intégration de profils externes dans les équipes internes (body shopping)

l’exécution autonome par une équipe externe team (project mode) Pour le transfert de connaissances, le pouvoir adjudicateur attend au moins (et obligatoirement !) du soumissionnaire :

qu’il adapte, complète et rédige la documentation relative au projet, comme décrit dans la méthodologie FUP (/RUP)

qu’il assure l’accompagnement, le coaching et si nécessaire la formation des collaborateurs internes qui sont liés au projet (partiel)

qu’il fournisse des informations (éventuellement une formation) à tous les collaborateurs (internes et externes) impliqués dans une phase ultérieure de l’application (utilisateurs (internes), business, development, testing, service desk..).

L'adjudicataire s’engage à assurer ce transfert de connaissances et cette coopération de manière continue, implicite et intégrée sans supplément de prestation. Le soumissionnaire peut également proposer d’autres méthodes de transfert de connaissances et/ou scénarios de coopération en vue d’obtenir qu’au terme du projet (partiel), le SPF Finances soit à même de poursuivre la maintenance de l’application concernée et de la faire évoluer en gestion propre. Outre la vision et la stratégie des scénarios et méthodologies proposés, le soumissionnaire est invité à donner dans son offre les informations suivantes pour chacun de ces scénarios et méthodologies (ainsi que ceux qu’il ajouterait lui-même) :

une analyse SWOT

une analyse de risque

le ou les remèdes possibles aux faiblesses, menaces et risques

les éventuelles procédures d’escalade (dans toutes les directions)

les responsabilités de l’adjudicataire et du pouvoir adjudicateur en la matière

… (toutes les informations pertinentes possibles concernant ces sujets soutenant sa candidature)

Le soumissionnaire peut, s’il l’estime nécessaire et si cela est suffisamment pertinent, joindre des informations supplémentaires concernant ce critère d’attribution. Pour ce critère, l’évaluation suivante sera appliquée :

20 points : très bon 16 points : bon 12 points : satisfaisant 8 points : mauvais 4 points : très mauvais 0 point : inexistant ou impossible à évaluer


Pour le lot 6 « tests »

I. Le prix 90 points

Concernant l’évaluation du critère d’attribution « Prix », la formule suivante sera appliquée pour calculer les points :

Mo = P x 90/100 Où : Mo est le nombre de points obtenus par le soumissionnaire pour le critère « Prix» ; P est le résultat obtenu après l’addition des différents profils pour l’offre analysée ;

Prix profils Points

Testeur P1 (sur 40 points)

Spécialiste en test tools P2 (sur 20 points)

Spécialiste en méthodologie de test P3 (sur 20 points)

Quality Assurance Coordinator P4 (sur 20 points)

Total intermédiaire (P1+P2+P3+P4+P5) P (100 points)

Tous les prix doivent être exprimés en euro, TVAC et pour une journée de 8h. Prix profil Testeur (40 points) Le critère « Prix » est pondéré de la façon suivante :

où :

Proffre = prix de l'offre, Prmin = le prix de l’offre la moins chère dans les offres régulières. P1 = points attribués au critère Prix profil « Testeur »

Les prix sont exprimés TVAC. Prix profil Spécialiste en test tools (20 points) Le critère « Prix » est pondéré de la façon suivante :

où :

Proffre = prix de l'offre, Prmin = le prix de l’offre la moins chère dans les offres régulières. P2 = points attribués au critère Prix profil « spécialiste en test tools »

Les prix sont exprimés TVAC. Prix profil Spécialiste en méthodologie de test (20 points) Le critère « Prix » est pondéré de la façon suivante :

offre P2

Pr

min Pr 20 x

offre P1

Pr

min Pr 40 x


où :

Proffre = prix de l'offre, Prmin = le prix de l’offre la moins chère dans les offres régulières. P3 = points attribués au critère Prix profil « spécialiste en méthodologie de test »

Les prix sont exprimés TVAC. Prix profil Quality Assurance Coordinator (20 points) Le critère « Prix » est pondéré de la façon suivante :

où :

Proffre = prix de l'offre, Prmin = le prix de l’offre la moins chère dans les offres régulières. P4 = points attribués au critère Prix profil « Quality Assurance Coordinator »

Les prix sont exprimés TVAC. Critère 2 Partenariat – garantie d’expertise concernant nos standards (10 points) Sans exclure les candidats ne possédant pas de partenariat mais afin de donner une garantie supplémentaire au SPF Finances sur l’expertise apportée par le soumissionnaire, il est demandé de fournir une preuve et le niveau de partenariat portant sur les softwares standards suivants utilisés au SPF finances suivants:

HP ALM HP UFT HP Performance Center HP Fortify Cast

Il existe différents niveaux de partenariat sur les softwares HP : silver, gold et platinium. (1) La firme possède un partenariat pour les 4 softwares HP de type :

Silver : 5 points Gold : 7 points Platinium : 10 points

(2) La firme possède un partenariat avec Cast software : 2 points La cote finale pour ce critère est égale à la somme du partenariat HP et du partenariat Cast, ramenée à 10 points (donc x 10/12). Cotation :

Partenariat HP (1) 0 point

5 points

7 points

10 points

Partenariat CAST (2) 0 point

2 points

Total (1) + (2)

offre P4

Pr

min Pr 20 x

offre P3

Pr

min Pr 20 x


C5.3.3. Cote finale

Par lot, la cote finale est attribuée à chaque offre en additionnant les points obtenus pour les 2 critères susmentionnés.


D. EXÉCUTION

D1. Fonctionnaire dirigeant. Pour chaque lot qui sera conclu sur base du présent marché, le fonctionnaire dans le sens de l’article 11 de l’arrêté royal du 14 janvier 2013 – arrêté royal établissant les règles générales d’exécution des marchés publics et des concessions de travaux publics – sera désigné dans la notification de la conclusion du marché. Seul le fonctionnaire dirigeant est compétent pour la surveillance du marché ainsi que pour son contrôle. Le fonctionnaire dirigeant qui sera un fonctionnaire du Pouvoir Adjudicateur sera désigné dans la notification de la conclusion du marché. Les limites de ses compétences y seront indiquées. Le fonctionnaire dirigeant peut déléguer une partie de ses compétences.

D2. Révision de prix. 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 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é ;

o 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 prestations effectivement prestées après la date visée ci-dessus (attention : l’adjudicataire doit introduire une nouvelle demande pour la révision des prix des prestations à prester après l'anniversaire suivant).

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

2.0*8,0*

0

0S

SPP

où : P = prix revu P0 = prix initial


S0 = indice salarial AGORIA (seulement pour les prestataires belges ; les prestataires étrangers doivent proposer un indice analogue) - moyenne nationale, charges sociales comprises, valable le mois qui précède l'ouverture des offres. S = comme S0 ci-dessus, mais valable le mois qui précède le jour anniversaire de la notification de l'attribution du marché.

Pour les indices, voir : http://www.agoria.be

Le pouvoir adjudicateur se réserve le droit de réviser les prix en cas d’indice

décroissant. Dans ce cas, la révision suit les règles ci-dessus, sauf que la lettre recommandée émane du pouvoir adjudicateur.

D3. Responsabilité du prestataire de services. L’adjudicataire assume la pleine responsabilité des fautes et manquements commis dans le cadre des prestations de services. Le pouvoir adjudicateur n’est en aucun cas responsable des dommages causés à des personnes ou à des 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 et notamment aux membres de l’Administration à cet égard. Par ailleurs, le prestataire de services garantit le pouvoir adjudicateur des dommages et intérêts dont celui-ci est redevable à des tiers du fait du retard dans l’exécution des services ou de la défaillance du prestataire de services. Toute dégradation ou vol résultant d’un abandon ou d’une négligence, fût-ce consécutif aux intempéries ou à d’autres risques sera de la responsabilité de l’adjudicataire.

D4. 4 Réception des services prestés

D4.1. La livraison et l’installation

L’adjudicataire doit mettre à la disposition du SPF Finances tous les renseignements et facilités nécessaires pour le contrôle de la préparation et de l’exécution des prestations.

D4.2. Spécifications techniques

Les services doivent correspondre sous tous rapports avec les plans, documents et thèmes applicables à ce marché. Même à défaut de spécification technique contractuelle, les services doivent être conformes à toutes les exigences et règles de bonne exécution.

D4.3. Suivi de la bonne exécution des livraisons et des services

Le SPF Finances a le droit d’exercer une surveillance permanente sur les services réalisés par l’équipe chargée de l’exécution du marché. L’équipe chargée de l’exécution doit remettre

http://www.agoria.be/


aux représentants du pouvoir adjudicateur tous les renseignements et facilités nécessaires à l’accomplissement des tâches de supervision. Les plans, spécifications, dossiers, etc, établis dans le cadre de ce marché par le personnel des adjudicataires, y compris les normes appliquées, doivent être approuvés avant l’exécution par le pouvoir adjudicateur. Le SPF Finances dispose d’un délai de 15 jours calendrier pour approuver ces documents ou pour formuler des remarques. En cas de remarques, les documents concernés doivent être adéquatement corrigés avant l’exécution, sans que les corrections n’entraînent la révision du délai d’exécution prévu, sauf si les remarques résultent d’une nouvelle exigence de la part du pouvoir adjudicateur. Tout dépassement du délai d’acceptation d’un document entraîne, à la demande de l’adjudicataire concerné, la prolongation du délai d’exécution. Le fait qu’un retard soit imputable au SPF Finances ne dispense pas l’adjudicataire de veiller à limiter les conséquences du retard. L’adjudicataire ne peut invoquer ce contrôle pour se soustraire à sa responsabilité lorsque les services sont refusés en raison de défauts de nature quelconque et qu’il en résulte une prolongation du délai d’exécution. Si, pendant l’exécution des services, des anomalies sont constatées, elles seront immédiatement signalées à l’adjudicataire par fax ou e-mail confirmé ensuite par lettre recommandée. Dans ce cas, l’adjudicataire est tenu de recommencer les services non conformes. Au terme de l’exécution des services, on procédera à l’évaluation de leur qualité et de leur conformité. Ensuite, un procès-verbal sera rédigé, dont l’original sera remis au prestataire de services. Les services inadéquats ou non conformes devront être recommencés.

Pour l’évaluation des services prestés et le suivi du projet, le pouvoir adjudicateur peut faire appel à une tierce partie. L’adjudicataire est tenu de collaborer avec ce tiers et de lui fournir toute l’information nécessaire au bon accomplissement des opérations de contrôle. Dans ce cadre, le SPF Finances souhaite mettre l’offre de l’adjudicataire à la disposition de collaborateurs internes et externes du SPF Finances chargés de l’évaluation et du contrôle des services. Le soumissionnaire doit indiquer clairement les parties de son offre qui ne peuvent être mises à la disposition de personnes étrangères au SPF Finances chargées de l’évaluation et du contrôle des services.

D4.4. Contrôle et encadrement du marché

Dans les 30 jours suivant l’annonce de leur achèvement par l’adjudicataire, le SPF Finances commencera un contrôle complet des éléments constitutifs de chaque commande. Les contrôles porteront sur l’adéquation et le bon fonctionnement de l’application. Le contrôle de l’adéquation a pour but de vérifier que les applications sont conformes aux spécifications imposées par le SPF Finances. Le contrôle du bon fonctionnement a pour but de vérifier que les services livrés peuvent fonctionner correctement dans des conditions normales (autrement dit, que les installations sont aptes aux services préalablement définis). Les opérations de contrôle concernent notamment :


- La bonne exécution des services correspondants ; - L’opérationnalité et la programmation de toutes les fonctions ; - La capacité en termes de performances, de sécurité, de robustesse, de charge… - Au besoin, des outils de test sont installés pour pouvoir effectuer ces contrôles ; - La fourniture de la documentation.

Les contrôles sont considérés comme fructueux lorsque les composants fournis passent les tests avec succès dans les délais impartis. Les tests et leur calendrier sont définis de commun accord et doivent être compatibles avec le lot testing.. Si les opérations de contrôle révèlent que les performances et/ou les fonctionnalités ne répondent pas ou répondent seulement partiellement à ce qui est demandé dans ce cahier spécial des charges et/ou annoncé dans l’offre et les éventuels documents complémentaires, l’adjudicataire s’engage à apporter à ses frais les corrections ou modifications nécessaires, ou à remplacer tout ou partie des délivrables par une livraison conforme, dans les 30 jours calendrier suivant la date du procès-verbal constatant l’impossibilité de procéder à la réception provisoire. Passé ce délai, le SPF Finances se réserve le droit d’appliquer les amendes de retard. Dans cette éventualité, tous les tests de réception doivent être recommencés, après que l’adjudicataire a apporté les modifications, compléments ou remplacements nécessaires. Concrètement, dans le cas où les tests fonctionnels d’une application détectent des anomalies de fonctionnement ou des éléments non-conformes à l’analyse fonctionnelle, les modifications devront y être apportées aux frais de l’adjudicataire et retestées par les testeurs et utilisateurs finaux (acceptance métier). Dans le cas où ces modifications ont un impact sur un projet qui a fait l’objet d’une livraison intermédiaire antérieure, les modifications devront y être apportées aux frais de l'adjudicataire avant que le SPF Finances accepte la livraison intermédiaire de cette application. Si les contrôles ne peuvent être menés à bien avec fruit dans les délais impartis, le SPF Finances peut :

- appliquer les mesures d’office prévues à l’article 47 de l’A.R. du 14 janvier 2013, qui définit les règles générales d’exécution des marchés publics et des concessions de travaux publics ;

- ou prendre des dispositions particulières avec l’adjudicataire.

D4.5. Réception provisoire

Contrôle et réception des services Chaque projet dans un lot est considéré comme un marché distinct en vue de l’exécution et de la réception. Chaque projet dans un lot fait l’objet d’une réception provisoire. Le prestataire de services assume la pleine responsabilité des fautes et manquements présentés dans les services fournis, en particulier dans les études, les comptes, les plans ou dans toutes les autres pièces déposées par lui en exécution du marché. Les prestations qui ne satisfont pas aux clauses et conditions du marché ou qui n'ont pas été fournies conformément aux règles de l'art sont recommencés par le prestataire. Les services qui font l’objet de chaque marché sont soumis à des contrôles afin d’établir s’ils répondent aux prescriptions des documents du marché. Le pouvoir adjudicateur dispose d'un délai de vérification de 30 jours à compter de la date de la fin des services par projet, constatée conformément aux modalités fixées dans les


documents du marché, pour procéder au contrôle et aux formalités de réception provisoire et en notifier le résultat au prestataire de services. À l’expiration de ce délai de 30 jours à compter du jour où a été constaté l’achèvement de l’ensemble des services par lot, un procès-verbal de réception ou de refus de réception du marché, selon le cas, est établi. Si la fin des services intervient avant ou après cette date, c’est au prestataire de services d’en informer le fonctionnaire dirigeant par courrier recommandé et de lui demander à cette occasion de procéder à la réception. Dans les 30 jours à compter de la réception de la demande des prestataires de services, un procès-verbal de réception ou de refus de réception est établi selon le cas.

D4.6. Garantie Le nombre d’années proposées pour la garantie est minimum 1 an et court à compter de la réception provisoire. Durant la période de garantie, tout comportement imprévu ou qui ne correspond pas à la description dans le document d’Analyse fonctionnelle devra être corrigé dans les délais prévus. La responsabilité de l’adjudicataire est engagée aussi bien pour le comportement du système informatique, que ce qui concerne le contenu de(s) base(s) de données et leur cohérence.

D4.7. Réception définitive

La réception définitive est déclarée à la demande du fournisseur, après échéance de la date de la garantie de la dernière prestation exécutée, pourvu que le SPF Finances n’ait pas formulé de plaintes concernant le bon fonctionnement pendant cette période. La réception définitive sera consignée dans un procès-verbal signé par l’adjudicataire et le SPF Finances. Le SPF Finances dispose d’un délai de 30 jours à compter de la demande de l’adjudicataire pour rédiger le procès-verbal d’acceptation qui autorise la réception.

D4.8. Frais de réception

Tous les frais de réception, y compris les éventuels frais de déplacement et de séjour des délégués du pouvoir adjudicateur, sont à la charge de l’adjudicataire.

D5. Cautionnement

Cautionnement En application de l’article 9, paragraphes 2 et 3 de l’AR du 14 janvier 2013, l’attention des soumissionnaires est attirée sur le fait que, dans le présent cahier spécial des charges, il a été dérogé à l'article 25 de l’arrêté royal du 14 janvier 2013 relatif au cautionnement et plus particulièrement pour ce qui concerne l’adaptation du montant du cautionnement compte tenu de l’impossibilité de déterminer avec certitude le montant du marché au moment de son attribution et compte tenu du poids administratif excessif qu’impliquerait une adaptation de ce cautionnement en fonction des commandes potentiellement nombreuses adressées par le pouvoir adjudicateur.

D5.1. Constitution du cautionnement

Le cautionnement s’élève à un montant de 50.000 euros, TVA comprise.


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 législation relative au statut et au contrôle des établissements de crédit ou par une entreprise d'assurances satisfaisant au prescrit de la législation relative au contrôle des entreprises d'assurances et agréée pour la branche 15 (cautionnement). L’adjudicataire doit, dans les trente jours civils 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 bpost

banque de la Caisse des Dépôts et Consignations [compte bpost banque n° BE58 6792 0040 9979 (IBAN), PCHQBEBB (BIC)] 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 de sa gestionnaire

des titres 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, par 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’engagement 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’établissement 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 solidaire 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 des documents du marché, 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 son compte, avec la mention « bailleur de fonds » ou « mandataire », suivant le cas.


Le délai de trente jours 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és et les jours de repos compensatoires prévus par voie réglementaire ou dans une convention collective de travail rendue obligatoire. La preuve du cautionnement doit être envoyée à l’adresse suivante :

D5.2. Libération du cautionnement

Le cautionnement sera libéré en une fois après la réception définitive de ce marché.

D6. Conditions de l’exécution

D6.1. Clause d’exécution

Le soumissionnaire s’engage, jusqu’à la complète exécution du marché, à respecter les 8 conventions de base de l’OIT, en particulier: 1. l’interdiction du travail forcé (conventions n° 29 concernant le travail forcé ou obligatoire,

1930, et n° 105 sur l’abolition du travail forcé, 1957)

2. le droit à la liberté syndicale (convention n° 87 sur la liberté syndicale et la protection du droit syndical, 1948)

3. le droit d’organisation et de négociation collective (convention n° 98 sur le droit d’organisation et de négociation collective, 1949)

4. l’interdiction de toute discrimination en matière de travail et de rémunération (conventions n° 100 sur l’égalité de rémunération, 1951 et n° 111 concernant la discrimination (emploi et profession), 1958)

5. l’âge minimum fixé pour le travail des enfants (convention n° 138 sur l’âge minimum, 1973), ainsi que l’interdiction des pires formes du travail des enfants (convention n° 182 sur les pires formes du travail des enfants, 1999).

En vertu de l’article 44, § 1er, 1° de l’arrêté royal du 14 janvier 2013, le non-respect de cet engagement sera considéré comme une non-exécution du marché suivant les prescriptions fixées dans les documents du marché, ce qui donnera lieu à la mise en demeure de l’adjudicataire, et pourra, en vertu de l’article 47, § 2 de l’arrêté royal du 14 janvier 2013, donner lieu à l’application des mesures d’office, en particulier à la résiliation unilatérale du marché.

Service public fédéral FINANCES

Division Engagements à l’attention de Madame MALJEAN Françoise NOGA B22

Boulevard Roi Albert II, 33 boîte 781 – Bloc B22 1030 BRUXELLES


D6.2. Clause d’évolution technologique

Si, avant l'expiration du délai de livraison, une évolution technologique donne naissance à des livrables 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.

D6.3. Lieu d’exécution du marché et particularités

L’exécution des services

L'exécution du marché se déroulera principalement dans les locaux du SPF Finances - Service d'Encadrement ICT, North Galaxy, Avenue Roi Albert II 33, 1030 Bruxelles. Si, au cours de certaines périodes, il fallait travailler en d’autres lieux, les frais de déplacement ne seraient 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 moyennant l’accord préalable du SPF Finances.

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 du SPF Finances, entre 7h00 et 19h00 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 à l’adjudicataire chaque année.

D6.4. Personnel de l’adjudicateur

D6.4.1. Généralités.

IMPORTANT Le prestataire doit être en mesure de justifier à tout moment que son personnel est en règle avec la réglementation belge du Travail. A cette fin, avant le début du chantier, le prestataire fournira au fonctionnaire dirigeant ou à son délégué, une copie: - la dimona/limosa (selon le cas) - le contrat de travail, - le certificat de bonnes vie et mœurs ; - la carte d’identité/le permis de travail (selon le cas).

Pour chacune des commandes basées sur ce marché, l’adjudicataire devra désigner un chef de projet (également décrit, dans le cadre de PMfin1, comme le « coordinateur de projet externe ») qui le représentera dans ses rapports avec le SPF Finances.

1 une méthodologie de projet unique au sein du SPF Finances qui est basée sur la méthode internationalement

reconnue Prince2


Le personnel de l’adjudicataire qui sera amené à réaliser le marché devra :

disposer de l’expérience nécessaire dans le cadre de la solution proposée ou de solutions comparables ;

être en mesure de comprendre tous les textes, comptes rendus, résumés, etc. nécessaires qui sont 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.

être à même d’assister aux réunions et de suivre les discussions à la fois en néerlandais et en français.

Disposer d'une connaissance orale et écrite suffisante pour pouvoir communiquer en français ou en néerlandais et, si possible, en passant d’une langue à l’autre ;

Le responsable de projet doit par ailleurs :

pouvoir communiquer couramment en français et en néerlandais. Le service d’assistance (helpdesk) 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 en général 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 la matière.

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 de niveau suffisant des outils utilisés dans le cadre du projet. Les adjudicataires doivent être en mesure de répondre immédiatement aux besoins qui apparaîtront à la suite de l'attribution du marché. L’équipe de projet mise à disposition par l’adjudicataire doit être suffisante pour mener à bien les tâches qui lui sont confiées.

Le personnel engagé pour l’exécution du marché doit être le même que le personnel proposé dans l’offre. Le cas échéant, le personnel mis à disposition pour l’exécution sera de niveau et d’expérience équivalents. Le SPF Finances devra donner son accord quant à la composition de l'équipe proposée dans le cadre du projet.

L’adjudicataire garantit, pendant 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. En cas de changement dans l’équipe, la firme s’engage à suivre les principes suivant :

- Tout départ d’une personne effectivement occupée sur un projet doit être notifié par écrit au SPF Finances (le coordinateur ICT, le responsable du département ICT Development, le gestionnaire de contrat) dés connaissance du départ et s’assurer que les personnes informées ont accusé réception de l’information. En l’absence de notification dans les temps, une pénalité est applicable de plein droit. Cette personne doit être remplacée par un profil au moins équivalent en termes de qualité et de compétences à celui du membre qui quitte l’équipe.


- Une pénalité est applicable de plein droit si aucun profil n’est jugé satisfaisant.

- La firme met à disposition la personne au plus tard 1 mois avant le départ en cas de préavis. La firme met à disposition la personne au plus tard 1 mois après le départ si un préavis n’a pas été presté. En l’absence d’engagement dans les délais, une pénalité est applicable de plein droit par mois de retard accompli.

- La firme prévoit un transfert de connaissance à ses frais entre le membre qui quitte l’équipe et un autre membre de l’équipe (éventuellement le nouvel engagé). La firme doit démontrer que le transfert de connaissance a été réellement effectué par des feuilles de prestations et des documents échangés. Des pénalités sont dues de plein droit en cas de non-respect de cette disposition.

- La firme s’engage à faire en sorte que le nouveau membre de l’équipe soit immédiatement productif et efficace. A ce propos, aucune prestation ne doit être prévue pour un quelconque intake relativement aux projets. Des pénalités sont dues de plein droit en cas de non-respect de cette disposition.

L'adjudicataire remplace immédiatement les membres du personnel qui lui sont signalés par le pouvoir adjudicateur comme compromettant la bonne exécution du marché par leur incapacité, leur mauvaise volonté ou leur inconduite notoire (article 16 Arrêté royal du 14 janvier 2013).

Dans ce cas, le changement devra intervenir dans les 10 jours ouvrables de la demande du SPF Finances, et ce sans frais à dater de la notification de l’incident au soumissionnaire.

D6.5. Sous-traitants

Le fait que l'adjudicataire confie tout ou partie de ses engagements à des sous-traitants ne dégage pas sa responsabilité envers le pouvoir adjudicateur. Le pouvoir adjudicateur n'a aucun lien contractuel avec ces tiers. Toutefois, le pouvoir adjudicateur exige que les sous-traitants de l'adjudicataire satisfassent en proportion de leur participation au marché aux exigences minimales de capacité financière et économique et de capacité technique et professionnelle imposées par les documents du marché. L'adjudicataire reste, dans tous les cas, seul responsable vis-à-vis du pouvoir adjudicateur. Dans les cas suivants, l'adjudicataire a l'obligation de faire appel à certains sous-traitants, le recours à d'autres sous-traitants étant soumis à l'autorisation du pouvoir adjudicateur :

1. lorsque l'adjudicataire a, pour sa sélection qualitative, utilisé la capacité de certains sous-traitants conformément à l'article 74 de l'arrêté royal secteurs classiques ;

2. lorsque l'adjudicataire a proposé certains sous-traitants dans son offre conformément

à l'article 12 de l'arrêté royal secteurs classiques.


En cas de changement de sous-traitant pour l’offre, l’adjudicataire en informera le SPF Finances, qui devra donner son accord avant que l'adjudicataire ne puisse procéder à ce changement.

Il est interdit à l'adjudicataire de confier tout ou partie de ses engagements à un entrepreneur, à un fournisseur ou à un prestataire de services qui se trouve dans un des cas visés à l'article 61 de l'arrêté royal secteurs classiques.

D6.6. Moyens mis à disposition par le SPF Finances Moyens techniques L’adjudicataire mettra à disposition de son personnel tout le matériel nécessaire à l’exécution de sa mission (ordinateur portable, etc.). Le personnel de l’adjudicataire dispose d’un accès limité au réseau du SPF Finances, ainsi que d’une adresse e-mail. Le SPF Finances ne dispose pas d’emplacements de parking pour le personnel de l’adjudicataire. Le SPF Finances n'effectuera aucune adaptation aux postes de travail des membres du personnel de l'adjudicataire afin de les faire mieux fonctionner au sein de l'infrastructure du SPF Finances. L'adjudicataire ne peut en aucun cas modifier, perturber ou surcharger l'infrastructure du SPF Finances par l'ajout de postes de travail pour son personnel dans cette infrastructure, sauf pour ce qui est directement associé au développement de l'application concernée. L'adjudicataire est intégralement responsable de la protection des postes de travail concernés contre les virus et de la gestion de ces postes. Il utilisera de manière prioritaire les outils mis à sa disposition par le SPF Finances. Au cas où d'autres logiciels devraient être utilisés dans le cadre du marché, 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écrits dans le point « Moyens d’actions de l’administration – Litiges » avant de faire appel au droit. Tâches des collaborateurs du SPF Finances Les collaborateurs du SPF Finances participent aux travaux liés à la maintenance d’une application donnée pour ce qui concerne :

la définition du contenu ;

la participation au choix de solutions : architecture, etc. ;

la validation des documents de réalisation : dossiers de spécification, dossiers de réalisation, dossiers d’acceptation, dossier de tests, manuels d’utilisation, manuels de maintenance, etc. ;

les contrôles de la qualité, notamment le contrôle de la concordance de la documentation avec la réalisation, du respect des normes en matière de documentation et de programmation, etc. ;


le cas échéant : la participation obligatoire aux tests de réception (aspects techniques et fonctionnels), indépendamment du fait qu’il s’agisse de tests de fonctionnement unitaires, de tests d’intégration ou de tests concernant le fonctionnement général ;

le support logistique aux équipes d’exécution, en ce qui concerne la mise à disposition des moyens techniques nécessaires à la réalisation selon ce qui sera déterminé en concertation.

La réalisation sera suivie de très près, étape après étape, par les collaborateurs du SPF Finances, qui, avec l’aide nécessaire de l’adjudicataire, seront chargés de contrôler (et, si nécessaire, de définir) les normes et standards sur le plan (où cela s’applique) de l’architecture, des règles d’application, des procédures de travail, de la documentation, de la programmation, etc. Ils doivent également veiller à ce que les normes soient strictement respectées, de façon à ce que les solutions implémentées puissent ensuite être reprises dans leur intégralité et sans problème spécifique par le SPF Finances. D6.7. Engagements particuliers pour le prestataire de services D6.7.1. Confidentialité et engagements particuliers concernant les informations reçues Tous les résultats et rapports produits par l’adjudicataire pendant l'exécution de ce marché, constituent la propriété du pouvoir adjudicateur et ne peuvent être publiés ou communiqués à des tiers, sauf accord écrit préalable de la part du pouvoir adjudicateur. L'exécutant des services et ses collaborateurs sont tenus au secret professionnel quant aux informations qu'ils auraient pu obtenir lors de l'exécution de ce marché. Ces informations ne pourront en aucun cas être communiquées à des tiers sans accord écrit de la part du pouvoir adjudicateur. 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 dont il s’agit:

peuvent être enregistrées sur n'importe quel type de support d'information, comme le papier, un film, une bande magnétique, un disque, une disquette, un montage intégré, etc. ;

peuvent être communiquées à l’adjudicataire oralement, par une démonstration et/ou par la transmission d'un support d'information qui contient l'information considérée ou peuvent venir à la connaissance de l’adjudicataire à l'occasion de l'exécution du présent marché ou d'une mission confiée par le SPF Finances dans le cadre du présent marché ;

peuvent, dans leur totalité ou en partie, consister en, par exemple, études, modes d'emploi, plans de conception, plans de fabrication, descriptions techniques, plans de détail, spécifications fonctionnelles, procédures, programmes d'ordinateur, codes exécutables, calculs, etc.

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 garantit que son personnel et ses sous-traitants respecteront la confidentialité des informations. 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 s’appliquent pas 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. L’adjudicataire est tenu d’effacer de ses propres supports toutes copies d’informations devenues inutiles dans le cadre de sa mission. Toute information du SPF Finances restera la propriété du SPF Finances. Par la mise à disposition d’informations du SPF Finances, celui-ci ne concède à l’adjudicataire, ni explicitement ni implicitement, aucun droit à licence sur les droits de brevet, droits d’auteur ou autres droits intellectuels. L’adjudicataire s'engage à ne pas appliquer industriellement l'information du SPF Finances et à ne pas l'utiliser pour d'autres fins que l'exécution du présent marché ou d'une mission à lui confiée par le SPF Finances dans le cadre du présent marché. L’adjudicataire et ses éventuels sous-traitants s’engagent également à signaler le plus rapidement possible toute faille ou tout risque qui pourrait nuire à la sécurité ou la confidentialité. 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.


D6.7.2 Propriété Les études, architectures et développements éventuellement produits par les membres du personnel de l’adjudicataire, la documentation correspondante, et en général tout document directement ou indirectement généré par le personnel de l’adjudicataire pendant l’exécution du présent contrat, ainsi que les droits de propriété intellectuelle y afférents, deviennent, à leur naissance, la propriété du SPF Finances. Il est interdit au personnel de l’adjudicataire d’emporter des documents appartenant au SPF Finances, sauf si les nécessités de la tâche l’imposent, notamment dans les déplacements entre les différents sites du SPF Finances. D6.7.3. Transférabilité L’adjudicataire remettra à un tiers agréé par le SPF Finances ou au SPF Finances toutes les informations nécessaires afin que le SPF Finances puisse effectuer toutes les opérations nécessaires au bon fonctionnement ou à l'évolution de la solution ou pour en confier l'exécution à un tiers si l'adjudicataire ou un de ses sous-traitants reste en défaut (cessation de ses activités ou rupture du contrat). À la fin du contrat, que ce soit par expiration ou rupture, l'adjudicataire prêtera son concours au SPF Finances afin que celui-ci ou un tiers puisse poursuivre sans difficulté les prestations exécutées dans le cadre du contrat. À partir du début de la période de transférabilité, l'adjudicataire s'engage à restituer au SPF Finances tous les éléments nécessaires à la production de l'informatique et tous les documents appartenant au SPF Finances. Les méthodes et procédures instaurées durant les prestations sont la propriété du SPF Finances. C’est pourquoi, en cas de rupture, l'adjudicataire soumettra au SPF Finances un plan de transition indiquant en détail les dispositions et conditions en relation avec les tâches à réaliser pour fournir les informations requises en vue de garantir la transition, avec un calendrier de ces tâches. L'adjudicataire s'engage à faire établir ce plan de transition par des personnes faisant partie de l'équipe chargée du contrat, sans supplément de frais pour le SPF Finances. Le SPF Finances est le seul propriétaire intellectuel des solutions développées dans le cadre de ce projet. Toutes les opérations en relation avec la transférabilité incombent à l'adjudicataire. Il s'agit notamment de :

la mise à disposition de toutes les procédures nécessaires à la gestion du système livré ;

la mise à disposition de documents de synthèse, bilans et autres rapports de réunion constituant le dossier de suivi ;

la formation et l'information des représentants du nouveau fournisseur ;

le transfert des données.


D8. Facturation et paiement. Les paiements ne peuvent être effectués qu’à posteriori, pour services déjà livrés et acceptés. 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, la procédure est la suivante : La facture doit être libellée en euros. Les factures sont revêtues de la mention : « Le montant dû doit être versé sur le compte nº… au nom de…à… ». L'adjudicataire envoie ses factures (en un exemplaire) à l'adresse suivante :

Service Public Fédéral FINANCES Service central de facturation Boulevard Roi Albert II, 33 bte 788 – Tour B22 1030 BRUXELLES

La facture peut être envoyée aussi, sous forme d’un fichier pdf, à l’adresse e-mail suivante : [email protected] Le paiement s’effectuera conformément au Règlement sur la Comptabilité de l’État. Seuls les services exécutés de manière correcte pourront être facturés. Le pouvoir adjudicateur dispose d'un délai de vérification de trente jours à compter de la date de la fin des services, constatée conformément aux modalités fixées dans les documents du marché, pour procéder aux formalités de réception provisoire et en notifier le résultat au prestataire de services. Le paiement du montant dû au prestataire de services doit intervenir dans le délai de paiement de trente jours à compter de l'échéance du délai de vérification. Lorsque les documents du marché ne prévoient pas une déclaration de créance séparée, la facture vaut déclaration de créance. La facture doit être libellée en euros.

D9. Litiges. Les moyens d'action du SPF Finances sont ceux prévus aux articles 44 et suivants de l’arrêté royal du 14 janvier 2013. Le marché doit être élaboré, conçu 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 résultant des dispositions qui régissent le marché doivent être réglés en concertation.



Avant de recourir à d’autres moyens, les parties doivent tenter de régler l’affaire à l’amiable. À cette fin, la partie la plus diligente notifiera à l’autre partie la mauvaise exécution du contrat par simple lettre recommandée. Si possible, cette notification s’accompagnera d’une proposition de solution. L’autre partie dispose d’un délai de 15 jours à compter de l’envoi de la lettre recommandée pour en confirmer la réception et accepter la solution proposée.

Faute d’accord et avant de faire valoir leurs droits en justice, les parties tenteront de trouver un compromis par la voie de négociations qui seront engagées dès qu’il apparaîtra que l’affaire ne peut être réglée à l’amiable. Les négociations se tiendront à une adresse déterminée 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 calendriers, à compter de la première lettre recommandée.

Tous les litiges relatifs à l’exécution du présent 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 dommages causés à des personnes ou à des biens qui sont la conséquence directe ou indirecte des activités nécessaires à l’exécution du présent marché. Le prestataire de services garantit le pouvoir adjudicateur contre toute action en dommages et intérêts par des tiers à cet égard.

D10. Amendes et Pénalités.

En application de l’article 9, paragraphe 4 de l’AR du 14 janvier 2013, l’attention des soumissionnaires est attirée sur le fait que, dans le présent cahier spécial des charges, il a été dérogé à l’article 154 de l’arrêté royal du 14 janvier 2013 relatif aux amendes en raison de l’importance accordée par le Service Public Fédéral FINANCES à la mise en production dans les délais impératifs fixés dans chaque commande.

D10.1. Pénalités

Tout service non presté dans le cadre de l’offre proposée donne lieu à une pénalité forfaitaire de 1.250,00 EUR.

D10.2. Amendes

Pour tout service non exécuté dans les délais imposés par le pouvoir adjudicateur, par infraction à ces délais et par jour de calendrier de retard, une amende forfaitaire de 1.250,00 EUR sera appliquée de plein droit pour non-exécution. Les amendes s’appliquent de plein droit sans formalité ni avis quelconque.


D10.3. Imputation des amendes et pénalités

D10.3.1. Amendes et sanctions Le non-respect d’un élément du SLA est sanctionné par une pénalité fixée à l'annexe 5. « Tableau KPI ». 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. Les pénalités peuvent être infligées aux prestataires si le SPF Finances constate le non-respect des engagements et obligations de résultats.

IMPORTANT

Le montant des dédommagements dus par le prestataire en cas de non-respect de son SLA est repris expressément sur la facture et déduit du montant à payer par le pouvoir adjudicateur.


E. PRESCRIPTIONS TECHNIQUES

E.1. Introduction Dans le cadre de la réforme Coperfin, le SPF Finances a entrepris la transposition de ses applications, à l’origine écrites en COBOL et déployées sur divers mainframes, vers des environnements modernes et conformes aux standards techniques actuels. Le langage et la technologie Java constituent la pierre angulaire de cette stratégie. Cette migration est à l’heure actuelle très avancée. Les applications du SPF Finances, qui sont opérationnelles à quelques exceptions près (« en production »), sont les applications cibles du présent cahier spécial des charges. Le soumissionnaire est invité à consulter le site Internet (http://finances.belgium.be/fr) pour se faire une idée du contexte du projet. Dans ce cadre, et en vue de réaliser ses missions avec toujours plus d’efficacité et d’efficience, le SPF Finances, souhaite donc mettre en concurrence la maintenance de ses applications afin d’assurer leur évolution et leur pérennité tout en améliorant leur qualité et en optimisant l’utilisation des ressources nécessaires à leur fonctionnement. Le SPF Finances se doit d’utiliser le plus efficacement possible les ressources publiques qui sont mises à sa disposition dans le cadre de l’exercice de sa mission. Ainsi, le SPF Finances souhaite renforcer ses équipes de maintenance et de développement avec des équipes et profils externes (task manager, technical architect, business analyst, junior JEE-technology developer et senior JEE-technology developer). Dans la même logique, le SPF Finances souhaite également renforcer son équipe de tests avec une équipe externe combinant différents profils (testeur, spécialiste en test tools, expert en méthodologie de tests et quality assurance coordinator). Le marché est subdivisé en 6 lots :

lot 1: entretien (spécifique) de Zacheus, e-Notariat, Finprof, e-Deduction (SAFS CV), Avis de saisie (FCA)

lot 2: entretien (spécifique) de Stipad

lot 3: entretien (spécifique) de FSP, Pandora, Cautionnements solidaires (SP10A), Faillites (SP10B), Grootboek/Grand Livre, CDC Dmat...

lot 4: entretien (général)

lot 5: nouveaux développements (en général), y compris redéveloppement significatif d’applications existantes

lot 6: testing (général) : tests fonctionnels et tests techniques spécifiques (charge et performance).

http://finances.belgium.be/fr/


Le SPF Finances estime que la réalisation des activités de développement dans le cadre de lots 1 à 5 « entretiens et développements » est inconciliable avec la réalisation des activités de test dans le cadre du lot 6 « tests ». La séparation de ces activités constitue une condition indispensable à la réalisation des objectifs en matière d’amélioration de qualité tels que décrits dans le présent document. En conséquence, il est précisé que lors de l’attribution du lot 6, le soumissionnaire qui remporterait l’un des cinq premiers lots sera d’office écarté pour l’attribution du lot 6 sauf si le soumissionnaire a choisi le lot 6 comme premier choix dans son ordre de préférence via le formulaire d’offre. Dans ce cas, en cas d’acquisition effective de ce lot 6, le soumissionnaire sera exclu de l’attribution des lots 1 à 5. La même logique d’exclusion de l’attribution s’applique entre les « lots entretiens spécifiques 1, 2 et 3 », le « lot 4 entretien (général) » et le « lot 5 nouveaux développements ». Un même soumissionnaire ne peut acquérir qu’« un ou plusieurs lots d’entretiens spécifiques » ou le « lot 4 entretien » ou le « lot 5 développement ». Ces règles d’exclusion s’appliquent également à :

tout soumissionnaire qui agit comme membre d’une association sans personnalité juridique constituée pour l’exécution de ce marché ;

tout sous-traitant d’un des soumissionnaires pour l’exécution de ce marché. Le SPF Finances attribuera d’abord les lots d’entretien spécifique 1, 2 et 3 ; suivront le lot 4 « entretien », puis le lot 5 « nouveaux développements » et enfin le lot 6 « testing ». À noter que les associations sans personnalité juridique sont autorisées dans le cadre du présent marché. Chacun des membres d’une telle association étant responsable solidairement pour l’exécution du lot. Chaque membre de l’association verra son droit d’accès contrôlé, sa capacité économique et financière évaluée et sa capacité technique validée (voir points « C.5.1.1. Contrôle d’accès » et « C.5.1.2. Sélection qualitative » de la partie « C. Adjudication » de cette offre). Pour rappel, le SPF Finances n’est pas tenu de commander la maintenance annuelle prévue au présent cahier. Les obligations, décrites au présent cahier spécial des charges, pour une période donnée découleront du bon de commande préalablement transmis à l’adjudicataire. À noter également le strict découplage entre l’octroi des composantes «Développement/support» et « testing ». L’émission d’un bon de commande pour la première n’implique donc aucunement une commande pour la seconde, et inversement.

IMPORTANT L’adjudicataire garantit que tous les services qui devront être exécutés dans le cadre ce marché seront exécutés, par un personnel suffisamment formé et compétent, en respectant


les délais et budget prévus. Aucun dépassement de délai ou de budget ne sera accepté. L’adjudicataire a donc une obligation de résultat.

E.2. Contexte et principes généraux du marché En introduisant une offre, le soumissionnaire déclare avoir pris connaissance des contexte et principes suivants, et en tenir compte dans l’exécution de tous les marchés qui lui sont attribués dans le cadre de ces charges. L’adjudicataire devra tenir compte de ces principes dans la pré-analyse d’un projet réalisé dans le cadre de ce marché et les expliquer clairement dans son offre pour ce marché. Une attention particulière sera donc apportée aux propositions faites par le soumissionnaire pour améliorer l’efficience, l’efficacité et la qualité des développements réalisés dans le cadre de la maintenance (tous types).

E.2.1. Contexte général

E.2.1.1. Encadrement du marché

L’adjudicataire tiendra compte, dans le cadre de ce marché, des aspects suivants qui sont partie intégrante de la phase de préparation et de réalisation :

Garantie de réalisation des projets ;

Capacité de réaliser les projets à relativement court terme ;

Planning et flexibilité du planning ;

Flexibilité dans l’exécution des projets ;

Communication ;

Rapportage ;

Vision à long terme et orientation avenir ;

Exploitation des opportunités ;

Tous les autres éléments pertinents Le prestataire de services utilisera des techniques avancées et éprouvées en matière de gestion de projet, d’organisation et de documentation pour :

Garantir que toutes les tâches sont définies clairement et logiquement, et comprises de toutes les parties concernées ;

S’assurer que tous les membres de l’équipe assument des responsabilités claires et bien délimitées, et que ces responsabilités sont communiquées à toutes les parties intéressées ;

Veiller à la circulation de l’information au sein de l’équipe de projet afin de contribuer à la réalisation d’une solution intégrée ;

Obtenir à temps du pouvoir adjudicateur toutes les informations nécessaires au bon accomplissement du travail ;

Suivre et respecter les dates limites et les plannings fixés ;

Rédiger une documentation détaillée et correcte des produits et activités ;

Mettre en place un rapportage détaillé et à jour concernant la progression, les problèmes, les points à suivre, les risques, etc., concernant les activités de projet menées à bien ou restant à exécuter.


En introduisant son offre, le soumissionnaire déclare tenir compte de ces aspects et techniques dans l’exécution du marché et disposer de ressources et capacités (matérielles et intellectuels) suffisantes pour les exécuter.

E.2.1.1.1. Collaboration

Dans l’exécution de ce marché, l’adjudicataire devra collaborer avec les départements business, ICT, Development, Testing, Quality, … du SPF Finances (collaborateurs internes et externes). Une collaboration avec des équipes ne relevant pas du SPF Finances, mais d’autres services publics ou de partenaires privés, n’est pas à exclure. Toutes ces collaborations sont obligatoires. Leurs modalités seront définies lors du kick-off du projet concerné et suivies par le Comité de pilotage. Les éventuels problèmes et conflits découlant de cette collaboration seront également soumis au Comité de pilotage. Il est également possible de faire appel à des tiers pour le contrôle qualité et les audits. L’adjudicataire est obligé d’y apporter son concours.

E.2.1.1.2. Conditions de l’exécution

Le SPF Finances pouvant, à certains moments, disposer de ressources internes suffisantes à l’exécution de la maintenance, le pouvoir adjudicateur se réserve le droit de ne procéder à aucune commande et ce, sans dommages et intérêts possibles dans le chef des adjudicataires. Le SPF Finances n'impose pas de justification quant à l'application de ces principes. Méthodologie FUP Toutefois, pour des raisons historiques, le niveau actuel d’intégration avec FUP peut différer d’une application à l’autre. Le cycle global de maintenance (dérivé de FUP) peut globalement être découpé comme suit (une description plus détaillée de ce cycle est fournie en annexe) : Le tableau joint en annexe 6 donne un aperçu de la documentation FUP existante pour chaque application. L’existence de la documentation ne signifie pas qu’elle soit complète, et ne donne aucune indication concernant sa qualité. Même si le projet/l’application n’intègre pas tous les principes, le SPF Finances souhaite dans ce cadre ouvrir une voie vers l’intégration de la méthodologie. Il revient à l’adjudicataire, dans le cadre de la maintenance d’une application, de créer ou compléter la documentation FUP conformément aux prescriptions de la méthodologie FUP. Remarquez que la maintenance d’une application existante implique que l’on perfectionne le code source existant et les nouveaux adjudicataires assurent ainsi également la correction de tous les bugs qui sont encore découverts.


E.2.1.1.3. Description des applications

Une description des applications citées ci-avant est fournie en annexe du présent cahier et couvre les domaines suivants : Description fonctionnelle Description métier des fonctionnalités couvertes par l’application. Cycle de vie récurrent L’exécution du présent cahier des charges est basée sur un cycle d’exécution annuel, découlant du cycle budgétaire lui-même annualisé. Le présent volet a donc pour vocation de préciser les contours des « prestations récurrentes » en matière de support et de maintenance annuels. Évolutions prévues Cette partie a pour objectif d’informer le soumissionnaire quant aux évolutions prévues et/ou probables à la date de rédaction du présent document, afin qu’il dispose de la vue la plus complète possible. Ces informations sont assurément sujettes à évolution et ne constituent aucunement un engagement de réalisation.

E.2.1.1.4. Séparation des aspects « entretien », « développement » et « tests »

Dans sa volonté d’améliorer la qualité de ses applications IT, le SPF Finances a amorcé il y a quelques années une professionnalisation du testing (tests fonctionnels et test de charge/performance) des applications au sens large, et ce, dans l’esprit suivant :

Professionnalisation des tests dans le cadre des projets élaborés durant le Performance Test Center (PTC – charge et performance) et Test Competence Center (TCC – tests fonctionnels et d’acceptation) ;

Meilleure garantie d’une documentation mise à jour ;

Mesure indépendante de la qualité du code, notamment grâce aux outils d’analyse tels que CAST,Fortify et SonarQube ;

Séparation claire des responsabilités entre les équipes qui sont respectivement chargées du développement (y compris tests unit et d’intégration) et des tests (fonctionnels, acceptation et charge/performance) ;

Assistance au Business pour l’élaboration des scripts de test (Test Cases) et des critères d’acceptation ;

Intégration de la composante testing (fonctionnel, performance) dès le début du cycle de maintenance (Définition des requirements).

Dans ce cadre, le Département Quality Assurance et IT Process Support a été créé afin d’englober l’ensemble des aspects liés à la qualité au sens large. C’est dans cette optique qu’ont été créés notamment le Performance Test Center (PTC) en charge des tests de charge et le Test Competence Center (TCC) en charge des tests fonctionnels. Ces 2 équipes sont complétées par l’équipe de Test labo en charge des analyses de code. Le présent cahier spécial des charges distingue donc deux composantes principales conformément à la volonté de professionnalisation du volet qualité/tests :


La partie « entretien et développement », qui regroupe globalement les activités liées au soutien et au développement d’applications, y compris le code et les tests d’intégration de ces applications (hormis les aspects spécifiquement liés au testing fonctionnels),

la partie « tests » (transversale pour les cinq lots « entretien et développement ») regroupe les tests fonctionnels et de charge/performance des applications

Vous trouverez ci-après plus de précision quant à la portée de la mission de chacune de ces deux composantes, étant entendu que la limite de responsabilité de chacune des équipe en charge (Development vs Tests) pourra si nécessaire être précisée en kick-off. Le descriptif de chaque applicatif joint en annexe précise et/ou complète le champ d’action attendu de l’adjudicataire dans le cadre de sa mission. Les soumissionnaires des lots 1 à 5 sont expressément invités à prendre connaissance du contenu de la composante « Tests » (lot 6) et inversement. Bien que les aspects développement et tests soient exécutés par des adjudicataires différents, ces équipes devront collaborer étroitement. Y compris avec les collaborateurs correspondants internes au SPF Finances. Cette collaboration est sous-tendue par le « Modèle en V », standard du marché qui relie chaque phase du cycle de vie de développement à la phase de test correspondante. En l'occurrence, il est question d’une collaboration continue dès l’élaboration des requirements et jusqu’à la complétion du rapport final de test. Lors du kick-off officialisant la prise en charge de l’application, la stratégie globale de collaboration entre les adjudicataires des lots de « tests » et d'« entretien et développement » sera présentée. L’étendue précise, la profondeur de cette collaboration, et les objectifs de la période, seront déterminés conjointement par le SPF Finances et les adjudicataires en présence et validés en Comité de Pilotage dans le cadre de la préparation de chaque cycle annuel. Remarquez que le testing et le débogage du code développé, les tests d’intégration technique et la garantie de qualité générale de l’application relèvent de la responsabilité de l’adjudicataire pour le lot de maintenance concerné.

E.2.1.1.6. Amélioration de la qualité des applications (disponibilité, performance, optimisation, documentation, qualité du code, consommation de ressources,…).

Les applications mises à disposition du personnel du SPF Finances et des Citoyens (E-Gov), bien qu’en constante évolution pour répondre à l’évolution des besoins (la description et le traitement des différents types de maintenance seront abordés plus avant dans le présent cahier spécial des charges), sont arrivées à un niveau de maturité couvrant les besoins des utilisateurs (sauf exceptions signalées). Des informations remontées via les différents canaux d’information, il ressort de manière récurrente qu’une attention particulière doit être consacrée à l’amélioration de la qualité notamment d’un point de vue

de la disponibilité,

de la performance,

de la robustesse,

de l'impact sur les environnements (optimisation de la charge),


de l'intégration à des applications fonctionnellement liées. L’attention du pouvoir adjudicateur portera donc sur les propositions dans ce domaine.

E.2.1.1.7. Intégration entre les applications fonctionnellement liées entre elles

Plusieurs applications fonctionnellement liées entre elles ont été développées au cours du temps par différents prestataires de services, avec éventuellement des technologies différentes. On recherche une approche intégrée qui vise à améliorer la collaboration entre ces applications. L’attention sera donc apportée à des propositions favorisant une intégration et une amélioration dans tous les domaines de la qualité. L’adjudicataire devra tenir compte de ce principe dans l’exécution d’un marché partiel. L’adjudicataire devra indiquer les possibilités d’intégration dans l’analyse du projet partiel et dans l’établissement de son offre.

E.2.1.1.9. Maîtrise des coûts

La rencontre des différents objectifs présentés devra notamment induire à terme une meilleure maîtrise (et donc une réduction) des coûts liés à la maintenance des applications. Il est donc demandé au soumissionnaire de mettre en lien ses propositions avec cet objectif et notamment s’engager à une réutilisation maximale des composants disponibles, qu’ils aient été développés par lui ou mis à disposition par d’autres (par exemple un module de signature électronique).

E.2.1.1.10. Évaluation des prestations exécutées

Au moment où les services seront exécutés, une évaluation portera sur leur qualité et leur conformité. À cet effet, le service d’encadrement ICT a créé un Quality Assurance Comittee (QUAC) au sein de son département Qualité. Le QUAC veille au respect de tous les aspects liés au respect des normes, à la qualité des délivrables (documentation, codes…), aux procédures suivies… Le QUAC rendra un avis à chaque demande de réception (partielle ou complète) des prestations exécutées, sous la forme d’un procès-verbal. Les services incorrects ou non conformes devront être corrigés préalablement à la soumission d’une nouvelle demande de réception.

E.2.1.2. Cycle de maintenance

Le soumissionnaire est invité à décrire dans son offre sa vision et stratégie de la réalisation concrète de ce cycle de maintenance. Il est prié d’accorder l’attention nécessaire à l’utilisation des ressources, au planning, à la work breakdown structure, à l’analyse des risques, au calcul des coûts, … . L’ajout d’une offre modèle (template) avec l’élaboration pratique de ces principes est obligatoire (sous peine de nullité de l’offre).


Le cycle de maintenance (dérivé de FUP) peut être découpé comme suit : 1. Phase initiale

Identification et validation du/des besoin(s) fonctionnel(s) et/ou technique(s)

Première évaluation par l’équipe de projet quant à la faisabilité et au budget nécessaire à la réalisation.

Go/NoGo du Comité de Pilotage concernant la phase préparatoire et de négociation 2. Phase préparatoire et de négociation La préparation a pour but de déterminer précisément la teneur du projet (domaines concernés, fonctionnalités requises, conditions de réalisation), son planning et les ressources nécessaires (budgétaires, humaines et/ou matérielles) afin de permettre une décision en connaissance de cause par le Comité de Pilotage. Les besoins sont notamment mis en rapport avec les développements déjà effectués, les possibilités de mutualisation, et les ressources pouvant être mises à disposition par le SPF Finances, notamment dans le cadre du co-sourcing. Ce trajet se compose comme suit : a. Transmission de la demande à l’adjudicataire par le SPF Finances. Cette demande

contient une description suffisamment précise de la maintenance à réaliser et mentionne, par profil, le nombre de personnes internes au SPF Finances mises à la disposition du projet dans le cadre de ladite demande.

b. Pré-analyse et première évaluation de la charge de travail d’une part par l’adjudicataire, d’autre part par le SPF Finances. Ces analyses et évaluations constituent la base de la négociation menant au projet d’offre.

c. Négociation entre l’adjudicataire et l’équipe projet du SPF Finances afin d’obtenir la proposition la plus équilibrée quant à la prise en compte des besoins exprimés (scope/qualité/délai/coût).

d. Rédaction d’un projet d’offre par l’adjudicataire (avec engagement sur les spécifications, les délais, les SLA…) conforme aux négociations.

e. Validation du contenu du projet d’offre par le comité de pilotage : GO/NOGO. f. En cas de décision positive (GO), une offre contraignante est demandée à

l’adjudicataire, préalable à la phase budgétaire. L’étape b) ci-dessus implique la mise en place d’une méthodologie de pré-analyse et d’évaluation des charges de travail pour les différents projets qui pourront être soumis à l’adjudicataire. Il est demandé au soumissionnaire de décrire très précisément ces méthodologies dans sa réponse au présent marché : participation à la description précise des besoins, méthodes d’évaluation des charges de travail, méthodes d’élaboration des critères de réussite, définition des contraintes techniques et de planning, etc. Des évaluations en « jour-homme » de la phase d’évaluation sera dérivé le prix du marché en multipliant (pour chaque profil) le nombre de jours nécessaires par le tarif journalier des membres de l’équipe de réalisation. Ce tarif figure dans l’offre et fait au besoin l’objet d’une révision suivant la formule du cahier des charges. La phase de préparation est du ressort de l’équipe de projet et du comité de pilotage et ne préjuge en rien des étapes préalables (ex. l’avis du Conseil des Ministres) et/ou suivantes (p. ex. l’avis de l’Inspection des Finances).


3. Phase budgétaire (hors FUP) Pour mémoire, et afin d’être complet : l’offre validée par le comité de pilotage en fin de phase préparatoire suit le circuit d’approbation permettant l’engagement budgétaire des moyens nécessaires. La conclusion positive de cette phase, concrétisée par l’émission d’un bon de commande transmis à l’adjudicataire, permet le démarrage de la phase de réalisation. 4. Phase de réalisation Cette phase vise l’implémentation (analyse, coding, testing) et le déploiement de la solution décrite en phase préparatoire. A) Étude fonctionnelle Une étude fonctionnelle met l’accent sur l’architecture théorique des données et des opérations. Elle précise éventuellement les objectifs, divise les systèmes en sous-systèmes et crée les structures de données. b) Décision du comité de pilotage du projet -> GO/NOGO C) Étude technique L’étude technique développe les objectifs de l’étude fonctionnelle :

Description des procédures :

Conception de la structure de stockage, avec priorité à la sécurité ;

Mesures en matière de sécurité ;

Structure des packages

… b) Décision du comité de pilotage du projet -> GO/NOGO e) Réalisation – Développement & Testing Pour rappel : les activités de réalisation qui relèvent des composants développement/support comprennent en particulier :

Détail des spécifications ;

Développement du code ;

Tests unitaires ;

Tests d’intégration ;

Rédaction de la documentation ;

Support aux équipes en charge du testing. Pour rappel : les activités de réalisation qui relèvent de la composante testing transversal comprennent en particulier :

Elaboration d’un plan de test détaillé ;

Préparation des données de test ;

Test d’ensembles logiques (test système et d’intégration)

Test de l’application complète (performances, robustesse, fonctionnalités…) ;

Création et automatisation des tests de non-régression ;

Test de l’infrastructure et des configurations utilisées ;

Réalisation d’un rapport d’évaluation dans lequel sont mentionnés la qualité constatée et les résultats, ainsi que les risques liés à l’utilisation des produits ;

Fourniture d’assistance aux équipes de test quant à l’amélioration des méthodes de travail et des techniques de test appliquées, l’extension des sortes de test appliquées et la gestion des environnements de test et données de test.


f) Décision du comité de pilotage du projet -> GO/NOGO quant à la mise en production effective. g) Exploitation / mise en œuvre Conversion/migration éventuelle des données et introduction dans le système :

Mise au point d’un plan de conversion et d’introduction, y compris les instructions détaillées ;

Conversion/migration des données ;

Support de l'application du nouveau système ;

Formation/information ;

Soutien

… h) Feed-back et transfert de connaissances La méthodologie doit être exposée dans l’offre et mise en relation à la fois avec ce qui précède et avec la méthodologie PMFin.

E.2.1.3. Transfert des connaissances Le soumissionnaire est invité à décrire dans son offre sa vision et stratégie quant à la réalisation concrète du transfert de connaissances, notamment dans le cadre du co-sourcing (voir critère d’attribution 2). L'adjudicataire s’engage à assurer ce transfert de connaissances et cette coopération de manière continue, implicite et intégrée sans supplément de prestation.

E.2.1.3.1. Implication du personnel interne et renforcement de la maîtrise

Le SPF Finances souhaite clairement maintenir, et dans la mesure du possible renforcer, l’implication de son personnel dans les travaux visés au présent cahier. Dans un contexte de ressources toujours plus rares, il est cependant peu opportun de fixer un objectif fixe en matière de participation du personnel ICT interne. Dans ce cadre, nous attendons des propositions en matière de Co-sourcing adaptées à ce contexte variable et visant une valorisation maximale des ressources mises à disposition par le SPF Finances.

E.2.1.3.2. Co-sourcing

Compte de tenu de la situation en matière de personnel affectable aux projets IT, le SPF Finances ne peut garantir la disponibilité de ressources internes pour les différents projets visés dans le présent cahier spécial des charges. Le SPF Finances se réserve dans ce cadre le droit d’adapter ou de modifier la solution de sourcing selon ses intérêts et possibilités. Néanmoins, la volonté affichée par le SPF Finances est, dès lors que les conditions sont réunies en matière notamment de disponibilité et de niveau de compétence, d’intégrer son personnel à ces projets. Un accord (concrétisé par l’offre du contractant) sera établi à chaque début de cycle, dans lequel seront notamment mentionné le profil et le nombre de


ressources disponibles que le SPF Finances mettra à disposition au cours de ladite période pour réaliser les objectifs fixés de commun accord. Donc, dès lors que du personnel sera affecté au projet en co-sourcing, le soumissionnaire est tenu de respecter les modalités décrites ci-dessous. Il précisera dans son offre au présent marché comment il propose la mise en place pratique de ce mode de collaboration avec les agents du SPF Finances. Le SPF Finances met en place une structure de co-sourcing dans les buts suivants :

Favoriser le transfert de connaissance entre le personnel de l’adjudicataire et les collaborateurs internes du SPF Finances ;

Diminuer les coûts de développement, des tests et de maintenance des projets. Ce co-sourcing est à considérer comme fondement, au même titre que les standards ICT du département. Le contractant est tenu d’en respecter les modalités, et seul le SPF Finances est habilité à décider de ne pas y faire appel, que ce soit pour un projet entier ou pour des parties de projet. En ce qui concerne l’encadrement administratif, l’équipe sera sous la responsabilité d’un chef de projet du SPF Finances. Dans toutes les offres qui seront émises par l’adjudicataire, il y aura lieu d’indiquer de manière explicite les charges de travail réalisées en co-sourcing. Ces lignes donneront forcément lieu à une charge financière nulle dans les tableaux de prix. Dans le cas de profils pour lesquels aucune correspondance n’est trouvée dans ceux de co-sourcing, l’adjudicataire décrira précisément quelles en sont les spécificités et en quoi les profils de co-sourcing ne répondent pas au besoin. Le recours au co-sourcing ne peut en aucun cas enlever ou diminuer la responsabilité du contractant qui devra veiller à un encadrement suffisant du personnel à intégrer. En particulier, le co-sourcing ne pourra pas être utilisé par le contractant comme explication pour du retard de livraison ou pour la présence de failles ou d’erreurs dans les applications mises en œuvre. Par ailleurs, toute offre basée sur le co-sourcing décrira de manière intensive la méthodologie qui sera employée par le soumissionnaire pour la mise en œuvre pratique de celui-ci. L’accent sera notamment mis sur les méthodes de collaboration, l’intégration des équipes, la formation, la répartition des tâches et le suivi et l’évaluation des compétences.

E.2.1.3.3. Documentation

Les documents devront systématiquement être fournis sous format électronique et respecter les standards et templates mis à disposition par le SPF Finances. L’exploitation de ces documents ne devra pas requérir, sauf accord explicite du SPF Finances, l’utilisation d’outils spécifiques requérant l’acquisition de licences. Le SPF Finances demande toujours aussi le matériel didactique, indépendamment du fait que le projet nécessite ou non une formation.


La documentation technique doit être disponible en français ou en néerlandais ou en anglais. Le SPF Finances se réserve la possibilité d’accepter aussi l’anglais pour la documentation technique. Dans ce dernier cas, les deux parties doivent être d’accord. Notez que toute la documentation doit être tenue à jour sans frais supplémentaires pour le SPF Finances pendant la durée de la maintenance. La documentation de l’utilisateur final doit être disponible en français, en néerlandais et pour certaines applications en allemand voire en anglais. Dans ce cadre, les autres langues ne sont pas autorisées. Le soumissionnaire s’engage à donner au SPF Finances un droit de regard sur la confection de la documentation durant l'exécution du projet. Le SPF Finances peut copier les manuels pour les besoins de leur diffusion interne.

E.2.1.3.4. Formation

Il convient de souligner que la fourniture de cours ne concernera qu’une minorité des projets. Il ne faut donc aucunement supposer que cette forme de transfert de connaissances fera partie de l'encadrement d'un projet. Le soumissionnaire doit donc en première instance se concentrer sur le coaching et la documentation technique et fonctionnelle notamment nécessaires aux formations. Chacune des formations requises doit être proposée en français et en néerlandais. La formation sera organisée à 3 niveaux :

Utilisateurs : une formation « train-the-trainer » est prévue pour les utilisateurs, par groupes de 10. En complément, l’adjudicataire peut présenter d’autres modes de formation possible, par exemple l’e-learning.

Gestionnaire de systèmes : le soumissionnaire propose une formation commune aux gestionnaires et aux développeurs du système. Cette formation est dispensée à des groupes de 5 personnes.

Service Desk (remarque : le service desk opère suivant les principes ITIL) : Le soumissionnaire propose ici une formation brève, par groupes de 10 personnes. Cette formation est organisée de telle façon que les membres du service desk acquièrent une connaissance suffisante de l’application pour remplir leur fonction, ainsi que le bagage nécessaire pour transférer cette connaissance à leurs collaborateurs (train-the-trainer).

Les besoins effectifs en la matière seront exprimés et validés par le Business et l’ICT du SPF Finances en début de cycle et le cas échéant valorisés et intégrés au contrat annuel de maintenance (voir cycle annuel). La documentation doit être adaptée aux nouveaux développements et à l'entretien.

E.2.2. Contexte technique

Les documents présentés sous les rubriques « Fondements ICT » et « Standards ouverts » doivent être considérés comme faisant partie intégrante du présent cahier spécial des charges.


Le soumissionnaire est censé avoir pris connaissance des exigences en matière de « normes ICT », y compris les principes de base de FUP (Finances Unified Process) définis par les projets « SUPDEV », « Identity Management » et « Gestion de projet » du SPF Finances dans le cadre de la structure informatique centralisée (la documentation de cette infrastructure et de ses normes est disponible sur le portail du SPF Finances, à l’adresse

http://finances.belgium.be/fr/sur_le_spf/historique_modernisation/ict/ Peuvent y être consultés notamment les directives en matière d’utilisation de « Standards ouverts » et le détail des « Fondements ICT » (Architecture Building Blocks et méthodologie FUP).

E.2.3. Contexte organisationnel

Tous les projets (partiels) au sein du SPF Finances sont réalisés suivant la méthodologie de projet PMFin. PMFin est la méthodologie de projet unique, le standard au sein du SPF Finances. Elle repose sur la méthode internationalement reconnue Prince2. Cette méthodologie est appuyée par l’outil de projet ProjectMaster. L’adjudicataire est tenu d’appliquer PMFin à tous les marchés partiels dans le cadre de ce projet. Les modalités spécifiques et éventuelles dérogations sont fixées en kick-off et au comité de pilotage du projet partiel concerné. Vous trouverez ci-dessous un aperçu des principaux acteurs et phases de PMFin.


E.2.1.2. Project Initiation Document (PID)

Le soumissionnaire joindra à son offre pour un marché partiel un « Project Initiation Document » (PID) (ou équivalent, selon sa propre méthodologie) qui énumère les principales tâches qui doivent permettre la réalisation de ce projet.

Ce document est pour nous, un produit, une unité de travail dans 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 (product breakdown structure) solide et bien étayée : produits, descriptions,

critères de qualité et d'acceptation ; Une WBS (work breakdown structure) complète, un planning détaillé et réaliste du

projet avec des jalons (GANTT) qui mentionne la durée des différentes phases et sous-phases d'activités et de tâches, les moyens à mobiliser, les moyens nécessaires, spécifiés par phase (financiers, personnels, autres) ; Le planning est tenu à jour ;

Une analyse détaillée des risques avec la définition de mesures de maîtrise ; Proposition de structure de projet (compte tenu des rôles décrits dans ce chapitre) ;

Interdépendances avec d’autres projets ;

Plan de qualité ;

Plan de communication (qui reprend des aspects du « change management ») ; Rapports et suivis de l’exécution (statut et progression).

Ce PID sera finalisé, complété et enfin soumis au groupe de pilotage, y compris le sponsor, pour validation à l'occasion du kick-off.


Le soumissionnaire doit décrire sa structure et ses capacités en termes d’organisation de services professionnels, notamment les services offerts, la portée géographique, les niveaux et les qualités du personnel. Ce PID doit mentionner les tâches, la durée et le nombre de personnes impliquées, et ce, pour chaque (partie de) phase. Après l'attribution du projet, le soumissionnaire élaborera un PID complet et détaillé ainsi qu'un plan de projet, et les présentera à la structure de gestion du projet du SPF Finances. Une approbation formelle du PID, y compris le planning de projet, par le comité de pilotage du projet est nécessaire avant d’entamer la phase suivante. Le soumissionnaire est responsable de la mise à jour de ce PID pendant la durée du projet. Toute modification apportée au PID doit être approuvée formellement par le comité de pilotage du projet. Le PID élaboré constituera pour notre propre PID une source d’informations à propos des produits et des unités de travail dont le soumissionnaire aura la charge.

E.2.3.2. 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 :

E 2.3.3. Chef de projet

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


Le soumissionnaire désignera son propre coordinateur de projet externe (task manager). Celui-ci et le chef de projet assument l'entière responsabilité de la bonne exécution du projet.

E 2.3.4. 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 dé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. De plus, il traite tous les aspects contractuels, administratifs et techniques relatifs à 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 rendront régulièrement compte au Comité de pilotage : statut, avancement, risques et problèmes... Le Comité de pilotage se compose du sponsor, du chef de projet et d’un représentant des utilisateurs. Un profil senior du soumissionnaire et le coordinateur de projet externe participent aux réunions du Comité de pilotage, afin d’informer celui-ci et de discuter des litiges/problèmes soulevés par le chef de projet. 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. Lorsque sont mis à l’ordre du jour des points dont le contenu peut comporter un conflit d’intérêts avec des partenaires externes, le sponsor peut décider en toute liberté de délibérer et de statuer sur ces points sans la présence de représentants de ce partenaire externe.

E 2.3.5. Équipe de projet

L’équipe de projet se compose de différents profils (internes et externes) dont chacun rend compte au responsable de son unité de travail (work package) ou au chef de projet. Les rôles suivants font idéalement partie de l’équipe : coordinateur de projet ICT (qui assure la liaison avec le Service d’encadrement ICT, dénommé dans ce marché « Task Manager »), change coordinator (chargé de la gestion des changements (P&O et Communication)), coordinateur externe (contractant).

E 2.3.6. Réunion de coup d’envoi (kick-off)

Dans un délai maximum de 2 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). Pendant le kick-off, il est pris acte du lancement officiel du projet. Lors de cette première réunion, on procédera – si le cahier des charges le prévoit – à l’examen du PID, on présentera la composition et les connaissances techniques des équipes respectives, on fixera l’agenda des rapports et des réunions du comité de pilotage, on fixera


des conventions relatives à la gestion de projet et au planning de la réalisation du marché, on expliquera les principes des 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.

E 2.3.7. Réunion du groupe 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. Le sponsor ou le chef de projet peuvent toujours convoquer un Comité de pilotage en dehors des dates fixées.

E 2.3.8. Autres réunions

Une fois par semaine, le chef de projet rencontre l'équipe de 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).

E 2.3.9. Qualité

Le PID réserve une large place à la qualité. Le soumissionnaire indique dans son PID comment il entend surveiller la qualité. Par ailleurs, le SPF Finances peut demander des contrôles supplémentaires au Test Competence Center (TCC) et un contrôle de qualité au service ICT Quality ou à des tiers. Le Quality Assurance Comite (QUAC) valide tous les délivrables quant à leur conformité aux standards avant qu’ils soient acceptés

E 2.3.10. 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, les rapports SLA… Périodiquement, selon un calendrier défini de commun accord lors de la réunion kick-off, l’adjudicataire établira un rapport complet destiné au Comité de pilotage concernant l’état d’avancement du projet (état de chaque phase de réalisation) et les problèmes éventuellement rencontrés avec les solutions proposées. L’adjudicataire établira également des rapports de coordination et de travail concernant l’état d’avancement du projet (statut de chaque phase de réalisation) et les éventuels problèmes rencontrés avec les solutions proposées. Ces réunions seront organisées de manière ponctuelle à la demande des parties. Le rythme de ces rencontres dépendra de l’état


d’avancement des phases du projet. Le lieu de ces réunions sera précisé en même temps que les dates par le SPF Finances. Le soumissionnaire et le coordinateur de projet qu’il a nommé mettront à la disposition du chef de projet toutes les informations nécessaires pour disposer d’un aperçu de l’avancement effectif des travaux dans le chef du soumissionnaire et de la situation par rapport au planning prévu. Ces rapports à l’attention du chef de projet se font chaque semaine, à l’aide d’un état reproduit sur le tableau Gantt du projet et complété par un bref commentaire écrit à propos des points essentiels et des éventuels problèmes, y compris la façon d’y remédier. Tous les détails concernant la manière d’établir ces rapports seront communiqués au début du projet. Tous les aspects relatifs au contenu (planning, risques, qualité, réception, ressources, etc.) seront tout d’abord débattus au sein de l’équipe de projet. Si le chef de projet le juge nécessaire, les problèmes seront soumis à discussion et délibération auprès du comité de pilotage. Le chef de projet fait rapport de l’avancement du projet devant le Comité de pilotage. Le cas échéant, le chef de projet peut inviter en appui le coordinateur de projet externe à la réunion du comité de pilotage afin d’expliquer certains aspects plus en détail.

E 2.3.11. Gestion des modifications

Toute modification (périmètre, résultats/produits préconisés, planning, budgets…) au projet doit faire l’objet d’une demande de modification décrivant en détail la raison de la modification et son impact. Le groupe de pilotage évalue le bien-fondé et l’opportunité de la modification proposée. Il peut se faire assister par le PMO (opérationnel) et/ou par un expert (externe) en la matière. L’approbation formelle du Fonctionnaire dirigeant est nécessaire avant de mettre les modifications proposées à exécution. Le cas échéant, l’adjudicataire se chargera d’actualiser le PID. Le soumissionnaire décrit sa méthodologie et son approche en ce qui concerne la gestion des modifications afin d’assister le Service public fédéral Finances pendant la mise en service du nouveau système et ses conséquences pour l’organisation des méthodes de travail. Le soumissionnaire doit décrire la plus-value offerte dans le cadre de la gestion des modifications au Service public fédéral Finances. À cet égard, il convient de prévoir les activités suivantes :

la préparation au changement ;

l’assistance de l’équipe du SPF Finances pendant la mise en service du nouveau système et la conversion vers ce nouveau système ;

le suivi après implémentation et assistance pour le management, les utilisateurs et le personnel technique/d’appui.


E.2.4. SLA

E.2.4.1. Introduction

L’administration souhaite conclure un Service Level Agreement (SLA) ou contrat de niveau de service pour chaque lot de cette demande d'offres. Le SPF Finances accorde une grande importance aux SLA imposés. Les SLA permettent en effet de surveiller les objectifs et les risques pour l’organisation liés aux services demandés. Des amendes peuvent être infligées à l’adjudicataire si le SPF Finances constate que les niveaux de services et les obligations de résultats ne sont pas respectés. Les normes pour les niveaux de service seront fixées par des exigences de performances exprimées en un ou plusieurs indicateurs de performance. Ces niveaux de service décrits individuellement produiront ensemble le MASTER SLA pour chaque lot de ce cahier des charges. Le SLA sera accompagné d’un « Dossier Accords et Procédures(DAP) » . Les normes exprimées en exigences de performance et indicateurs de performance, ainsi que les éventuelles clauses d’amende afférentes, figureront dans un tableau récapitulatif des KPI (tableau des Key Performance Indicators). Comme modèle de gestion pour ces processus ICT, le SPF Finances a choisi de suivre des processus ITIL© V3-20112. Le Service Level Management doit aligner le service ICT presté dans le cadre de ce marché sur les objectifs opérationnels en termes de qualité, quantité et coûts.

IMPORTANT Le soumissionnaire est tenu d’introduire les documents suivants sous peine de nullité de l’offre : 1. Concept MASTER SLA 2. Dossier Accords et Procédures (DAP) 3. Service Quality Plan (SQP) 4. Service Improvement Plan (SIP) 5. Exemple de rapportage

E.2.4.2. Principe d’élaboration des SLA dans le cadre de ce marché et déliverables correspondants

E.2.4.2.1. Concept MASTER SLA - template SLA FODFIN En annexe 4 de ce cahier des charges figure le modèle SLA actuel du SPF Finances qui sert de point de départ à la rédaction du projet de MASTER SLA. Il s’agit d’un template général,

2 Voir paragraphe Relation entre SLA et ITIL© V3-2011 Glossary


générique des SLA du SPF Finances, qui doit donc être adapté en fonction du caractère spécifique du cahier des charges pour les lots 1, 2, 3 et 4. Il est permis de proposer d’autres points pertinents dans le concept MASTER SLA. Aucune information financière ne figure dans le SLA sauf, éventuellement, une liste des clauses d’amendes (voir annexe 5). E.2.4.2.2. Tableau de KPI avec clauses d’amende Un indicateur clé de performances (KPI) est une condition importante qui doit être surveillée afin de limiter les risques liés à l’objectif à réaliser par le processus auquel il est associé. Les objectifs des processus permettent eux-mêmes la réalisation des objectifs de l’entreprise. Le tableau récapitulatif de l’annexe 4 contient à la fois les KPI et les indicateurs de performance (IP) et normes de performance correspondants. Une clause d’amende figure également dans le tableau pour certaines normes IP. C’est l’amende standard prévue par le SPF Finances en cas de non-respect des normes définies dans le tableau. E.2.4.2.3. Projet de « Dossier Accords et Procédures (DAP) » – contenu

IMPORTANT Le soumissionnaire est tenu de joindre à l’offre une version du concept de DAP sous peine de nullité de l’offre.

En complément au MASTER SLA, le soumissionnaire doit obligatoirement établir et présenter un premier projet de « Dossier Accords et Procédures (DAP) ». Ce document reprend les accords relatifs au mode de coopération entre le pouvoir adjudicateur et l’adjudicataire. L’objectif de ce document est de préserver la lisibilité du document des SLA et de faire figurer tous les éléments liés aux accords et détails dans un document DAP distinct. Un avantage supplémentaire de cette méthode est la possibilité d’adapter rapidement le DAP sans qu’il soit nécessaire d’apporter de modification (nouvelle signature…) au document SLA original. Pour résumer, les points suivants sont traités – voir l’ouvrage de référence pour de plus amples détails :

Accords concernant la gestion du document DAP (durée de validité, procédures de modification du DAP, dérogations accessoires au DAP…) ;

Accords concernant les processus et procédures (templates, processus de gestion, tâche de gestion pour chaque processus de gestion, une description détaillée avec flowcharts, interfaces, accords…) ;

Lignes de communication (notifications d’incidents, procédures d’escalade, plaintes, informations de contact personnes impliquées…) ;

Tâches, compétences et responsabilités (RACI, structures de concertation, composition des différentes instances compétentes…) ;

Exemples de rapportage (organisation du rapportage pour chaque processus de gestion, fréquence et forme du rapportage sur les SLA, éventuellement exemples de rapports…).


Pour l’élaboration détaillée, veuillez consulter un ouvrage de référence3 qui contient un template détaillé du DAP. Aucune information financière ne figure dans le DAP. Aucun modèle formel n’est imposé au soumissionnaire concernant la forme de cette première version du concept de DAP. En matière de processus et de procédures, le standard en vigueur au SPF Finances est actuellement ITIL© V3-2011 (voir aussi paragraphe ITIL © V3-2011). Il est spécifiquement demandé qu’une première version des processus suivants et des procédures y afférentes soit, le cas échéant, traitée et décrite dans le concept de DAP à présenter, le cas échéant :

o ITIL Service Delivery Set (gestion tactique) Service Level Management; Availability Management; Capacity Management; IT service continuity Management;

o Service Support Set (Gestion opérationnelle)

Gestion des incidents ; Gestion des problèmes ; Gestion du changement ; Gestion des versions ; Gestion de la configuration ; Remarque : le service desk en fait également partie. Cette première

version du projet de DAP sera obligatoirement jointe à l’offre (voir critères d’évaluation).

E.2.4.2.4. Service Quality Plan (SQP) – Plan de qualité de service Pour continuer à garantir la qualité du service pendant la durée du projet, le soumissionnaire présentera un premier projet de plan d’approche pour un Service Quality Plan (plan de qualité de service). Ce SQP doit permettre d’adapter l’organisation et la gestion du projet aux exigences de la prestation de services. En principe, ce plan sera revu chaque année avec le groupe de pilotage du projet en vue d’atteindre le niveau de service souhaité. Le SQP proposé contiendra au moins les rubriques suivantes :

Accords concernant la gestion du document SQP (gestion des versions, durée de validité, procédures de modification du SQP…) ;

Objectif du SQP ;

Gouvernance du projet ;

Structure organisationnelle et gestion du projet ;

Gestion de la qualité, contrôle de qualité et garantie de qualité dans le cadre de ce marché ;

Structure de rapportage ; E.2.4.2.5. Service Improvement Plan (SIP) – Plan d’amélioration

3 SLA Best Practices - Bart de BEST p-95-102 – ISBN13 : 978-90-71501-45-6


Dans son offre, le soumissionnaire formulera une proposition indiquant comment il compte remédier à tout problème grave ou structurel constaté lors de la réalisation des normes de service. À cet effet, il établira un plan d’amélioration, également appelé SIP. Le soumissionnaire expliquera comment il organisera un SIP dans le cadre de ce marché. Le SIP proposé contiendra au moins les rubriques suivantes :

Accords concernant la gestion du document SIP (gestion des versions, durée de validité, procédures de modification du SIP…) ;

Méthodologie utilisée ; Plan d’approche global ou un proche par KPI en cas de dérogation à la norme

Rapportage

E.2.4.2.6. Service Level Reporting (SLR) - Rapportage sur le niveau de service Le rapportage concernant les normes IP atteintes figure dans des Service Level Reports, qui sont soumis périodiquement au SPF Finances à fins de contrôle et de réorientation. Les modèles de ces SLR sont repris dans le DAP. Un exemple de rapportage basé sur ce modèle fera partie de l’offre (voir paragraphe E 2.4.14.2.1 « Rapports généraux Service Level »). E.2.4.2.7. Délais et moyens d’élaboration des DAP, après l’attribution du marché Deux mois après l’attribution du marché, le DAP global complet, élaboré en concertation et définitif (Dossier Accords et Procédures) doit être disponible, ainsi que le Service Quality Plan (SQP), le Service Improvement Plan (SIP) et les modèles de rapports. Les processus et les procédures y afférentes doivent également être au point et opérationnels. Les mesures, rapports et reviews relatifs aux SLA doivent également être opérationnels à ce moment. Le soumissionnaire prévoira dans son offre les moyens nécessaires pour implémenter, exploiter et rectifier tous les documents nécessaires (MASTER SLA, DAP, …) ainsi que les procédures et processus correspondants durant toute la durée de ce marché.

E.2.4.3. Encadrement SLA

E.2.4.3.1. Relation entre SLA et ITIL© V3-2011 – Glossary Les SLA doivent être établis sous la forme de processus. Le SPF Finances utilise le modèle de gestion ITIL© V3-2011 à cet effet. Comme déjà indiqué, il est demandé de tenir compte des objectifs de ces processus de gestion et du Service Level Management dans l’élaboration de ces SLA. Les processus de gestion sont décrits dans le DAP. Pour de plus amples informations, voir les sites Web suivants relatifs à ITIL© V3-2011:

http://en.wikipedia.org/wiki/ITIL

http://wiki.en.it-processmaps.com/index.php/Main_Page4

4 Since July 2013, ITIL has been owned by AXELOS Ltd, a joint venture between HM Cabinet Office and

Capita Plc. Axelos licenses organisations to use the ITIL intellectual property, accredits licensed Examination

Institutes, and manages updates to the framework.

http://en.wikipedia.org/wiki/ITIL

http://wiki.en.it-processmaps.com/index.php/Main_Page

http://en.wikipedia.org/wiki/Axelos


La terminologie utilisée dans ITIL, avec une explication des termes, est disponible en langue originale (anglais) et traduite en néerlandais, français et allemand sous le lien suivant :

http://www.itil-officialsite.com/internationalactivities/itilglossaries_2.aspx5 Pour de plus amples explications concernant les termes utilisés dans ce cahier des charges, veuillez consulter ces ITIL© Glossaries. Si le SPF Finances souhaite utiliser une autre définition, cela sera spécifiquement mentionné dans le cahier des charges, et seule cette définition sera valable. E.2.4.3.2. Relation entre les SLA et les normes et fondements ICT du SPF Finances. Les normes et fondements ICT du SPF Finances sont publiés en ligne sur les sites Web suivants :

Néerlandais http://financien.belgium.be/nl/over_de_fod/geschiedenis_modernisering/ict/ict_fundamenten/

Français http://finances.belgium.be/fr/sur_le_spf/historique_modernisation/ict/ict_fundamenten/

E.2.4.3.3. Description et Contrôle SLA Pour gérer les normes de service, l’accent est placé sur une surveillance proactive et réactive : Proactive par un monitoring de qualité. Réactive par un processus de gestion des incidents. E.2.4.3.4. Principe des Quality Gates dans les cycles de développement L’adjudicateur attache une grande importance à la surveillance de la qualité pendant l’exécution du marché. C’est pourquoi il sera nécessaire de travailler avec des Quality Gates pendant l’exécution du projet. Celles-ci ont les objectifs suivants :

Garantir la qualité au début du projet, par une approche en projet qui intègre la garantie de qualité afin que les produits finaux livrés satisfassent aux standards et normes exigés.

Réduire le cycle de développement en « réussissant au premier essai »

Accent sur une conception de qualité des produits par une approche « Quality by Design ».

La notion de Quality Gates consiste à procéder aux analyses nécessaires entre les différentes phases. Nous distinguons les phases principales suivantes dans le cycle de développement de chaque itération :

1. Requirements (FUP D2) 2. Design (FUP D3) 3. Développement (FUP D4) 4. Testing (FUP D5 + TMv4, voir aussi lot 6)

Nous distinguons 4 Quality Gates, avec respectivement les 4 « reviews » suivantes :

5 Copyright © AXELOS Limited 2012. All rights reserved. Material is reproduced with the permission of

AXELOS"

http://www.itil-officialsite.com/internationalactivities/itilglossaries_2.aspx

http://financien.belgium.be/nl/over_de_fod/geschiedenis_modernisering/ict/ict_fundamenten/

http://financien.belgium.be/nl/over_de_fod/geschiedenis_modernisering/ict/ict_fundamenten/

http://finances.belgium.be/fr/sur_le_spf/historique_modernisation/ict/ict_fundamenten/


1. Requirements Review : la validation des requirements en concertation avec le business. L'adjudicataire des lots 1 à 5 décrira l’approche qu’il utilisera dans l'inventorisation et la validation des requirements. L’approche doit permettre d’obtenir une compréhension mutuelle optimale de chaque requirements du périmètre de l’itération afin que les corrections soient réduites à un minimum dans les phases ultérieures du cycle.

2. Design review: l'adjudicataire des lots 1 à 5 décrira l’approche qu’il utilisera dans la review pour faire en sorte que la conception corresponde aux standards ICT et aux requirements identifiées.

3. Development review: l’adjudicateur attache une grande importance à une approche « Quality by Design » orientée qualité dans la rédaction du code. L'adjudicataire des lots 1 à 5 décrira l’approche qu’il appliquera dans la review pour garantir que le code livré est développé selon les meilleures pratiques généralement acceptées d’une part et satisfait aux exigences des standards en ICT d’autre part (voir aussi l’introduction du paragraphe I.1.3.2).

4. Test review: l’adjudicataire du lot 6 décrira l’approche spécifique qu’il utilisera dans la review afin de garantir la qualité des tests et leur cohérence avec les autres phases dans la méthodologie des tests discutée dans le lot 6.

Le tout est résumé par l’illustration suivante, qui présente la répartition en phases d’une

itération : L’adjudicateur est conscient des différentes méthodologies de type « agile » (scrum...) qui sont habituelles dans le monde du développement de logiciels. La répartition en phases ci-dessus peut être appliquée dans une approche « agile » (ex. sprints). L’adjudicateur ne veut absolument pas de modèle en cascade, mais préfère une approche itérative. La répartition en phases visualisée correspond donc à une itération x et non à l’ensemble du projet. Le soumissionnaire qui souhaite appliquer une méthode de développement agile est invité à décrire comment il la greffera sur les standards ICT en vigueur, qui restent intégralement d’application. Nous soulignons explicitement le fait que l’utilisation des outils et templates décrits dans les standards ICT reste obligatoire (ex. template déliverables FUP, tools FUP…). Ils devront donc également être intégrés dans les approches des reviews demandées dans ce paragraphe. E.2.4.3.5. Environnements à soutenir dans le cadre du présent SLA Les environnements dans lesquels les SLA demandés peuvent être valables figurent ci-dessous. Ces environnements sont désignés par une lettre ou une abréviation.


Dans le tableau des KPI, on a décrit pour chaque KPI l’environnement pour lequel il est valable.

D: Development

A: Acceptation

T: Test

P: Production

E.2.4.4.Service Levels et engagements de résultats correspondants dans le cadre de ce marché

Le SPF Finances souhaite définir 7 niveaux de service, adaptés aux différentes phases :

1. Service Levels relatifs à la gestion de projet : 2. Services Levels relatifs à la phase de développement ; 3. Service Levels relatifs à la mise en production ; 4. Services Levels relatifs aux exigences non fonctionnelles ; 5. Service Levels en matière de traitement d’incidents, d’interventions correctrices et

réactives ; 6. Service Levels concernant les services du personnel mis à disposition par

l’entrepreneur : 7. Service Levels relatifs au lot 6 Testing.

Ces 7 SLA et engagements de résultat sont décrits dans les sections suivantes.

E.2.4.5. Service Levels relatifs à la gestion de projet : délai, exhaustivité et planification

E.2.4.5.1. PI-Project-bid-delivery-period

Objectifs

Définition Livrer l’offre avec le plan du projet dans le délai fixé par le SPF Finances.

Méthode de mesure Contrôle par comparaison de la date de demande et de la date d'introduction de l’offre.

Formule de calcul Date d’introduction de l'offre (ou date d'accusé de réception du SPF Finances) – date de demande officielle du SPF Finances.

Période de calcul Le calcul se fait trimestriellement et est rapporté en fonction du nombre de demandes qui débutent à partir du 1er jour ouvrable du 1er mois jusqu’au dernier jour ouvrable du 3e mois. En fonction de ces chiffres, des actions correctrices sont mises en œuvre si nécessaire.

Résultat à atteindre 90% des demandes à fournir doivent être effectuées dans les 10 jours ouvrables


E.2.4.5.2. PI-Bid-Task-Completeness

E.2.4.5.2.1.Composition minimale offre lots de 1 à 6

Liste non limitative : à préciser après adjudication du marché en concertation avec l’adjudicataire.

Artikel I. Plan du projet avec phases, milestones Artikel II. Estimations des ressources, délais, Artikel III. déliverables à générer Artikel IV. services à générer Artikel V. proposition financière Artikel VI. analyse de risque Artikel VII. analyse de l'impact

Le contenu sera précisé en concertation avec l’adjudicataire après attribution du marché.

E.2.4.5.2.2. Description

E.2.4.5.3. PI-Project Plan-Planning

Objectifs

Définition Un contrôle de l’exhaustivité de l’offre sur la base de la composition minimale décrite dans le paragraphe ci-dessus.

Méthode de mesure

Vérification par le demandeur auprès du SPFFIN

Tous les éléments sont repris.

Formule de calcul Nombre d’offres complètes demandées, une offre est incomplète si plus d’un des éléments convenus de l’offre manque ou est incomplet (cf. composition minimale de l’offre dans le cahier des charges).

Période de calcul Le calcul se fait trimestriellement et est rapporté chaque trimestre en fonction du nombre de demandes, à partir du 1er jour ouvrable du 1er mois jusqu’au dernier jour ouvrable du 3e mois. Si nécessaire, des actions correctrices sont mises en place, en fonction de ces chiffres.

Résultat à atteindre

90% des offres demandées doivent être complètes sur base trimestrielle.

Sur cette base, le SPFFIN a le droit de refuser l’offre demandée de l’adjudicataire ou de demander des informations complémentaires.

Objectifs

Définition Le respect du planning préétabli pour tous les projets/marchés en cours que l'adjudicataire doit exécuter officiellement. À la fin de chaque mois, l’adjudicataire transmettra le statut de chaque projet/marché par le biais d’un graphique de Gantt. Un aperçu global du statut des projets/marchés en cours sera repris dans le rapportage chaque trimestre. Le planning ne peut être modifié qu’en concertation avec le SPF FIN et après approbation formelle du groupe de pilotage.

Méthode de mesure Comparer manuellement les dates conformément au planning (par le


E.2.4.6. Niveaux de service phase de développement : conformité à la méthodologie FUP, aux standards ICT et qualité du code

L’adjudicataire doit se conformer aux deliverables et au cycle de vie (phases, itérations, relations temporelles avec les deliverables…), ainsi qu’aux outils standard utilisés au sein du SPF Finances. Cela inclut les points suivants :

la réalisation des deliverables FUP conformément à la méthodologie FUP et compte tenu de la qualité livrée ;

Lot 3 (Développement et support) :

l’utilisation correcte des standards définis dans les standards ICT6

Afin de contrôler et de garantir la qualité du code et de la solution livrée, les principes et critères7 suivants seront utilisés :

La conformité à la méthodologie FUP, en particulier les artefacts de la discipline D4 dont font notamment partie le plan de qualité du code et le rapport de qualité du code.

L’intégration dans la FUP-ITIL « continuous integration tool chain » (Starteam, Maven, Jenkins, SonarQube, HP Fortify…). Un indicateur de performance sera repris sous le SLA mis en production.

Un contrôle de la qualité du code sera réalisé au moyen de l’outil SonarQube (voir aussi www.sonarqube.org). Le pouvoir adjudicateur attache une importance particulière :

o un unit test coverage élevé : min. 80% ; o à un degré suffisamment élevé de documentation du code :

documentation conforme aux public API ; o au Rules Compliance Index (RCI) calculé sur la base des règles du SPF FIN :

min. 90% ; pas de blocking issues ; pas de critical issues ;

o à la limitation à un minimum du nombre de lignes de code dupliquées : max. 10%

6 Architecture Building Blocks 7 Vu la durée du contrat-cadre, ces principes et critères pourront être adaptés aux nouvelles évolutions et

découvertes technologiques.

biais d’un éventuel graphique de Gantt du projet/marché)

Formule de calcul Date de réception – date officielle de démarrage du projet/marché

Période de calcul Le statut des retards de tous les projets en cours est établi sur base annuelle. Sur la base du graphique de Gantt des projets/marchés qui sont revus périodiquement par le chef du projet conformément au planning convenu.

L'évaluation définitive se fait sur base annuelle.

Résultat à atteindre 90% des projets/marchés attribués à un entrepreneur durant l’année en cours peuvent avoir un retard max. de 10 jours ouvrables.

http://www.sonarqube.org/


Un contrôle de sécurité et d’intégrité du code sera réalisé au niveau des applications web à l’aide de l’outil HP Fortify. Cet outil partage le nombre de problèmes de sécurité potentiels en 4 catégories : critical, high, medium et low. La condition de base pour l’acceptation de la solution est qu’il ne peut y avoir aucun problème dans la catégorie critical. Les normes et critères de qualité seront précisés après attribution du marché en concertation avec l’entrepreneur. Si nécessaire, et d’après les contrôles qualité réalisés, l’adjudicataire s’engage à apporter les améliorations nécessaires à son code afin de respecter les normes de qualité et les délais des phases établis dans le présent cahier des charges.

Le SPF Finances se réserve le droit d’utiliser d’autres outils afin de vérifier la qualité du code. E.2.4.6.1. PI-délivrables-FUP

E.2.4.6.2. PI-FUP-Outils & ICT-standards

E.2.4.6.3. PI-Quality-of-Code

Objectifs

Définition Les délivrables FUP doivent être livrés complets et dans les délais. La liste exacte des délivrables FUP à livrer sera fixée au début de chaque marché.

Méthode de mesure La date à laquelle la version finale des délivrables FUP sera reçue au repository central (Starteam).

Formule de calcul Date à laquelle la version finale est disponible dans le repository central – la date prévue dans le planning du projet.

Période de calcul Selon le planning du projet

Résultat à atteindre Max. 10 jours ouvrables de retard sur la date de livraison.

Objectifs

Définition Les outils FUP et les standards ICT doivent être respectés en permanence.

Méthode de mesure Contrôle de qualité par le SPF FIN ou par un tiers pour le compte du SPF FIN.

Formule de calcul Le nombre de jours ouvrables entre la date à laquelle les non-conformités ont été communiquées et la date à laquelle l’adjudicataire communique formellement qu’elles ont été résolues.

Période de calcul Trimestrielle

Résultat à atteindre Un mois de 30 jours comprend 43 200 minutes et correspond à 100% de disponibilité pour la service window 7x24x365.

Objectifs

Définition Tout comme les années bissextiles, on tient compte des mois qui comptent 30 et 31 jours respectivement. Méthode de mesure La disponibilité est mesurée en effectuant une simulation toutes les 10min qui contrôle les fonctionnalités précitées.

Méthode de mesure Date de livraison de la version figurant dans Delivery Management

Formule de calcul Nombre de releases qui satisfont aux critères / Nombre total de releases


E.2.4.6.4. PI-Security-Integrity-Code

E.2.4.7. Mise en production des Servicelevels

Les procédures strictes appliquées par le SPF Finances doivent être respectées pour la mise en production de nouvelles versions/nouveaux patches/bugfixes. Ce, afin de ne pas perturber l’opérationnalité de l’environnement opérationnel existant. Les outils et méthodologies prévus et décrits dans les standards ICT seront utilisés. E.2.4.7.1. PI-Continuous-Integration-Tool-Chain

E.2.4.7.2. PI-Releases-in-production


Résultat à atteindre Si une ou plusieurs normes de qualité du plan qualité n’ont pas été respectées après la livraison d’une version donnée, cela devra être corrigé dans un délai de max. 10 jours ouvrables, par livraison d’une nouvelle version qui respecte les normes de qualité fixées.

Objectifs

Définition C’est la durée avant qu’une contre-mesure à une fuite de sécurité soit prise après que la fuite a été formellement constatée par le SPF Finances ou une partie tierce.

Méthode de mesure - SAST (Static Application Security Testing)

- DAST (Dynamic Application Security Testing)


Objectifs

Définition La Continuous Integration Tool Chain doit toujours être utilisée correctement :

pour les activités de développement day-to-day ;

lors de la livraison de versions/patches/bugfixes au département ICT Operations.

Des informations sur la « Continuous Integration Tool Chain » de FUP-ITIL figurent dans les ABB.

Méthode de mesure Les informations figurant dans les outils de la Continuous-Integration Tool Chain (Jenkins, Delivery Management …).

Formule de calcul Nombre de versions /patches/bugfixes qui ont été livrés sans utilisation correcte de la Continuous Integration Tool Chain.


Résultat à atteindre Aucune version ne peut être livrée sans utilisation correcte de la Continuous Integration Tool Chain.

Objectifs


E.2.4.8. Service levels exigences non fonctionnelles

E.2.4.8.1. PI–Availibility-7x24x365 et PI-Availibility-5x12 Le SPF Finances considère les indicateurs de performances « disponibilité des applications » comme très importants en vue de garantir un service de qualité pour l’organisation interne et les citoyens. Le principe est que les applications sont réparties en plusieurs catégories de disponibilité. La différence entre catégories réside dans les service windows ou périodes d’ouverture et dans les pourcentages de disponibilité prévus et souhaités. On indiquera également la catégorie de disponibilité dont relève l’application pour chaque marché.

E.2.4.8.1.1. Périodes d’ouverture du service (service window) et périodes de maintenance dans le cadre de ces SLA

Les périodes d’ouverture d’un service sont les périodes pendant lesquelles le service est disponible pour son utilisateur. La période de maintenance est la période où les services ne sont pas fournis, par exemple parce que des travaux de maintenance doivent être effectués sur les applications ou l’infrastructure.

E.2.4.8.1.2. Service Windows par catégorie d’applications

Le SPF Finances prévoit actuellement deux catégories d’applications pour lesquelles des indicateurs de performance de disponibilité sont prévus. Service window 7x24x365 Les incidents peuvent être notifiés manuellement via le help desk du SPF Finances ou automatiquement par le système de monitoring du SPF FIN. Toutes les autres indisponibilités de l’application, par exemple en raison d’incidents, seront traités comme tels si elles relèvent de la compétence de l’adjudicataire. En fonction de la nature de l’incident, le SPF Finances peut décider d’effectuer des interventions dans la service window afin de rétablir le service au profit des utilisateurs finaux. Des techniques de back-up en ligne seront utilisées pour ces applications.

Définition La version proposée pour la mise en production doit être exacte et exhaustive par rapport aux exigences définies.

Méthode de mesure La gestion des incidents et l’outil standard utilisé pour les demandes d’installation des versions

Formule de calcul Nombre de versions retirées de la production parce que inexactes, incomplètes ou douteuses / Nombre total de versions


Résultat à atteindre Max. 10%


Service window 5x12 Les applications sont disponibles les jours ouvrables officiels du SPF Finances, de 07h00 à 19h00, cinq jours sur sept, du lundi au vendredi, à l’exception des jours fériés et des jours de pont officiels du SPF Finances. Des interventions peuvent avoir lieu pendant le week-end de maintenance trimestriel prévu et les périodes d’intervention convenues mutuellement à l’avance – et confirmées par le SPF Finances – en dehors de la service window fixée. Les indisponibilités des applications, par exemple en raison d’incidents, seront traitées comme telles si elles relèvent de la compétence de l’adjudicataire. En fonction de la nature de l’incident, le SPF Finances peut décider d’effectuer des interventions dans la service window pour rétablir le service au profit des utilisateurs finaux (voir aussi paragraphe Traitement des incidents, actions correctrices et réactives). E.2.4.8.1.3. Normes PI–Availibility-7x24x365 et PI-Availibility-5x12

E.2.4.8.1.4. Clauses de pénalité PI–Availability

Objectifs

Définition Les périodes de maintenance planifiée ou les interruptions convenues avec le SPF Finances (pour cause de mises à jour, de nouvelles versions…) ne seront pas prises en considération pour la période d’indisponibilité au cours de la période de référence.

Actuellement, le SPF Finances prévoit 4 week-ends de maintenance par an, 1 par trimestre ; pendant cette période, des travaux importants peuvent être effectués et les citoyens ne peuvent pas accéder aux applications e-gov

Les indisponibilités qui ne sont pas dues à l’adjudicataire (après examen et concertation) ne sont pas prises en considération.

Un mois de 30 jours comprend 43 200 minutes et correspond à 100% de disponibilité pour la service window 7x24x365. La disponibilité peut être calculée de la même manière pour le nombre de minutes de disponibilité dans la service window 5x12.

Tout comme les années bissextiles, on tient compte des mois qui comptent 30 et 31 jours respectivement.

Méthode de mesure La disponibilité est mesurée en effectuant une simulation toutes les 10 minutes qui contrôle les fonctionnalités précitées.

Période de calcul La disponibilité est calculée par période de six mois. Des actions correctrices sont mises en place en fonction de ces chiffres.


Le rapportage de fait tous les 3 mois.

Résultat à atteindre

PI–Availibility-7x24x365 PI-Availibility-5x12

99,50% de disponibilité pour chaque application (version) en production de l’adjudicataire.

99% de disponibilité pour chaque application (version) en production de l’adjudicataire.


La disponibilité et les clauses de pénalité correspondantes s’appliquent à toutes les applications individuelles que l’adjudicataire a en production. Les amendes sont donc calculées par disponibilité d’une application individuelle. E.2.4.8.2. PI-Performance La performance doit être déterminée par catégorie d’applications ou par exception pour une application individuelle. Les accords en matière de PI-Performance seront déterminés individuellement après attribution du marché et exécution des tests de performances. Actuellement, aucune amende n’y est associée. La PI-Performance proposée actuellement est décrite ci-dessous. En fonction des applications, d’autres aspects de performances seront ajoutés si cela s’avère nécessaire au terme des tests de performances.

E.2.4.9. Service Levels en matière de traitement d’incidents, d’interventions correctrices et réactives ;

Ce SLA aura notamment trait :

à la disponibilité du help desk de 2e ligne de l’adjudicataire pour la résolution de problèmes techniques ;

au délai d’intervention maximal pour la réparation et/ou la résolution de défauts ou de bugs (voir plus loin dans cette section « niveaux de priorité pour les actions correctrices et réactives »).

Objectifs

Définition La Performance de l’application renvoie au temps qui s’écoule entre le moment de réception d’une demande au niveau du Reverse Proxy et le moment de la réponse à cette demande par le Reverse Proxy.

ATTENTION : Par conséquent, le temps de traitement du Prestataire de services ne comprend pas :

o Le temps requis pour le transport par internet

o Le temps requis pour le traitement par le réseau de l’Utilisateur

Méthode de mesure Les données sont mesurées au niveau du Reverse Proxy. Les calculs se font sur la base de logs quotidiens de WebLogic ; le point de référence est le context root de l’application.

Formule de calcul Le rapport entre le nombre de résultats avec un temps de réponse inférieur à Y secondes et le nombre total de résultats (exprimé en pourcentage).

Période de calcul La performance est calculée et rapportée chaque trimestre. High –Incident très urgent qui doit être traité au plus vite


Résultat à atteindre Par exemple, X % < Y secondes

Normes à définir en concertation après exécution des tests de performance individuels requis après l’attribution du marché.


La disponibilité du help desk et la réactivité de l’adjudicataire seront :

fournir une assistance technique les jours ouvrables du SPF Finances entre 7h00 et 19h00 pour les applications Service Window 7x24x365 et les applications Service Window-5x12.

IMPORTANT En dehors de ces heures, l’adjudicataire organisera un help desk de deuxième ligne pour la Service window 7x24x365.

À partir du moment où les demandes sont attribuées à l’équipe de support du soumissionnaire, le SPF FIN exige une acceptation formelle de la demande dans les délais convenus (Incident Response Time). Ces délais sont fixés en fonction de la priorité de la demande.

Un délai de résolution maximal est également défini par niveau de priorité (Incident Resolution Time).

La notification des incidents s’effectue via un collaborateur mandaté du SPF FIN (Service Desk SPFFIN, …).

Pour chaque incident constaté, quelle qu’en soit la nature, le SPF Finances dressera un ticket d’incident et le transmettra à l'adjudicataire. Ce ticket comportant un numéro d'identification unique permettra de suivre la résolution de l'incident et sera à la base du contrôle de la qualité des prestations fournies. Ce ticket sera encodé dans un système de suivi des incidents qui est à la disposition l’adjudicataire.

Si un incident est transmis au help desk de 2e ligne de l’adjudicataire, une référence unique de l’enregistrement dans la gestion des incidents de l’adjudicataire sera transmise au SPF Finances. Ce, soit selon une procédure formelle à convenir, soit via une méthode automatique que l’entrepreneur met à la disposition du collaborateur mandaté du SPF Fin.

Sur ce ticket, l’adjudicataire doit compléter tous les éléments requis par rapport à la résolution de l'incident, conformément au SLA qu’il a signé dans le cadre de son offre.

E.2.4.9.1. Priorités quant aux incidents Priorités relatives aux incidents pour les interventions correctrices et réactives Description et critères

Priorité 1 Major incident – Impact important sur le processus de travail. Service indisponible pour l’ensemble des utilisateurs. Service bloqué ou défectueux pour l’ensemble des utilisateurs, baisse importante de la performance entraînant l’impossibilité d'utiliser le service. Aucune alternative utilisable n’est disponible.

Priorité 2 High Priority – Incident bloquant ou grave Les incidents qui ont un impact sensible sur une partie du service. Aucune alternative utilisable n’est disponible.

Priorité 3 Medium Priority – Incident superficiel sans impact sur les fonctions opérationnelles du service. Le service ne fonctionne pas comme il devrait, mais est disponible avec


un impact minimal ou grâce à une alternative utilisable. Tous les incidents business qui ne sont ni P1, ni P2 et pas single user.

Priorité 4 Normal Priority - Incident mineur ou service request, impact sur un seul utilisateur business. Pas d’impact business ou problème fonctionnel minime. Toutes les requests ou les tickets de plainte du business.

E.2.4.9.2. Matrice des priorités Matrice d’urgence / d’impact pour les décisions autour de la priorité d’incidents en cas de doute :

Urgence Faible Moyenne Élevée Critique

Impact

Risque faible 4 4 3 3

Risque modéré 4 3 3 2

Risque élevé 3 3 2 2

Risque très élevé 3 2 2 1

Définitions de l’impact sur le business :

Very High Risk – Impact sur un département complet ou un délai de livraison/service critique ou impact important sur le business sans solution d'urgence réalisable pour le business

High Risk – Impact sur un grand groupe d’utilisateurs ou impact moyen sur le business sans solution d’urgence réalisable pour le business

Moderate Risk – Impact sur un groupe spécifique ou sur plusieurs utilisateurs, ou faible impact sur le business

Low Risk – Impact sur un seul utilisateur Définitions d'Urgence

Critical – Incident grave qui doit être traité en priorité, en situation de gestion de crise

High –Incident très urgent qui doit être traité au plus vite

Average – Incident urgent qui doit être traité rapidement

Low – Incident sans urgence E.2.4.9.3. PI-Incident-Response-Time

Délai d’acceptation des tickets de help desk selon le niveau de priorités (Incident Response Time KPI).

Retour Incidents ou Incident-Response-time.

Objectifs

Définition Effectuer un retour sur la base d'un incident notifié par le collaborateur mandaté par le SPF Finances avec:

un (premier) contrôle de l’exhaustivité de l’incident notifié

un (premier) contrôle de l’exactitude du transfert


E.2.4.9.4. PI-Incident-Resolution-Time

SLA délai max. pour la réparation et/ou la résolution de pannes (Résolution d'incidents – Incident Resolution Time KPI)

8 Indien de FOD Financiën vaststelt dat een aangeboden oplossing x in praktijk geen afdoende oplossing biedt,

geldt het tijdstip van de aanbieding van oplossing x niet bij het berekenen van deze KPI.

Méthode de mesure

Via le système de gestion des incidents du SPF Finances ou de l’adjudicataire (help desk de 2e ligne)

Formule de calcul

Moment d’acception du ticket par le groupe de support de l’adjudicataire-Moment de notification de l’incident par le SPF FIN

Période de calcul

Trimestrielle

Résultat à atteindre Priorité 1

100 % dans 30 minutes après attribution de l’incident au groupe de support de lu soumissionnaire

Priorité 2 100 % dans 30 minutes après attribution de l’incident au groupe de support de lu soumissionnaire

Priorité 3 100 % dans 30 minutes après attribution de l’incident au groupe de support de lu soumissionnaire

Priorité 4 100% dans 30 minutes après attribution de l’incident au groupe de support de lu soumissionnaire

Objectifs

Définition Dès l’instant où les demandes (tickets) sont attribuées à l’équipe de support du soumissionnaire, le SPF FIN exige les délais de réception suivants (Incident Resolution Time) selon les niveaux de priorité

Méthode de mesure

Via le système de gestion des incidents du SPF Finances et le système de gestion des incidents de l’adjudicataire (help desk 2e ligne adjudicataire)

Formule de calcul

moment d’enregistrement « incident resolved »8 dans le système de gestion des incidents – moment d’attribution au groupe de support

Période de calcul

Trimestrielle

Résultat à atteindre Niveau de priorité Délai de résolution (Incident Resolution Time)

1 100 % dans 4 heures après attribution de l’incident au groupe de support du soumissionnaire

2 80 % dans les 24 heures et 100 % dans les 48 heures après attribution de l’incident au groupe de support du soumissionnaire


E.2.4.10. Service Levels concernant les services du personnel mis à disposition par l’adjudicataire.

E.2.4.10.1.PI-BID-reactiveness

E.2.4.10.2. PI-Staff-Timesheet

Remarque : Dans ses timesheets, l’adjudicataire indiquera clairement les heures réellement prestées avec heure de début et de fin, compte tenu des pauses légales prévues qui ne peuvent pas être intégrées aux prestations fournies.

3 80 % dans les 2 jours ouvrables et 100 % dans les 4 jours ouvrables après attribution de l’incident au groupe de support du soumissionnaire

4 100% dans 5 jours ouvrables après attribution de l’incident au groupe de support du soumissionnaire

Retour des incidents : o Toutes les 2 heures de travail pour les incidents de priorité 1 o Toutes les 4 heures de travail pour les incidents de priorité 2 o Toutes les 12 heures de travail pour les incidents de priorité 3

Si pas encore résolu, escalade vers le service manager : o Après 5 heures de travail pour les incidents de priorité 1 o Après 12 heures de travail pour les incidents de priorité 2 o Après 1 semaine pour les incidents de priorité 3

Objectifs

Définition Délai de réponse de la société après réception du bon de commande pour fournir le personnel.

Méthode de mesure Manuelle

Formule de calcul Nombre de jours ouvrables entre la réception du bon de commande et la présence effective du personnel demandé

Période de calcul Date de réception du bon de commande par courrier recommandé

Résultat à atteindre Personnel présent max. 10 jours ouvrables après réception du bon de commande.

Objectifs

Définition Fournir des timesheets avec les prestations individuelles du personnel qui travaille sur le projet sur base mensuelle.

Méthode de mesure Remise officielle du timesheet en deux exemplaires, signés par le représentant de l’adjudicataire et celui du SPF Finances

Formule de calcul Date de remise – 1er jour ouvrable qui suit la période de rapportage trimestrielle


Résultat à atteindre Dans les 10 jours ouvrables à partir du 1er jour ouvrable du mois, 90% de tous les timesheets pour tous les projets en cours pour l’adjudicataire.


Le nom de la personne (et éventuellement son profil) qui a effectué les prestations sera indiqué, ainsi qu’une brève description des prestations effectuées. Si un pool de prestations prévues est utilisé, les prestations qui restent à effectuer seront mentionnées sur le timesheet.

E.2.4.11. Service Levels relatifs au lot 6 Testing.

E.2.4.11.1. Sommaire Les KPI spécifiques pour le lot 6 « Testing » sont répartis en trois catégories :

Test project Test quality Test process performance

Les KPI de la catégorie « Test project » sont :

PI-Actualized-testing-effort- burn- down-rate (management KPI only for reporting) Les KPI de la catégorie « Test Quality » sont :

PI-Test execution coverage PI-Test build coverage PI-Defect detection ratio

Les KPI de la catégorie « Test process performance » sont :

PI-Test-efficiency PI-Test-case-automation

E.2.4.11.2. KPI Test project

E.2.4.11.2.1. PI-Actualized-testing-effort- burn- down-rate (management KPI)

E.2.4.11.3. KPI Test project

E.2.4.11.3.1. PI-Test execution coverage

Objectifs

Définition Tous les efforts déployés par rapport à l’effort nécessaire actualisé

Méthode de mesure Activités dans Sharepoint

Formule de calcul Efforts de test actuels/efforts de test estimés jusqu’à achèvement

Période de calcul En fonction de la période de test

Résultat à atteindre Max. 100% par projet

Objectifs


E.2.4.11.3.2. PI-Test build coverage

E.2.4.11.3.3. PI-Defect detection ratio

E.2.4.11.4. KPI testing process performance

E.2.4.11.4.1. PI-Test-efficiency

Définition Exigences (requirements) associées aux test cases exécutés

Méthode de mesure Dans HP ALM

Formule de calcul Nombre d’exigences (requirements) testées / nombre d’exigences (requirements)


Résultat à atteindre Au moins 90 % à la fin du projet de test

Objectifs

Définition Exigences (requirements) qui ont été couvertes par les test cases par projet


Formule de calcul Nombre d’exigences (requirements) couvertes / nombre d’exigences (requirements)


Résultat à atteindre Min 90%

Objectifs

Définition Défauts manqués durant l’exécution du test qui passent dans la production. Mesurés par projets

Méthode de mesure HPALM + HP Service manager

Formule de calcul Nombre de manquements / (nombre de manquement + nombre de manquements post-release)

Période de calcul Cycle de release du projet

Résultat à atteindre Min. 90% par projet

Objectifs

Définition Performance effective vs performance attendue pour l’exécution des test cases

Méthode de mesure Sharepoint (test plan + activités)

Formule de calcul Efforts attendus pour l’exécution des tests/efforts actuels pour l’exécution des tests



E.2.4.11.4.2. PI-Test-case-automation

E.2.4.12. Périodes d’application des différents SLA

Service Levels Période de validité

Environnements

1. Service Levels relatifs à la gestion de projet :

À partir de l'attribution D-A-T-P

2. Services Levels relatifs à la phase de

développement

De l’attribution à la mise en production

D-A-T-P

3. Service Levels relatifs à la mise en production

De la mise en production à la fin de la mise en production

D-A-T-P

4. Service Levels exigences non fonctionnelles

Á partir de la mise en production

P

5. Service Levels concernant le traitement d’incidents, les interventions correctrices et réactives

Á partir de la mise en production

D-A-T-P

6. Service Levels concernant les services du personnel mis à disposition par l’entrepreneur :

À partir de l'attribution D-A-T-P

7. Service Levels relatifs au lot 6 Testing.

À partir de l'attribution A-T et éventuellement D-P nécessaire à évaluer par projet

E.2.4.13. Amendes

Le non-respect d’un élément déterminé du SLA est sanctionné d’une amende standard. Le SPF Finances n’a nullement l’intention de comprimer les frais par le biais d’amendes, mais d’encourager l’adjudicataire à respecter toutes les conventions afin de toujours garantir la prestation de services.

Résultat à atteindre Min 90%

Objectifs

Définition Pourcentage de test cases automatisés/ nombre de test cases préparés


Formule de calcul Nombre de test cases automatisés/ nombre de test cases préparés


Résultat à atteindre Le minimum doit être défini dans chaque offre ou chaque année


Les clauses de pénalité préétablies sont reprises dans le tableau récapitulatif des KPI à l'annexe x où sont également indiqués les Indicateurs de performance.

E.2.4.14. SLA monitoring, rapportage et analyse, Concertation du Service Management

E.2.4.14.1. Monitoring du SLA :

E.2.4.14.1.1. Base de contrôle au sein du SPF Finances

Le SPF Finances procède à une supervision permanente de toutes ses applications via, d’une part, le monitoring des composants et du système et, d’autre part, le test permanent de toutes les applications importantes par l’exercice d’activités synthétiques d’utilisateur final. Ces tests synthétiques sont créés par la monitoring team du SPF Finances sur la base d'un scénario fourni (screenshots) et des données de connexion nécessaires à un utilisateur test. Les actes posés par cet utilisateur test sont gratuits et ne doivent pas être repris dans les statistiques. Pour cet utilisateur test, il convient de respecter les mesures de sécurité nécessaires. On dispose, en ce qui concerne cette disponibilité mesurée, de plusieurs rapports qui peuvent être utilisés pour contrôler les SLA. Pour plus d’informations sur cette simulation d’utilisateur final, nous vous renvoyons aux Fondements ICT publiés sur l’internet, à savoir :

Néerlandais : http://financien.belgium.be/nl/over_de_fod/geschiedenis_modernisering/ict/ict_fundamenten/

Français : http://finances.belgium.be/fr/sur_le_spf/historique_modernisation/ict/ict_fundamenten/

plus précisément le chapitre ABB 9.1.1 End-to-End Monitoring et mesures service level

E.2.4.14.1.2. Assistance dans le cadre du monitoring par l’adjudicataire

Dans le cadre du présent marché, la société collaborera à l’établissement et à la validation d’un scénario de base et aidera à élaborer les éventuelles adaptations occasionnelles, si une version adaptée /mise à jour d'une application est déployée. Le coût de l'assistance pour établir ce monitoring de base et des éventuelles adaptations dans le courant du projet est compris dans le prix de la maintenance annuelle et des projets supplémentaires. Les résultats du monitoring seront utilisés pour le rapportage SLA et peuvent être mis à disposition de l’adjudicataire pour les traiter dans son rapportage SLA trimestriel. Le SPF Finances fournira à l’adjudicataire les données liées au monitoring pour le 10e jour ouvrable du mois prochain. Si des manquements sont constatés, le monitoring lancera la procédure de règlement des incidents avec l'enregistrement nécessaire.


L’adjudicataire se déclarera d’accord avec cette méthode de travail pour mesurer la disponibilité. Avec l’équipe de monitoring, l’adjudicataire conclura les accords requis lors du lancement du projet. En cas de doute, il peut faire effectuer à sa charge un audit du système de monitoring des Finances pour vérifier la fiabilité des mesures, et ce pour la partie qui lui importe. E.2.4.14.2. Rapportage SLA, Reviews, PI-SLR

E.2.4.14.2.1. Service Level Reporting (SLR) général – exemple de rapports

IMPORTANT Le soumissionnaire est tenu de joindre à l’offre un exemple de rapports Service Level Reporting (SLR) sous peine de nullité de l’offre.

Ce rapportage service level (SLR) a trait aux activités sous-traitées à l’adjudicataire par le SPF Finances et qui ont trait aux services dans le cadre du présent cahier spécial des charges. Le point de départ est qu’il faut faire rapport e.a. sur les indicateurs de service mesurables repris dans le SLA. La mesure et le rapportage ont lieu chaque trimestre :

L’adjudicataire fournit le rapportage au plus tard 15 jours ouvrables après la fin de la période. Lors d’un stade ultérieur, il se peut que certains rapportages n'aient pas de valeur ajoutée ou que seules les exceptions doivent être reprises pour certains indicateurs de service. Ceci peut mener à une correction de cette structure de rapportage. Les changements dans les service levels mêmes peuvent également entraîner l’adaptation de la structure de rapportage. Le soumissionnaire formulera une proposition de rapports trimestriels (SLR) sous la forme d’un document exploitable qui indique les niveaux de SLA atteints. Si des incidents de priorité 1 et 2 ou des « SLA breaches » importantes se produisent, l’adjudicataire établira un rapport SLR intermédiaire avec les éléments clés devant permettre de suivre les projets et de les présenter aux services concernés du SPF Finances (Reviews). Au besoin, une réunion SLA mensuelle « by exception » sera organisée. Tous les trois mois, une réunion SLA au sein du SPF Finances est organisée sur place, où le Service Level Report trimestriel est abordé. Ensuite, les résultats sont soumis au groupe de pilotage. Un exemple de rapport SLR possible sera joint à l’offre afin que la commission d’évaluation puisse l’évaluer (sous-critère). Ce rapport SLR utilisera autant que possible des tableaux récapitulatifs et présentations graphiques.

Le document SLR présenté contiendra entre autres les sujets suivants (liste non restrictive) :

• sur la base de la période écoulée et

• de manière cumulative sur la base des périodes dans l’année en cours.


1. Résultats service level du SLA par rapport aux normes définies (KPI) avec une explication des éventuelles « SLA breaches » (non-réalisation des normes) ; (mensuel et de manière cumulative sur toute l’année)

2. Proposition de SIP pour éviter les « SLA breaches » à l’avenir ; 3. Statistiques de performance et de disponibilité ; 4. Statut des composants de la solution (si d’application) ; 5. Soumission d’une analyse des tendances au groupe de pilotage sur la base des

résultats des trimestres passés… ; 6. Aspects liés à la sécurité (correctifs, scanning, journaux, auditing…) ; 7. Rapports d’incidents (détails sur les incidents par catégorie, Incident Response et

Resolution Time…) ; 8. Le « Request For Changes » durant la période de référence ; 9. Analyse des incidents en ce qui concerne la gestion des problèmes (recommandation

sur la base d’une analyse de la cause principale) ; 10. Tableau de bord récapitulatif avec rapportage du statut de projet pour le

management, qui sera soumis aux groupes de pilotage trimestriels ; 11. Propositions d’adaptation SLA à soumettre au groupe de pilotage.

E.2.4.14.2.2. PI-SLR

E.2.4.14.2.3. Concertation de Service Management

Cette concertation a lieu comme indiqué dans la matrice ci-dessous :

Nom

Fréquence

Présents

Sujets

Concertation direction

1 * par an

Délégation ICT

Management SPF FIN

Délégation management

adjudicataire

Quality Management SPF

FIN

Service Management

adjudicataire

monitoring contrat et

collaboration

développements

escalade pour la Concertation

de Service Level

Objectifs

Définition Fournir les Service Level Reports à temps

Méthode de mesure Date d’e-mail si par e-mail, date de signature de réception par personne mandatée par le SPF Finances

Formule de calcul Date de réception – 1er jour ouvrable de la période écoulée de rapportage

Période de calcul 3 mois / ad hoc (by exception)

Résultat à atteindre Réception au plus tard le 15e jour ouvrable après la période de rapportage écoulée


Concertation de Service Level

1 * tous les 3 mois

Quality Management SPF FIN

Service Management adjudicataire

Monitoring SLA

Développements, améliorations

Escalade pour la concertation de marché

Concertation de marché

1 * par semaine

Management de marché

SPF FIN

Management de marché

adjudicataire

Intake nouveaux marchés

priorités

plaintes et améliorations

escalade pour concertation sur

le fond

Concertation sur le fond (non formalisé)

Ad hoc gestion des incidents

gestion quotidienne

sur le fond : exécution des flux

de travail

problèmes, améliorations

Une concrétisation détaillée de ces formes de concertation sera reprise dans le DAP.

E.2.4.15. Remarque de clôture

Le SPF Finances peut, s’il le souhaite, faire contrôler et exécuter les mesures du SLA, à ses frais, par un bureau d’études indépendant. Cela ne dégage pas le soumissionnaire de sa responsabilité concernant le suivi et le contrôle des SLA.


E.3. Description du marché

E.3.1. Composante « Développement et Support » (Lots 1 à 5)

E.3.1.1. Mission La mission principale sera de renforcer le département « ICT Development » du service d’encadrement ICT par l’apport d’équipes et de profils externes chargés d’organiser et d’exécuter leur support opérationnel. Remarquez que les aspects liés aux tests fonctionnels et spécifiques qui ne relèvent pas du travail des développeurs sont repris sous le lot 6 « Testing ». Les lots 1 à 5 comprennent notamment les activités suivantes :

Support au Business dans l’élaboration et/ou la formalisation des requirements et des analyses fonctionnelles

Analyse technique

Développements

Tests unitaires

Tests d'intégration de composants

Intégration avec la partie « Tests » prévue au lot 6 (collaboration, planification intégrée, transfert d’informations, ….)

Rédaction / mise à jour des délivrables prévus dans le projet conformément aux standards du SPF Finances (par exemple les documents FUP)

Support à la production (notamment support au diagnostic technique et/ou fonctionnel).

Support à la production par la livraison de scenarii de monitoring end-2-end permettant la mesure du niveau de fourniture de service

Support aux équipes de test (entre autres par l’assistance à fournir lors du déploiement de nouvelles versions de l’application)

Support au Business par la fourniture de données d’analyse et/ou statistiques

Soutien du service desk et prévision d’un helpdesk de deuxième ligne

Participer à des audits de qualité pour l’application ou le service concerné La méthode à suivre est décrite dans le paragraphe « E.2.1.3.5 Cycle de maintenance ». E.3.1.2. Profils

Pour la réalisation des marchés partiels, le SPF Finances souhaite faire appel aux profils ci-dessous. Le soumissionnaire pour ce marché doit utiliser ces dominations dans les réponses et descriptions de son offre. Il devra également se référer explicitement à ces profils dans les CV présentés. Remarquez également que l’adjudicataire devra se référer à ces profils dans ses offres (work breakdown, planning, calcul des prix…). Les compétences et l’expertise doivent être démontrées à l’aide de CV et du tableau joint en annexe. Pour l’expérience, la classification ci-dessous s’applique :


starter: moins de 1000 heures d’expérience réelle dans l’expertise concernée

junior: entre 1000 et 3500 heures d’expérience réelle dans l’expertise concernée

senior: entre 3500 et 10000 heures d’expérience réelle dans l’expertise concernée

expert: plus de 10000 heures d’expérience réelle dans l’expertise concernée

E.3.1.2.1. Task Manager Le Task Manager : dont les activités principales sont la planification, la communication, la gestion (pouvant être intégrale, en ce compris le rapportage selon les prescriptions du SPF Finances) du projet et la gestion de son équipe et des tâches et activités des personnes associées à une maintenance donnée ou au projet. Expertise exigée :

gestion de projets Java-EE

méthodologies Agile et/ou méthodologie Prince2

compréhension d’UML E.3.1.2.2. Technical Architect Le Technical Architect : dont les activités principales dont de maîtriser, d'intégrer, d'expliquer, d'imposer, de contrôler, de coacher, de communiquer, d'être représentant au comité tactique, au cab ou à tout comité qui requiert son expertise, et ce, en regard de la mise en application des standards techniques et méthodologiques du SPF finances; il joue aussi le rôle d'assurance projet pour le Task Manager. Expertise exigée :

Architecture de Java/applications JEE

techniques de communication entre applications

design patterns

Création de diagrammes en architecture ULM

design interface application web E.3.1.2.3. Business Analist Le Business Analist : notamment chargé d’assister le business à la capture des besoins – conformément à la discipline FUP-D1 ou autre méthodologie assimilée (au choix du SPF Finances), essentiellement chargé - conformément à la discipline FUP-D2 ou autre méthodologie assimilée (au choix du SPF Finances), - d'analyser et de formaliser les requirements métier, avec une approche Use-Case centric, et la coopération avec le business et les testeurs. Expertise exigée :

analyse des applications JEE

analyse et conception de modèles de données

analyse et création de Use cases ULM E.3.1.2.4. Développeur technologie JEE Junior


Le Développeur : notamment chargé du développement applicatif Java/JEE complet et autres systèmes/technologies en dépendance, de la documentation technique, du déploiement (y compris la réalisation des documents et l'utilisation des processus et outils), des tests élémentaires (unitaires, intégration), et de comprendre les autres langages de programmation. Expertise exigée :

Java Core

Java EE Basic (EJB + JDBC + JPA)

Unit Testing

comprend UML E.3.1.2.5. Développeur technologie JEE Senior Le Développeur : notamment chargé du développement applicatif Java/JEE complet et autres systèmes/technologies en dépendance, de la documentation technique, du déploiement (y compris la réalisation des documents et l'utilisation des processus et outils), des tests élémentaires (unitaires, intégration), et de comprendre les autres langages de programmation. Un développeur senior a au moins 3500 heures d’expérience réelle dans les compétences de base (voir développeur junior) et les compétences complémentaires. Expertise exigée :

comprend UML

Maven

Java EE Advanced (JAX-WS + JAXB + JAXP + JMS + JNDI)

Design Patterns 3.1.2. Composition de l'équipe Ce marché est subdivisé en cinq lots « Entretien et développement » et un lot « Tests ». Le SPF Finances se base sur la composition minimale suivante par lot :

Profil Capacité minimale lots 1, 2 et 3 (ETP)

Capacité minimale lots 4 et 5 (ETP)

Task Manager 1 1

Technical Architect 1 2

Business Analist 2 3

Développeur technologie JEE Junior 2 4

Développeur technologie JEE Senior 2 4

L’adjudicataire s’engage à avoir en permanence l’équipe minimale décrite ci-dessus à la disposition du SPF Finances pendant la durée du marché (voir aussi par. D.6.4.2. Capacité collaborateurs). Cet engagement est une prescription technique qui mène à une offre irrégulière si elle n’est pas rencontrée, et à des pénalités éventuelles en cas d’exécution incomplète de l’offre.


Le soumissionnaire doit démontrer dans son offre qu’il dispose de la capacité nécessaire pour fournir cette équipe minimale pendant toute la durée du marché. Il indiquera notamment :

le nombre de personnes qui entrent en considération pour chacun des profils demandés

le nombre de ces personnes qui sont disponibles ou peuvent être rendues disponibles à court terme

la réserve dont il dispose pour compenser la rotation de personnel

sa stratégie pour acquérir de nouveaux profils

sa stratégie pour pourvoir aux éventuelles compétences manquantes

… (toutes les informations que le soumissionnaire estime pertinentes pour appuyer sa candidature concernant la mise à disposition obligatoire d’équipe ou de profils)

Sauf exception dûment justifiée, les personnes dont les CV sont présentés dans l’offre doivent être présentes dans l’entreprise depuis au moins six mois (à la date de l’ouverture des offres concernées). Si la firme ne peut remplir ces obligations d’ancienneté dans les matières nécessaires, une période d’on-boarding de deux mois est autorisée. Pendant cette période, la firme s’engage à former (25 à 50% d’un ETP) le nouveau membre de l’équipe et à le mettre à la disposition du SPF (le reste du temps) gratuitement. La firme démontre cela par un rapport sur les formations suivies – ces dernières doivent concerner la matière manquante – et les prestations effectuées. Personnel mobilisé par l’adjudicataire par projet Pour l’exécution des projets, le soumissionnaire doit proposer les profils de base via sa liste de prix (avec un prix par profil) et les CV concernés. Il précise les compétences de chaque profil. Les compétences décrites dans ce cahier des charges sont à considérer comme un minimum et doivent au moins correspondre au niveau « senior » par compétence.

a. Vu l’importance des compétences des personnes proposées par le soumissionnaire, le SPF Finances demande que les CV soient soigneusement rédigés (en fonction des profils décrits dans ce cahier des charges) et mis en relation avec le présent marché. L’expérience requise constitue à ce titre un critère absolu. Une offre dont les CV ne permettraient pas de s’assurer du respect des minima exigés sera d’office pénalisée et pourra donner lieu à l’arrêt du marché.

b. Étant donné le contexte bilingue dans lequel l’équipe de l’adjudicataire sera amenée

à évoluer, le bilinguisme (FR/NL) de l’équipe est requis. Il faut pour ce faire qu'au moins 80% de l'équipe ait le français ou le néerlandais comme langue maternelle et que les deux langues nationales soient représentées au sein de l'équipe."

c. L’attention du soumissionnaire est également attirée sur le fait que le SPF Finances

entend que les conditions évoquées aux points a) et b) ci-dessus devront être respectées tout au long du contrat.

Continuité en cas d’arrêt d’un projet ou d'un programme Le soumissionnaire doit garantir que les mesures sont prises pour garantir la sûreté et la continuité du marché s’il n’est pas en mesure de le poursuivre (p.ex. en cas de faillite).


Continuité du service et pool de connaissances L’adjudicataire prendra toutes les mesures nécessaires pour développer un centre de connaissances, afin que les nouveaux membres de l’équipe (internes et externes) puissent s’intégrer rapidement et efficacement dans la partie de la mission qui leur incombe. Il en va de même des éventuels remplacements au sein de l’équipe. Le soumissionnaire peut développer la description de son service sur ce plan. Vu la longue durée du marché, le soumissionnaire prévoit aussi de donner la formation nécessaire à ses collaborateurs si le besoin s’en fait sentir, sans frais pour le SPF Finances. Le soumissionnaire décrit les connaissances et l’expérience qu’il peut mobiliser à tout moment pour exécuter le marché (y compris les références et CV). La description couvre aussi ce que le soumissionnaire peut offrir en tant qu’entité au SPF Finances en termes de connaissances et d’expérience (autrement dit les capacités utiles du « pool » d’employés dans lequel le soumissionnaire peut puiser si nécessaire). Disponibilité Il est clair qu’au fil d’un marché de cette nature, la charge de travail peut varier sensiblement. L’adjudicataire doit pouvoir y réagir adéquatement. La charge est notamment influencée par les périodes de vacances, les pointes de travail, la nécessité de grands changements, mais aussi le niveau d’importance (bas, moyen, haut, critique) des changements demandés ou des incidents. Le soumissionnaire indique clairement dans quelles marges il réagira et comment. Back Office Le soumissionnaire décrit par ailleurs le support qu’il peut assurer en vue d’un bon suivi du marché, autrement dit le « back-office ». On songe notamment ici à la rapidité de réaction de l’adjudicataire, à la qualité de la communication et de manière générale à tout ce qui peut favoriser une bonne collaboration de l’adjudicataire avec le personnel du SPF Finances ainsi que la bonne exécution du marché. Le soumissionnaire indique aussi comment il voit la collaboration dans les équipes composées d'employés de sa société et de personnes dépêchées par le SPF Finances. E.3.1.3. Support technique par téléphone – service desk – ITIL Les projets de maintenance comprendront un support par téléphone en 2e ligne. Le service demandé ci-dessous doit être assuré les jours ouvrables de 7h à 19h. Le SPF Finances met un service desk à la disposition de tous les utilisateurs finaux. Le service desk assure le traitement de tous les types d’appels. Le soumissionnaire installera un helpdesk de deuxième ligne pour recueillir les problèmes liés au non-fonctionnement ou au mauvais fonctionnement de l’application dont l’adjudicataire a la responsabilité, pendant toute la durée du projet. Tous les appels que le service desk ne peut résoudre à distance seront aiguillés vers ce helpdesk. En première instance, ce helpdesk sera accessible au service desk du SPF Finances, qui se chargera de toutes les interventions possibles à effectuer sur les logiciels à entretenir.


Les services proposés par l’adjudicataire seront introduits dans le respect de la méthodologie ITIL, appliquée au sein du SPF Finances. Cela signifie notamment que la gestion des incidents, problèmes, changements, etc. doit être conforme aux méthodes en vigueur au sein du SPF Finances. La première ligne se chargera de distinguer les incidents d’infrastructure et les incidents applicatifs. La communication entre la première et la deuxième ligne est décrite par le soumissionnaire. Elle doit permettre à la première ligne de mettre l’utilisateur en contact avec la deuxième ligne si la première soupçonne que l’incident signalé va nécessiter une intervention sur place ou une communication entre deuxième ligne et utilisateur. Dans son offre, le soumissionnaire indique comment il entend appliquer les normes ITIL dans sa tâche et comment il va acquérir les connaissances nécessaires pour s’intégrer dans les processus existants. La transmission des appels entre le service desk du SPF Finances et le helpdesk de deuxième ligne que l’adjudicataire doit mettre en place passera au moins par les canaux suivants : Les canaux suivants doivent au moins être utilisés :

Téléphone et e-mail à la disposition des opérateurs du service desk du SPF Finances.

Automatiquement ou semi-automatiquement, en reliant l’outil du SPF Finances (HP Service Management) à l’outil utilisé par le service manager pour la gestion et le suivi des appels. Le soumissionnaire expliquera dans son offre les canaux qu’il supporte. Il précisera en particulier : o Les moyens dont l’Administration disposera pour contrôler à tout moment l’état

des appels ouverts. o Les moyens dont l’Administration disposera pour contrôler le respect du SLA. o La façon dont il propose éventuellement de synchroniser les deux outils (SPF

Finances et soumissionnaire). o Les rapports qu’il mettra à la disposition du SPF Finances pour le suivi de la

qualité du service. o La méthode éventuelle pour résoudre à distance certains problèmes de

fonctionnement. Le soumissionnaire doit aussi prévoir un retour d’information vers le service desk à propos des appels qui lui ont été transmis ; autrement dit, il doit informer le service desk de la suite qu’il leur a réservée, via un canal préalablement annoncé, canal qui permet le suivi des appels. Le soumissionnaire expliquera le service en tenant compte de tous les points évoqués ici. Il fournira aussi les autres services qu’il juge nécessaires. Tout changement au système entraîne la livraison d’un ensemble de code source et de documentation à inclure dans le système de gestion des versions du SPF Finances. Les changements ne sont effectués qu’après l’accord du SPF Finances. L’adjudicataire transmettra toutes les informations nécessaires à la CMDB (configuration management database), en suivant les procédures imposées par le SPF Finances. Ces procédures seront communiquées après attribution du marché. Elles pourront changer pendant la durée du contrat. Le SPF Finances attire l’attention des soumissionnaires sur la grande importance attachée à la surveillance de l’intégrité de la CMDB. Dans leur offre, les soumissionnaires préciseront clairement les mesures qu’ils proposent à cet effet.


E.3.Composante « Tests (Lot 6).

Le lot 6 du présent marché est relatif à des activités de tests spécifiques aux applications non fiscales du SPF Finances.

E.3.2.1. Marchés

La mission principale sera de renforcer la division Test Management du service d'encadrement ICT par l’apport des testeurs externes afin d’organiser et d'exécuter les tests et maintenues par les équipes de développement au sein du SPF Finances. Il s’agit à travers le lot « Tests » (6) de séparer les activités de test des activités de développement des lots « Maintenance et développement » (1 à 5).

La mission secondaire sera d'apporter de l'aide aux testeurs internes de la division de Test Management afin d'améliorer le processus de test existant

Exécution des tests

Par exécution des tests le soumissionnaire devra remplir les activités suivantes pour le lot Tests :

Réaliser des plans de test détaillés en respectant la méthodologie de test utilisée au SPF Finances (tant pour les tests statiques que dynamiques)

Rassembler les données de tests à utiliser Exécuter les tests d’ensembles logiques (system test & integration test) Test de l’intégralité de l’application (system test : performance, security, functionality

& user acceptance test) en étroite collaboration avec le service de gestion des applications des administrations et service d’encadrement concernés

Créer et automatiser les tests de non régression Aider à l’analyse des résultats Donner du feedback concernant des adaptations (résultats constatés) Rédiger les rapports d’évaluation dans lequel sont mentionnés la qualité constatée et

les résultats, ainsi que les risques liés à l’utilisation des produits Rapporter aux comités de pilotage des risques liés à la qualité des applications Participer à l’amélioration de la qualité de l’application (entre autre par

l’enregistrement des constatations réalisées durant les tests effectués et des résultats des analyses de code).

Réalisation d’un plan de test d’intégration détaillé Fourniture d’assistance aux équipes de test quant à l’amélioration des méthodes de

travail et des techniques de test appliquées, l’extension des sortes de test appliqués et la gestion des environnements de test et données de test.

…

E.3.2.2. Contexte.

E.3.2.2.1. Environnement organisationnel


E.3.2.2.2. Référence

Le soumissionnaire pourra trouver une description de la méthodologie sous la référence :

http://finances.belgium.be/fr/sur_le_spf/historique_modernisation/ict/

E.3.2.2.3. Méthodes de travail

Le SPF Finances souhaite expressément améliorer la maturité du processus de test et des méthodes de test utilisées. Ceci dans le but de mettre des applications de qualité à la disposition des citoyens, des entreprises et des collaborateurs du SPF Finances. Le « leitmotiv » ici, est celui de l'amélioration permanente. On attend des soumissionnaires qu'ils aillent plus loin dans les méthodologies et expertises déjà développées par le passé. L'accent est mis sur les tests fonctionnels, de performance, de robustesse et de convivialité de l'application. De plus, une grande importance est également attachée – par le biais d'une étude statistique du code source des applications – à la maintenabilité et aux caractéristiques de sécurité du code.

http://finances.belgium.be/fr/sur_le_spf/historique_modernisation/ict/


Lors de l'élaboration de l'offre, il faut tenir compte des éléments suivants:

Disciplines de développement décrites dans FUP

Depuis un certain temps déjà, on utilise, le développement des applications repose sur une méthodologie basée sur Unified Process. Cette méthodologie, adaptée aux exigences spécifiques du SPF Finances, est appelée FUP (=Finance UnifiedProcess). Dans le développement des applications reprises dans le scope du présent cahier des charges, les instructions de la méthodologie FUP sont en grande partie respectées. On note toutefois des écarts par rapport à la situation idéale en ce qui concerne la documentation. Il est demandé au soumissionnaire à ce cahier des charges de tenir compte des manquements au niveau du caractère complet de la base de test.

Enrichissements spécifiques de la méthodologie de test : Méthodologie TMv4 et PTC

La méthodologie de test développée pour le SPF Finances est largement basée sur le standard TMAP. Des affinements spécifiques pour l'exécution des tests de performance ont encore été apportés à la méthodologie de test sur la base de la méthodologie STBoX.

Il est demandé au soumissionnaire de décrire à quoi ressemblera son approche. De plus, le soumissionnaire devra également indiquer de quelle manière il prévoit de donner les formations requises à ses collaborateurs pour qu'ils disposent des connaissances nécessaires pour appliquer les méthodologies et les techniques le plus correctement possible.

E.3.2.2.4. Arsenal de tests tools

1. HP ALM

HP ALM (Application life cycle management), version 11.0, forme le cœur de la gestion des tests. Peuvent y être repris les requirements (requirements modifiés ou nouveaux), les définitions de versions, les plans de test et les défauts constatés. Ces tools constituent en outre la base de la gestion des tests effectués et du suivi du test coverage. Via HP QTP (Quick Test Professional) et UFT, cela constitue aussi la base des tests fonctionnels automatisés et des tests de régression automatisés. Le soumissionnaire est censé augmenter significativement le rythme des tests de régression automatisés en cours de mission et élargir progressivement la collection des scripts de test disponibles. Il est demandé au soumissionnaire de décrire sa vision des tests automatisés et d'indiquer son approche dans ce domaine.

2. HP Performance center


Un accent important sera mis sur la gestion de la performance. Un élément central à ce niveau sera le HP Performance center toolset qui permet d'effectuer des stresstests et des loadtests. Toute régression de la performance doit en tout temps être évitée. On attend, au minimum, qu'à chaque release majeur d'une application, un projet loadtest soit effectué dans le but de surveiller la performance. Il est demandé au soumissionnaire de décrire sa vision des loadtests et d'indiquer son approche dans ce domaine.

3. Compuware Dynatrace et DCRUM

Outre les outils destinés à l'exécution des tests, le SPF Finances mettra aussi des outils diagnostiques à la disposition des équipes de développement et des équipes de test. Outre les moyens habituels comme les database client tools, les log file analyse tools et les webservice XML visualisation tools, les principaux outils diagnostiques mis à disposition comprendront aussi les Compuware Dynatrace et DCRUM tools. Ces outils permettront d'étudier le comportement dynamique des applications pendant les tests fonctionnels et les loadtests. On attend du soumissionnaire l'expertise nécessaire pour utiliser ces tools de manière productive. Il est demandé au soumissionnaire de décrire sa vision sur les outils diagnostiques et leur intégration dans des test tools comme HP ALM et HP Performance center.

4. Gestion des données de test

Sur le plan de la gestion des données de test, le SPF Finances a encore devant lui un long trajet d’amélioration à parcourir. Un outil a été acquis qui permet de procéder à des extractions à partir des bases de données de production. Cet outil, appelé SEAL, offre les fonctionnalités suivantes :

Définition de schémas de bases de données en fonction des besoins d'une campagne de tests

Sélection de données à partir des bases de données source Exécution des extractions et création d’une base de données cible Anonymisation de données sur la base de différents algorithmes (aussi bien des

données structurées dans les bases de données que des documents contenus dans les collections de documents dans Filenet)

Conservation des données pour les campagnes de tests Remise des données en leur état initial après l’exécution d’une campagne de tests

Dans la pratique, l’outil SEAL n’est encore que peu utilisé (principalement en raison de l’absence d'environnements de test distincts). Il est demandé au soumissionnaire de décrire sa vision et son approche pratique en matière de gestion des données de test ainsi que d’indiquer comment générer la plus grande valeur ajoutée possible avec les moyens disponibles.


5. Environnement de test

L’environnement de test n’existe pas encore actuellement pour certaines applications comprises dans le scope du présent cahier spécial des charges. Pour les applications pour lesquelles il n’existe pas de disposition D-T-A-P des environnements, le soumissionnaire doit tenir compte du fait que les environnements manquants seront créés pendant la durée du marché (c’est le cas pour la majorité des applications). Il est demandé au soumissionnaire de donner sa vision sur les évolutions souhaitées dans l’aménagement des environnements de test et d’indiquer dans quelle mesure son approche s’écarte de la situation décrite plus haut. Il est en outre demandé au soumissionnaire de mentionner les points d’attention que son expérience lui a montrés comme importants dans la gestion et l’utilisation des différents environnements.

E.3.2.3. Profils.

Les profils proposés sont les seuls à pouvoir être repris dans l’exécution du marché. En cas de remplacement de ces profils, les modifications de profils doivent être soumises à l’accord du SPF Finances sous peine de pénalité. Une même personne peut être reprise dans plusieurs profils différents mais en cas d’offre, le SPF Finances se réserve le choix de la sélectionner dans le profil désiré.

Compétences communes

Tous les profils proposés (P1 – P3) doivent satisfaire à ces exigences sous peine de nullité :

Certification ISTQB obligatoire sous peine de nullité de l’offre. Fournir la preuve de la certification

Maîtrise de la langue française et/ou néerlandaise et connaissance passive de l’autre langue

Minimum 3 ans d’expertise dans le secteur informatique dont 2 ans dans le software testing.

E.3.2.3.1. Testeur

Activités Un testeur est responsable de toutes les activités primaires de test. Ces activités sont réparties sur l’ensemble du trajet de test. Premièrement, le testeur devra préparer les tests. Cela signifie qu’il faudra définir la base du test et qu’il faudra ensuite procéder à un intake sur cette base de test. Deuxièmement, le testeur devra exécuter les spécifications du test. Cela implique l’élaboration de cas de test logiques et la préparation de cas de tests physiques. Pour cette phase, le testeur utilisera les outils de test nécessaires. Ensuite, les tests préparés seront exécutés par un testeur. Pendant l’exécution des tests, le testeur rapportera correctement les éventuels manquements et en assurera le suivi. Pendant cette phase, il sera fait usage des outils de test nécessaires.


Enfin, les résultats finaux des tests seront rapportés par le testeur sous la forme de conclusions, de tests réussis et ratés. Les résultats seront systématiquement complétés de preuves supplémentaires (“test evidence”) par le testeur. Profil Le testeur connaît une méthodologie de test structurée, TMap Next ou STBOX. Le testeur est également capable d'utiliser un des outils de test suivants: HP ALM, UFT ou LoadRunner/Performance Center. Outre ces compétences de nature plus technique, la maîtrise de compétences de communication est également importante dans le cadre du rôle du testeur, car le testeur doit être capable d’entretenir des contacts étroits avec les développeurs, les analystes et les chefs de projet. Le testeur doit être capable d'exprimer ses idées et ses avis de manière claire et structurée, aussi bien oralement que par écrit. Le testeur posera aussi toujours des questions complémentaires pour être certain de tout bien comprendre. Un testeur est capable de collaborer efficacement avec ses collègues et de contribuer à un climat positif au sein de l’équipe pour que le travail puisse être effectué de manière efficiente. Il contribue activement à la réalisation des résultats communs ainsi qu’à la résolution des problèmes ou des conflits. Le testeur dispose aussi des compétences d’analyse nécessaires. Chaque phase des spécifications des tests étant liée à une analyse de la base de test. le testeur devra être capable d’étudier les informations de manière approfondie et critique et d’estimer correctement les interrelations. Le testeur doit également être disposé à assimiler, comprendre et appliquer correctement les différentes méthodes et procédures disponibles. Le testeur doit être capable d’organiser le travail qui lui a été confié de manière efficiente. Pour cela, le testeur formulera des objectifs, planifiera les activités et définira des priorités.

E.3.2.3.2. Spécialiste en test tools

Activités Le spécialiste en outils de test sera d’une part responsable de l’exécution des activités primaires de test (préparation des tests, spécifications des tests, exécution des tests, reporting et suivi des résultats) et d’autre part il devra mettre ses connaissances spécialisées au service de l'équipe et servir de point de contact à ce sujet. Le spécialiste en outils de test devra aussi s’investir dans l’implémentation et le suivi des outils de test (HP ALM, Performance Center, UFT…). Il prendra également en charge le coaching des membres de l’équipe concernant ces outils. Profil Le spécialiste en outils de test dispose des connaissances et de l’expérience nécessaires pour travailler de manière indépendante sans avoir besoin en permanence d’un accompagnement ou de l’aide d’autrui.


Dans son domaine de spécialisation, le spécialiste en outils de test sera capable d'identifier les opportunités et d’agir ou de faire des propositions quand ces opportunités se présentent. Il sera aussi capable de continuer à fonctionner efficacement dans les situations difficiles, sous pression élevée (au niveau du temps) ou face à la résistance et aux oppositions. Le spécialiste en outils de test est capable de donner un avis éclairé dans son domaine d’expertise. Il adapte son style et ses techniques d’avis tant aux personnes auxquelles il s'adresse qu'aux situations. Dans son domaine d’expertise spécifique, le spécialiste en outils de test est capable de mettre en œuvre ses nouvelles idées, de proposer des solutions et de faire des propositions en matière d'amélioration des processus. Le spécialiste en outils de test entreprend (ou soutient) d'initiative des actions qui stimulent le développement professionnel des autres. Il aidera les autres et les accompagnera dans l’exercice de leur fonction.

E.3.2.3.3. Spécialiste en méthodologie de test

Activités Le processus de test dans son ensemble ressortit à la responsabilité du spécialiste en méthodologie de test. Cela signifie que régulièrement (p. ex. tous les six mois ou tous les ans), le spécialiste en méthodologie de test effectuera un TPI®. Les résultats de ce TPI® seront convertis par le spécialiste en méthodologie de test (en concertation avec le Test Manager) en points d’action concrets et repris dans un planning comportant divers jalons. Profil Le spécialiste en méthodologie de test dispose des connaissances et de l’expérience nécessaires en matière de méthodologie de test pour travailler de manière indépendante sans avoir besoin en permanence d’être accompagné ou aidé par quelqu’un d’autre. Profil Au sein de son domaine d’expertise spécifique, le spécialiste en outils de test est capable de mettre en œuvre ses nouvelles idées, de proposer des solutions et de faire des propositions en matière d'amélioration des processus. Au sein de son domaine d’expertise spécifique, le spécialiste en méthodologie de test est capable de mettre en œuvre ses nouvelles idées, de proposer des solutions et de faire des propositions en matière d'amélioration des processus. Le spécialiste en méthodologie de test entreprend (ou soutient) d'initiative des actions qui stimulent le développement professionnel des autres. Il aidera les autres et les accompagnera dans l’exercice de leur fonction.

E.3.2.3.4. Quality Assurance Coordinator

À peine d’exclusion, les Quality Assurance Coordinators proposés doivent, au minimum, disposer des compétences suivantes :

Pouvoir démontrer au minimum 5 ans d’expérience dans un environnement IT, dont minimum 1 an dans une organisation de taille comparable à celle du SPF Finances.


Pouvoir démontrer au minimum 2 ans d’expérience de projet en qualité de responsable du contrôle qualité et/ou de l’assurance qualité dans minimum 2 projets différents.

Certification Prince2 ou PMBOK. Maîtrise des deux langues nationales (français et néerlandais) :

o Maîtrise parfaite (niveau C2 / locuteur natif) du français ou du néerlandais . o Connaissance active et courante de l’autre langue nationale.

Activités Le Quality Assurance Coordinator interviendra principalement en qualité de contrôleur qualité par le biais d’initiatives “deep dive” et la réalisation de reviews concrets pour surveiller le respect des standards ICT du SPF Finances, et plus particulièrement celui du standard FUP (aussi bien les outils que les deliverables). Concrètement, il s’agit, entre autres, des activités suivantes :

Document review van de deliverables; Contrôler l’utilisation correcte des outils (HP ALM, Continuous Integration, …) Contrôler la qualité de la gestion et de la définition des requirements; Contrôler la qualité du code à l'aide des critères de mesure fournis (SonarQube, HP

Fortify, …); Surveiller la qualité des activités de test pour le lot 5; Intervenir et communiquer de manière proactive en cas de constatation

d’incohérences potentielles (et risques) qui surviendraient entre les activités de développement des lots 1 à 5 et les activités de tests du lot 6 ;

… De plus, à la demande de l’adjudicataire, il émettra un avis ad hoc et formulera des instructions en matière de limitation des risques, d’assurance qualité, de santé du projet et d'application des bonnes pratiques. Il identifiera clairement les interdépendances entre les différentes activités du projet et sera capable d’en estimer l’impact et les risques dans le cadre de la surveillance de la cohérence entre les activités exécutées dans le cadre du lot 5 d’une part et les activités des lots 1 à 5 d’autre part. Dans la pratique, le Quality Assurance Coordinator travaillera en étroite collaboration avec les membres du Comité QUAC. Cela signifie que chaque mois, il fera aux stakeholders du SPF Finances un rapport sur les éléments suivants :

Un rapport high level comprenant un aperçu des principaux risques, constatations et recommandations ;

Un rapport d’activités détaillé sur les activités Quality Assurance complétés de rapports de review.

Un planning des activités et des reviews encore à effectuer. Profil Pour pouvoir mener à bien sa mission, le Quality Assurance Coordinator doit disposer des compétences et connaissances suivantes :

Développement applicatif : cette activité exige des connaissances dans le domaine des méthodologies de développement (RUP ou méthodologie similaire), des standards J2EE, des bonnes pratiques en matière de design et de qualité du code, …

Test du software: Cette activité exige des connaissances dans le domaine des différents o niveaux (p. ex. unit testing, system testing, …), o types (p. ex. test de performance), o et sortes (p. ex. stress testing) de tests (voir aussi la description de TMv4 en

annexe).


Cette activité exige également des connaissances en matière de méthodologies de test.

Architecture de l’information : cette activité exige des compétences dans le domaine de la transposition de modèles de domaine en modèles de base de données logiques et physiques.

Infrastructure: dans le cadre du SPF Finances cela implique surtout des connaissances dans le domaine des serveurs applicatifs, des systèmes de gestion, des outils de développement, etc.

Gestion de projets : o Gestion de la communication : communication transparente et obtention de

l’engagement de tous les acteurs du projet o Gestion des risques : sensibilisation permanente aux risques et à la maîtrise des

risques o Gestion des changements

Le Quality Assurance Coordinator:

Crée une base de confiance avec les différents acteurs; Utilise une approche cohérente; Est capable d’entrer en contact avec les bonnes personnes au bon niveau; Applique une méthode de travail très interactive.

Le SPF Finances part de la composition minimale suivante :


lot 6 (ETP)

Testeur 4


Spécialiste en méthodologie de test 2


IMPORTANT Cet appel d’offres ne peut en aucun cas être considéré comme un engagement de la part du SPF FINANCES qui se réserve le droit de ne pas attribuer le marché.

1000 BRUXELLES,


Johan VAN OVERTVELDT Ministre des Finances


F. ANNEXES

1. Formulaire d'offre

2. Modèle de référence

3. Curriculum vitae (annexes 3.a. et 3.b.)

4. SLA Template

5. Tableau KPI

6. Description des applications


Annexe 1 : FORMULAIRE D’OFFRE

SERVICE PUBLIC FÉDÉRAL Finances Service d'encadrement Logistique Division Achats North Galaxy - Tour B4 - boîte 961 Boulevard du Roi Albert II, 33 1030 BRUXELLES

CAHIER SPECIAL DES CHARGES N° : S&L/DA/2016/060

La société :

(dénomination complète)

dont l’adresse est:

(rue) (code postal et commune) (pays)

immatriculée à la Banque Carrefour des Entreprises sous le numéro:

et pour laquelle Monsieur/Madame9

(nom) (fonction)

domicilié(e) à l’adresse:

(rue) (code postal et commune) (pays)

agissant comme soumissionnaire ou fondé de pouvoirs et signant ci-dessous, s’engage à exécuter, conformément aux conditions et dispositions du cahier spécial des charges n° : S&L/DA/2016/060, les services définis aux prix forfaitaires unitaires mentionnés ci-après, indiqué en lettres et en chiffres, libellés en EUROS, hors TVA et TVA comprise, de :

9 Biffer la mention inutile

Appel d'offres ouvert relatif à l'entretien au développement et au test des applications pour

le compte du SPF Finances


Lot 1 : Entretien (spécifique) de Zacheus, e-Notariat, Finprof, e-Deduction (SAFS CV), Avis

de saisie (FCA), ...

PROFIL

Prix unitaire (hors TVA) par HOMME/JOUR en euros (en chiffres et en lettres)

Prix unitaire (TVAC) par HOMME/JOUR en euros (en chiffres et en lettres)

Task Manager

Technical Architect

Business Analist

Développeur technologie JEE Junior

Développeur technologie JEE Senior

Lot 2 : Entretien (spécifique) de Stipad,...

PROFIL



Task Manager

Technical Architect

Business Analist




Lot 3 : Entretien (spécifique) de FSP, Pandora, Cautionnements solidaires (SP10A),

Faillites (SP10B), Grootboek/Grand Livre, CDC Dmat., …

PROFIL



Task Manager

Technical Architect

Business Analist



Lot 4 : Entretien (général)

PROFIL



Task Manager

Technical Architect

Business Analist




Lot 5 : Nouveaux développements (général)

PROFIL



Task Manager

Technical Architect

Business Analist



Lot 6 : Tests (général)

PROFIL



Testeur

Spécialiste en test tools

Spécialiste en méthodologie de test

Quality Assurance Coordinator


Lot(s) pour le(s)quel(s) le soumissionnaire remet offre : Soumission : indiquer par OUI ou par NON les lots pour lesquels vous introduisez ou non une offre. Priorité : indiquer à l’aide d’un chiffre différent compris entre 1 et (maximum) 6 votre priorité pour les lots pour lesquels vous soumissionnez (1 est la plus haute priorité).

LOTS Soumission pour le lot (OUI/NON)

Priorité du lot (1 « élevée » à

6 « basse)

Lot 1 : Entretien (spécifique) de Zacheus, e-Notariat, Finprof, e-Deduction (SAFS CV), Avis de saisie (FCA).

Lot 2 : Entretien (spécifique) de Stipad.

Lot 3 : Entretien (spécifique) de BBF, Pandora, Cautionnements solidaires (SP10A), Faillites (SP10B), Grootboek/Grand Livre, CDC Dmat.

Lot 4 : Entretien (général)

Lot 5 : Nouveaux développements (général)

Lot 6 : Tests (général)

J’autorise l’administration à prendre toutes les informations utiles tant de nature financière que morale sur moi-même, auprès d'autres instances ou organismes. La présente inscription comprend l’engagement de faire parvenir à l’administration sur simple demande et dans les meilleurs délais les documents et certificats dont elle exigerait la présentation en application du cahier spécial des charges ou en application de la réglementation relative à la conclusion de contrats pour le compte de l'État. 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. Les informations confidentielles et/ou les informations qui se rapportent à des secrets techniques ou commerciaux sont clairement indiquées dans l’offre. Les sommes dues seront payées par l’organisme de paiement du pouvoir adjudicateur par virement ou versement sur

le compte n°: IBAN BIC


Pour l’interprétation du contrat, la langue

néerlandaise/française10

est choisie pour l’interprétation du contrat.

Toute correspondance concernant l’exécution du marché doit être envoyée à l’adresse suivante :

(rue) (code postal et commune) (n° et n° ?) (adresse e-mail)

Fait: À Le 20…..

Le soumissionnaire ou le mandataire :

(nom) (fonction) (signature)

APPROUVE,

POUR MÉMOIRE : DOCUMENTS A JOINDRE OBLIGATOIREMENT A L’OFFRE: - Tous les documents et renseignements demandés dans le cadre de la sélection

qualitative et des critères d’attribution (voir point 5 du volet C. Attribution) ; - Annexe obligatoire 3a et 3b

N’oubliez pas de prévoir une numérotation continue de toutes les pages de votre offre, ses annexes.

10 Biffer la mention inutile


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

1. Nom du projet …………………………………………………………………….

2. Nom de l’entreprise ……………………………

3. Secteur d'activité …………………………………………………………………….

4. Nom de personne de contact ……………………………

5. Coordonnées …………………………………………………………………….

6. Portée du développement ou du projet ……………………………

7. Objectifs visés …………………………………………………………………….

8. Date de début (par phase) - …………………………… - ……………………………

9. Date de fin ……………………

10. Budget (euros) ……………………………

A. Matériel informatique ……………………

B. Logiciels ……………………

C. Services ……………………

11. Résumé et brève description du rôle et de la part des éventuels sous-traitants

A. Nom de la ou des entreprise(s) ……………………

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

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

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



C. Environnement de développement ……………………

14. Résumé et brève description des systèmes pour la réalisation du projet



C. Environnement de développement ……………………

15. Méthode de gestion de projet

Instrument/méthode …………………………………………………………………….

16. Aperçu des profils affectés au projet ; (nombre (TOTAL) de personnes et hommes-jours pour le projet complet

Profil 1 ……………………

Profil 2 ……………………

Profil 3 ……………………

Profil 4 ……………………

Profil 5 ……………………

Profil ……………………


Annexe 3.a.: Curriculum Vitae – Individuel 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 seront pas complétés de cette manière et par conséquent 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 au sein du présent 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 (éventuellement répéter plusieurs fois) :

Titre ……………………………………………………

Diplôme obtenu le (date) ……………………………………………………

Institution …………………………………………………… Enseignement supérieur universitaire (éventuellement répéter plusieurs fois) :

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 (éventuellement, répéter plusieurs fois) 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)

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

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

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

Dans 3 autres entreprises au maximum :

Fonction (répéter 3 fois maximum)

…………………………………………………… Du : au …………….

Compétences techniques :

Matériel informatique ……………………………………………………

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

Logiciel - Systèmes d’exploitation …………………………………………………… - Banques de données …………………………………………………… - Langues de programmation …………………………………………………… - Applications Office …………………………………………………… - Autres (explications ……………………………………………………

Autres compétences :

Au niveau du management ……………………………………………………

Dans le domaine de la consultance ……………………………………………………

Autres (seulement si pertinent) ……………………………………………………

Connaissances linguistiques :

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) ……………………………………………………


Annexe 3.b.: Curriculum Vitae – Synthèse Annexe 3 b : tableau de synthèse des CV : annexe obligatoire sous peine de nullité de l’offre

En ce qui concerne les lots 1,2,3,4 et 5 Pour les lots 1, 2 et 3 « entretien spécifique » Le soumissionnaire doit prévoir une équipe qui se compose au minimum des ETP (équivalents temps plein) suivants pour chaque lot pour lequel il soumissionne.


Task Manager 1


Business Analist 2



Pour les lots 4 et 5 « entretien général et nouveaux développements »


Task Manager 1


Business Analist 3



Le soumissionnaire remplira dans son offre l’annexe obligatoire 3a et b (CV et tableau de synthèse) pour ce qui concerne les profils demandés. La firme ne pourra être sélectionnée si des renseignements exigés ne figurent pas dans l’annexe obligatoire 3b. Pour démontrer ses capacités, il joindra à son offre tous les CV nécessaires qui correspondent aux profils de compétences présentés. Les CV joints devront absolument respecter le modèle fourni en annexe 3a par le pouvoir adjudicateur. IMPORTANT Le soumissionnaire qui propose dans son offre une équipe qui ne satisfait pas la capacité minimale ne sera pas sélectionnée.


Les compétences et l’expertise doivent être démontrées à l’aide des CV et du tableau de synthèse joint en annexe 3b. À cet effet, l'on utilise la classification suivante en matière d'expérience :

Starter : moins de 1000 heures d'expérience réelle dans l'expertise concernée

junior : entre 1000 et 3500 heures d'expérience réelle dans l'expertise concernée

senior : entre 3500 et 10000 heures d'expérience réelle dans l'expertise concernée

expert : plus de 10000 heures d'expérience réelle dans l'expertise concernée E.3.1.2.1. Task Manager Le Task Manager : dont les activités principales sont la planification, la communication, la gestion (pouvant être intégrale, en ce compris le rapportage selon les prescriptions du SPF Finances) du projet et la gestion de son équipe et des tâches et activités des personnes associées à une maintenance donnée ou au projet. Expertise exigée : - gestion de projets Java EE -méthodologies Agile et/ou méthodologie Prince2 - compréhension de UML E.3.1.2.2. Technical Architect Le Technical Architect : dont les activités principales dont de maîtriser, d'intégrer, d'expliquer, d'imposer, de contrôler, de coacher, de communiquer, d'être représentant au comité tactique, au cab ou à tout comité qui requiert son expertise, et ce, en regard de la mise en application des standards techniques et méthodologiques du SPF finances; il joue aussi le rôle d'assurance projet pour le Task Manager. Expertise exigée : - architecture de Java/applications JEE - techniques de communication entre applications - design patterns - création de diagrammes en architecture ULM - design interface application web


E.3.1.2.3. Business Analist Le Business Analist : notamment chargé d’assister le business à la capture des besoins – conformément à la discipline FUP-D1 ou autre méthodologie assimilée (au choix du SPF Finances), essentiellement chargé - conformément à la discipline FUP-D2 ou autre méthodologie assimilée (au choix du SPF Finances), - d'analyser et de formaliser les requirements métier, avec une approche Use-Case centric, et la coopération avec le business et les testeurs. Expertise exigée : - analyse des applications JEE - analyse et conception de modèles de données - analyse et création de Use cases ULM E.3.1.2.4. Développeur technologie JEE Junior Le Développeur : notamment chargé du développement applicatif Java/JEE complet et autres systèmes/technologies en dépendance, de la documentation technique, du déploiement (y compris la réalisation des documents et l'utilisation des processus et outils), des tests élémentaires (unitaires, intégration), et de comprendre les autres langages de programmation. Expertise exigée : - Java Core - Java EE Basic (EJB + JDBC + JPA) - Unit Testing - comprend UML E.3.1.2.5. Développeur technologie JEE Senior Le Développeur : notamment chargé du développement applicatif Java/JEE complet et autres systèmes/technologies en dépendance, de la documentation technique, du déploiement (y compris la réalisation des documents et l'utilisation des processus et outils), des tests élémentaires (unitaires, intégration), et de comprendre les autres langages de programmation. Un développeur senior a au moins 3500 heures d’expérience réelle dans les compétences de base (voir développeur junior) et les compétences complémentaires. Expertise exigée : - comprend UML


- Maven - Java EE Advanced (JAX-WS + JAXB + JAXP + JMS + JNDI) - Design Patterns Équipe minimale pour le lot 1 Lorsque l’on soumissionne pour les lots 1, 2 et 3, il est nécessaire de disposer d’une équipe composée au minimum de 8 personnes différentes pour chaque lot, soit 24 personnes différentes au total.

Task Manager Expertise exigée : - gestion de projets Java EE

Expertise exigée : méthodologies Agile et/ou méthodologie Prince2

Expertise exigée : - compréhension de UML

Nom personne :…………………………….

(*) (*) (*)

Technical Architect Expertise exigée : Architecture de Java/applications JEE

Expertise exigée techniques de communication entre applications

Expertise exigée design patterns

Expertise exigée : Création de diagrammes en architecture ULM

Expertise exigée : design interface application web


Business Analist Expertise exigée : analyse des applications JEE

Expertise exigée analyse et conception de modèles de données

Expertise exigée analyse et création de Use cases ULM

Nom personne 1 ………………………………………………

(*) (*) (*)


Nom personne 2………………………………………………

(*) (*) (*)

Développeur technologie JEE Junior Expertise exigée : Java Core

Expertise exigée Java EE Basic (EJB + JDBC + JPA)

Expertise exigée Unit Testing

Expertise exigée Comprend UML

Nom personne 1 ………………………………………………

(*) (*) (*) (*)

Nom personne 2 ……………………………………………….

(*) (*) (*) (*)

Développeur technologie JEE Senior Expertise exigée : comprend UML

Expertise exigée : Maven

Expertise exigée : Java EE Advanced (JAX-WS + JAXB + JAXP + JMS + JNDI)

Expertise exigée : Design Patterns

Nom personne 1 ……………………………………………..

(*) (*) (*) (*)

Nom personne 2 ……………………………………………….

(*) (*) (*) (*)

Nombre total de personnes exigées pour la soumission au lot 1 : 8 personnes

(*) le soumissionnaire mentionne obligatoirement l’expérience réelle dans le tableau ci-dessus sous peine de nullité de l’offre.

starter : moins de 1000 heures d'expérience réelle dans l'expertise concernée



expert : plus de 10000 heures d'expérience réelle dans l'expertise concernée


Équipe minimale pour le lot 2





(*) (*) (*)










Nom personne 1 ………………………………………………

(*) (*) (*)

Nom personne 2………………………………………………

(*) (*) (*)






Nom personne 1 ………………………………………………

(*) (*) (*) (*)

Nom personne 2 ……………………………………………….

(*) (*) (*) (*)





Nom personne 1 ……………………………………………..

(*) (*) (*) (*)

Nom personne 2 ……………………………………………….

(*) (*) (*) (*)

Nombre total de personnes exigées pour la soumission au lot 2 : 8 personnes







Équipe minimale pour le lot 3





(*) (*) (*)










Nom personne 1 ………………………………………………

(*) (*) (*)

Nom personne 2………………………………………………

(*) (*) (*)






Nom personne 1 ………………………………………………

(*) (*) (*) (*)

Nom personne 2 ……………………………………………….

(*) (*) (*) (*)





Nom personne 1 ……………………………………………..

(*) (*) (*) (*)

Nom personne 2 ……………………………………………….

(*) (*) (*) (*)

Nombre total de personnes exigées en cas de soumission pour le lot 3 : 8 personnes







Équipe minimale pour le lot 4 L’équipe minimale proposée pour le lot 4 peut se composer des mêmes personnes que l’équipe proposée pour le lot 5.





(*) (*) (*)






Nom personne 1 ………………………………………………

Nom personne 2 ………………………………………………




Nom personne 1 ………………………………………………

(*) (*) (*)


Nom personne 2………………………………………………

(*) (*) (*)

Nom personne 3 Nom personne 1 Nom personne 1 Nom personne 1 Nom personne 1

Nom personne 1





Nom personne 1 ………………………………………………

(*) (*) (*) (*)

Nom personne 2 ……………………………………………….

(*) (*) (*) (*)

Nom personne 3 ………………………………………………

(*) (*) (*) (*)

Nom personne 4 ………………………………………………

(*) (*) (*) (*)





Nom personne 1 ……………………………………………..

(*) (*) (*) (*)

Nom personne 2 ……………………………………………….

(*) (*) (*) (*)

Nom personne 3 ……………………………………………..

Nom personne 4 ……………………………………………..


Nombre total de personnes requises pour la soumission au lot 4 : 14 personnes





expert : plus de 10000 heures d'expérience réelle dans l'expertise concernée Équipe minimale pour le lot 5





(*) (*) (*)






Nom personne 1 ………………………………………………

(*) (*) (*) (*) (*)

Nom personne 2 ………………………………………………

(*) (*) (*) (*) *)

Business Analist Expertise exigée : Expertise exigée Expertise exigée


analyse des applications JEE

analyse et conception de modèles de données

analyse et création de Use cases ULM

Nom personne 1 ………………………………………………

(*) (*) (*)

Nom personne 2………………………………………………

(*) (*) (*)

Nom personne 3 (*) (*) (*)





Nom personne 1 ………………………………………………

(*) (*) (*) (*)

Nom personne 2 ……………………………………………….

(*) (*) (*) (*)

Nom personne 3 ………………………………………………

(*) (*) (*) (*)

Nom personne 4 ………………………………………………

(*) (*) (*) (*)





Nom personne 1 ……………………………………………..

(*) (*) (*) (*)

Nom personne 2 ……………………………………………….

(*) (*) (*) (*)


Nom personne 3 ……………………………………………..

(*) (*) (*) (*)

Nom personne 4 ……………………………………………..

(*) (*) (*) (*)

Nombre total de personnes requises pour la soumission au lot 5 : 14 personnes

(*) le soumissionnaire mentionne obligatoirement l’expérience effective dans le tableau ci-dessus à peine de nullité de l’offre.

Starter : moins de 1000 heures d'expérience réelle dans l'expertise concernée



expert : plus de 10000 heures d'expérience réelle dans l'expertise concernée Annexe 3 b : cv tableau récapitulatif : annexe obligatoire

Pour ce qui concerne le lot 6 tests (général) : tests fonctionnels et tests techniques spécifiques (charge et performance) IMPORTANT Compétences communes Ces exigences doivent être rencontrées pour les profils proposés (P1 – P3) sous peine de nullité. - Certification ISTQB obligatoire sous peine de nullité de l’offre. Fournir la preuve de la certification - Maîtrise de la langue française et/ou néerlandaise et connaissance passive de l’autre langue - Minimum 3 ans d’expertise dans le secteur informatique dont 2 ans dans le software testing. E.3.2.3.1. Testeur

Activités

Un testeur est responsable de toutes les activités primaires de test. Ces activités sont réparties sur l’ensemble du trajet de test. Premièrement, le testeur devra préparer les tests. Cela signifie qu’il faudra définir la base du test et qu’il faudra ensuite procéder à un intake sur cette base de test. Deuxièmement, le testeur devra exécuter les spécifications du test. Cela implique l’élaboration de cas de test logiques et la préparation de cas de tests physiques. Pour cette phase, le testeur utilisera les outils de test nécessaires.


Ensuite, les tests préparés seront exécutés par un testeur. Pendant l’exécution des tests, le testeur rapportera correctement les éventuels manquements et en assurera le suivi. Pendant cette phase, il sera fait usage des outils de test nécessaires. Enfin, les résultats finaux des tests seront rapportés par le testeur sous la forme de conclusions, de tests réussis et ratés. Les résultats seront systématiquement complétés de preuves supplémentaires (“test evidence”) par le testeur. Profil Le testeur connaît une méthodologie de test structurée, TMap Next ou STBOX. Le testeur est également capable d'utiliser un des outils de test suivants: HP ALM, UFT ou LoadRunner/Performance Center. Outre ces compétences plus techniques, les compétences de communication sont importantes dans le rôle de testeur. Le testeur doit en effet être en mesure d’entretenir le contact avec les développeurs, les analystes et les chefs de projet. Le testeur doit être capable d'exprimer ses idées et ses avis de manière claire et structurée, aussi bien oralement que par écrit. Le testeur posera aussi toujours des questions complémentaires pour être certain de tout bien comprendre. Un testeur est capable de collaborer efficacement avec ses collègues et de contribuer à un climat positif au sein de l’équipe pour que le travail puisse être effectué de manière efficiente. Il contribue activement à la réalisation des résultats communs ainsi qu’à la résolution des problèmes ou des conflits. Le testeur dispose aussi des compétences d’analyse nécessaires. Chaque phase des spécifications des tests étant liée à une analyse de la base de test. Un testeur étudiera les informations en profondeur et de façon critique. Les relations internes seront également correctement estimées. Le testeur doit également être disposé à assimiler, comprendre et appliquer correctement les différentes méthodes et procédures disponibles. Le testeur doit être capable d’organiser le travail qui lui a été confié de manière efficiente. Pour cela, le testeur formulera des objectifs, planifiera les activités et définira des priorités. E.3.2.3.2. Spécialiste en test tools Activités

Le spécialiste en outils de test sera d’une part responsable de l’exécution des activités primaires de test (préparation des tests, spécifications des tests, exécution des tests, reporting et suivi des résultats) et d’autre part il devra mettre ses connaissances spécialisées au service de l'équipe et servir de point de contact à ce sujet. Le spécialiste en outils de test devra aussi s’investir dans l’implémentation et le suivi des outils de test (HP ALM, Performance Center, UFT…). Il prendra également en charge le coaching des membres de l’équipe concernant ces outils. Profil

Le spécialiste en outils de test dispose des connaissances et de l’expérience nécessaires pour travailler de manière indépendante sans avoir besoin en permanence d’un accompagnement ou de l’aide d’autrui. Dans son domaine de spécialisation, le spécialiste en outils de test sera capable d'identifier les opportunités et d’agir ou de faire des propositions quand ces opportunités se présentent.


Il sera aussi capable de continuer à fonctionner efficacement dans les situations difficiles, sous pression élevée (au niveau du temps) ou face à la résistance et aux oppositions. Le spécialiste en outils de test est capable de donner un avis éclairé dans son domaine d’expertise. Il adapte son style et ses techniques d’avis tant aux personnes auxquelles il s'adresse qu'aux situations. Dans son domaine d’expertise spécifique, le spécialiste en outils de test est capable de mettre en œuvre ses nouvelles idées, de proposer des solutions et de faire des propositions en matière d'amélioration des processus. Le spécialiste en outils de test entreprend (ou soutient) d'initiative des actions qui stimulent le développement professionnel des autres. Il aidera les autres et les accompagnera dans l’exercice de leur fonction. E.3.2.3.3. Spécialiste en méthodologie de test

Activités

Le processus de test dans son ensemble ressortit à la responsabilité du spécialiste en méthodologie de test. Cela signifie que régulièrement (p. ex. tous les six mois ou tous les ans), le spécialiste en méthodologie de test effectuera un TPI®. Les résultats de ce TPI® seront convertis par le spécialiste en méthodologie de test (en concertation avec le Test Manager) en points d’action concrets et repris dans un planning comportant divers jalons. Profil Le spécialiste en méthodologie de test dispose des connaissances et de l’expérience nécessaires en matière de méthodologie de test pour travailler de manière indépendante sans avoir besoin en permanence d’être accompagné ou aidé par quelqu’un d’autre. Profil

Au sein de son domaine d’expertise spécifique, le spécialiste en outils de test est capable de mettre en œuvre ses nouvelles idées, de proposer des solutions et de faire des propositions en matière d'amélioration des processus. Au sein de son domaine d’expertise spécifique, le spécialiste en méthodologie de test est capable de mettre en œuvre ses nouvelles idées, de proposer des solutions et de faire des propositions en matière d'amélioration des processus. Le spécialiste en méthodologie de test entreprend (ou soutient) d'initiative des actions qui stimulent le développement professionnel des autres. Il aidera les autres et les accompagnera dans l’exercice de leur fonction. E.3.2.3.4. Quality Assurance Coordinator Les Quality Assurance Coordinators proposés doivent disposer au minimum des compétences suivantes sous peine d’exclusion : au moins 5 ans d’expérience démontrable dans un environnement IT, dont au moins un an dans une organisation d’une taille comparable au SPF Finances. Pouvoir démontrer au minimum 2 ans d’expérience de projet en qualité de responsable du contrôle qualité et/ou de l’assurance qualité dans minimum 2 projets différents. - Certification Prince2 ou PMBOK. - Maîtrise des deux langues nationales (français et néerlandais) : - Maîtrise parfaite (niveau C2 / locuteur natif) du français ou du néerlandais . - Connaissance active et courante de l’autre langue nationale. Activités


Le Quality Assurance Coordinator interviendra principalement en qualité de contrôleur qualité par le biais d’initiatives “deep dive” et la réalisation de reviews concrets pour surveiller le respect des standards ICT du SPF Finances, et plus particulièrement celui du standard FUP (aussi bien les outils que les deliverables). Concrètement, il s’agit, entre autres, des activités suivantes : Document review van de deliverables; - Contrôler l’utilisation correcte des outils (HP ALM, Continuous Integration, …) - Contrôler la qualité de la gestion et de la définition des requirements; - Contrôler la qualité du code à l'aide des critères de mesure fournis (SonarQube, HP Fortify, …); - Surveiller la qualité des activités de test pour le lot 5; - Intervenir et communiquer de manière proactive en cas de constatation d’incohérences potentielles (et risques) qui surviendraient entre les activités de développement des lots 1 à 5 et les activités de tests du lot 6 ; De plus, à la demande de l’adjudicataire, il émettra un avis ad hoc et formulera des instructions en matière de limitation des risques, d’assurance qualité, de santé du projet et d'application des bonnes pratiques. Il identifiera clairement les interdépendances entre les différentes activités du projet et sera capable d’en estimer l’impact et les risques dans le cadre de la surveillance de la cohérence entre les activités exécutées dans le cadre du lot 5 d’une part et les activités des lots 1 à 5 d’autre part. Dans la pratique, le Quality Assurance Coordinator travaillera en étroite collaboration avec les membres du Comité QUAC. Cela signifie que chaque mois, il fera aux stakeholders du SPF Finances un rapport sur les éléments suivants : - Un rapport high level comprenant un aperçu des principaux risques, constatations et recommandations ; - Un rapport d’activités détaillé sur les activités Quality Assurance complétés de rapports de review. - Un planning des activités et des reviews encore à effectuer. Profil

Pour pouvoir mener à bien sa mission, le Quality Assurance Coordinator doit disposer des compétences et connaissances suivantes : Développement applicatif : cette activité exige des connaissances dans le domaine des méthodologies de développement (RUP ou méthodologie similaire), des standards J2EE, des bonnes pratiques en matière de design et de qualité du code, … - Test du software: Cette activité exige des connaissances dans le domaine des différents - niveaux (p. ex. unit testing, system testing, …), - types (p. ex. tests de performance), - et types (p. ex. stress test) de tests. - Cette activité exige également des connaissances en matière de méthodologies de test. - Architecture de l’information : cette activité exige des compétences dans le domaine de la transposition de modèles de domaine en modèles de base de données logiques et physiques. - Infrastructure: dans le cadre du SPF Finances cela implique surtout des connaissances dans le domaine des serveurs applicatifs, des systèmes de gestion, des outils de développement, etc. - Gestion de projet :


- Gestion de la communication : communication transparente et obtention de l’engagement de tous les acteurs du projet - Gestion des risques : sensibilisation permanente aux risques et à la maîtrise des risques - Gestion des changements Le SPF Finances part de la composition minimale suivante :

Profil Capacité minimale (ETP) lot 6

Testeur 4


Spécialiste en méthodologie de test 2


IMPORTANT Le soumissionnaire indique dans le tableau ci-dessous si la personne concernée répond aux exigences. Certaines exigences, comme la certification ISTQB obligatoire, sont démontrées par le biais d’attestations sous peine de nullité du profil proposé.


Testeur Expertise exigée : Connaissance d'une méthodologie de test structurée, TMap Next ou STBOX.

Expertise exigée : Test Tools : HP ALM, UFT pour tests de performance LoadRunner/Performance Center

Expertise exigée : Certification ISTQB obligatoire

Expertise exigée : Maîtrise de la langue française et/ou néerlandaise et connaissance passive de l’autre langue

Expertise exigée : Minimum 3 ans d’expertise dans le secteur informatique dont 2 ans dans le software testing.

Nom personne 1 :…………………………….

Nom personne 2 :…………………………….

Nom personne 3 :…………………………….

Nom personne 4 :…………………………….

Spécialiste en test tools Expertise exigée : Mise sur pied et suivi de test tools (HP ALM,Performance Center, UFT…

Expertise exigée : Certification ISTQB obligatoire

Expertise exigée Maîtrise de la langue française et/ou néerlandaise et connaissance passive de l’autre langue

Expertise exigée Au moins 3 ans d’expérience dans le secteur de l’informatique, dont deux ans en software testing.


Nom personne 1 ………………………………………………

Nom personne 2 ………………………………………………

Spécialiste en méthodologie de test Expertise exigée Connaissance approfondie de TMap et/ou STBox. Certification ISTQB obligatoire

Expertise exigée Maîtrise de la langue française et/ou néerlandaise et connaissance passive de l’autre langue

Expertise exigée Minimum 3 ans d’expertise dans le secteur informatique dont 2 ans dans le software testing.

Nom personne 1 ………………………………………………

Nom personne 2………………………………………………

Quality Assurance Coordinator Expertise exigée Au moins cinq ans d’expérience démontrable dans un environnement IT

Expertise exigée Minimum 2 ans d’expérience de projet en qualité de responsable du contrôle qualité et/ou de l’assurance qualité

Expertise exigée Certification Prince2 ou PMBOK.

Expertise exigée Maîtrise des deux langues nationales (français et néerlandais)

Expertise exigée Connaissances dans le domaine des méthodologies de développe


ment (RUP ou équivalentes), standards JEE

Nom personne 1 ………………………………………………

(*) (*) (*) (*)

Nom personne 2 ……………………………………………….

(*) (*) (*) (*)

Nombre total de personnes requises en cas de soumission au lot 6 : 10 personnes


ANNEXE 4 : SLA TEMPLATE

Le texte en italique précise l’élaboration possible du point concerné du SLA

1. Gestion de ce document SLA

a. Historique document – Version gestion (éventuellement avec la mention Requests for Change)

b. Liste de distribution pour la distribution du document c. Références aux documents y afférents

2. Définitions, concepts, abréviations (peut également être une annexe)

Liste comprenant des notions, des abréviations, des formules et des consignes de mesure cohérentes et clairement définies, qui aident à prévenir tout malentendu.

Relevé des notions utilisées dans le SLA :

définitions ;

abréviations ;

formules et prescriptions de mesure ;

périodes de début et de fin sur la base de paramètres mesurables. Objectif de ce SLA

3. Objectif de ce SLA

a. Scope du SLA Signaler à quel(s) service(s) le SLA a trait.

b. Objectifs généraux pour le Client Placement de remarques préliminaires (par exemple qu’un SLA a été établi pour améliorer la qualité du service) et de principes de base (par exemple le fait que des personnes doivent être habilitées à utiliser le service ou le fait de ne pas mettre les services à la disposition de tiers).

remarques préliminaires relatives aux objectifs et au contenu ;

principes de base relatifs à la mise à disposition du service.

4. Approbation et gestion de ce SLA

5. Adaptations et évaluation SLA

a. Description et évaluation périodique du SLA

b. Description de la procédure pour la modification du SLA

Les éléments à déterminer sont les suivants :

l’énumération des éléments qui mènent à une modification du SLA ;


la distinction entre les modifications incidentelles et les modifications permanentes ;

la procédure de modification (manière, moment, concertation) ;

les modifications antérieures et les versions du SLA, en ce inclus, les dates auxquelles les différentes versions étaient en vigueur (voir également le paragraphe « 1 Gestion de ce document SLA »).

c. Description de la procédure pour la modification du(des) service(s) délivré(s)

Effectuer une esquisse des possibilités de modification du/des service(s) fourni(s) (tant par le fournisseur que par le pouvoir adjudicateur) si cela s’avère nécessaire ou souhaitable. Il est en outre décrit de quelle manière et à quel moment des demandes de modification peuvent être introduites et dans quelle mesure la modification du service nécessite une révision du SLA.

Les éléments à déterminer sont les suivants :

la procédure de modification, en ce inclus, la mention du point de contact et la période d’introduction des modifications ;

le mode de concertation pour les demandes de modification ;

impact de la modification sur le SLA (p.ex. “modification du service, comme installation de nouveau matériel informatique et/ou de nouveaux logiciels, rend en principe nécessaire, la révision du SLA”).

Voir également le paragraphe « 11 Description des processus ITIL utilisés – Change Management »

6. Durée du SLA

a. Durée du contrat (date de début et de fin)

b. Règles et procédures concernant le renouvellement et la résiliation anticipée du SLA

7. Rôles et responsabilités du SPF Finances

a. Informations de contact (référence au DAP)

À enregistrer dans DAP : relevé des personnes de contact, leur fonction et les coordonnées (localisation, numéro de téléphone ou de GSM et adresse mail) ;

b. Responsabilités c. Rôles d. Communication au SPF Finances

8. Rôles et responsabilités de l’adjudicataire

a. Informations de contact (référence au DAP)

À enregistrer dans DAP : relevé des personnes de contact, leur fonction et les coordonnées (localisation, numéro de téléphone ou de GSM et adresse mail) ;

b. Responsabilités c. Rôles


d. Communication à l’adjudicataire

9. Engagement et conditions connexes

a. Engagement de l’adjudicataire concernant la portée b. Conditions connexes (limitations, restrictions, force majeure)

Description explicite des limites de la prestation de service, tant en matière de fourniture de service proprement dite, que de moyens utilisés précédemment. Fixation de limitations relatives à l’utilisation des services à fournir, la dépendance d’organisations tierces (par exemple dépendance d’un opérateur télécom) et l’ébauche de situations dans lesquelles les organisations peuvent invoquer la force majeure.

le nombre maximum d’utilisateurs simultanés des différents services ;

le nombre maximum d’utilisateurs des différents services (le nombre maximum des comptes d’accès) ;

la dépendance aux autres organisations ou services ;

la réglementation lorsque l’on invoque la force majeure, en ce inclus, la possibilité de la mise hors service du SLA et les actions à entreprendre pour revenir le plus rapidement possible à la situation normale ;

la procédure générale de calamité, en ce inclus, la référence aux différents plans de calamité; peut également être repris dans le paragraphe 17 Disaster recovery et Continuity

les autres limitations (par exemple le nombre maximum de transactions par période).

10. Services (Services) et Niveaux de service (Service levels)

Par service presté, référence aux spécifications du service level, qui sont fixées dans l’offre, conformément au cahier spécial des charges ou au contrat.

la description concrète des services (référence aux spécifications du servicelevel, élaboré par service) ;

par service à fournir, il faut au moins mentionner la fonctionnalité, les exigences de prestation et les restrictions d’application ;

éventuellement les listes avec les tâches à exécuter (p.ex. matrice RACI);

les horaires de service (horaires de service normaux de 07 à 19 heures durant les jours ouvrables, les week-ends, les jours fériés et les jours de congé) ;

la disponibilité du service (pourcentages minimum, moyenne, le nombre maximum de perturbations par période, la période de mesure) ;

les prestations de service ;

…

Autrement dit : Le but est qu’en l’espèce, la description des services ou des produits, à fournir par le Serviceprovider, tels que conclus et pour lesquels des accords explicites doivent être


conclus avec le client en matière d’indicateurs de prestations et d’exigences de qualité afin de pouvoir les contrôler ultérieurement, soit également reprise dans le SLA Ces indicateurs de prestations/exigences sont ensuite traduits en normes, mesurées dans le temps (valeurs min/max ou % min/max, …) qui détermines également le statut des services du SLA à intervalles réguliers, et qui peuvent être rendues exploitables pour l’évaluation du SLA (réalisation des objectifs, amendes ou pénalités éventuelles). Il y a lieu d’utiliser du tableau des KPI annexé au cahier des charges. Ce tableau doit être repris dans le SLA à titre de relevé des KPI.

11. Description des processus ITIL et des procédures : Dans un document distinct joint en annexe au SLA, à savoir, le Dossier Accords et Procédures (DAP), il y a lieu de décrire les détails des processus ITIL V3 respectifs utilisés, et des procédures liées. On reprend également dans le document DAP, tous les éléments qui ne nécessitent pas de nouvelle signature et de modification du document SLA (p.ex. liste des techniciens qui doivent avoir accès au centre de données du SPF Finances lors d’interventions, …). Voici un exemple de processus ITIL V3 :

Gestion des incidents

Gestion des problèmes

Gestion des versions

Gestion du changement

Capacity management;

… Par processus, au moins les points suivants doivent être traités dans le DAP :

Définition

Objectif

Accords

Procédures

…

12. KPI et Rapportage

Le pouvoir adjudicateur doit avoir et conserver une vue d’ensemble sur tout ce qui a trait aux services fournis. En ce qui concerne les rapports, des accords doivent être conclus en matière :

de format et de contenu des rapports ;

de fréquence de la fourniture des rapports ;

de distribution : comment et à qui (responsables fonctionnels, personnes physiques, divisions,…)

…

Le soumissionnaire introduira une proposition de rapport mensuel/trimestriel sous forme de document exploitable reprenant les niveaux SLA atteints. La fréquence de


livraison sera décidée dès l’attribution du marché. En principe, un document SLA est délivré chaque mois au SPF Finances, et vérifié par ce dernier. Au besoin, une réunion SLA mensuelle « by exception » sera organisée. Tous les trois mois, une réunion SLA « on-site » sera organisée au SPF Finances.

Le document présenté contiendra entre autres les sujets suivants (liste non restrictive) :

Les résultats du SLA par rapport aux normes définies (les KPI) comprenant

les explications quant aux éventuels « SLA breaches » (normes pas

atteintes) ;

Le statut des composantes de la solution : uptime hardware,

processeur/utilisation de la mémoire ou des différents services …;

L’analyse des tendances à soumettre au groupe de pilotage sur la base des

résultats des trimestres écoulés, … ;

Aspects de sécurité ( patches, scanning, logs, auditing,…);

Les rapports d’incidents (détails sur les incidents par catégorie, Incident

Response et Resolution Time, … ;

Le « Request For Changes » durant la période de référence ;

L’analyse des incidents liés au problem management (recommandation sur la

base de « root cause analyse » ;

Un tableau de bord récapitulatif reprenant un résumé du management avec le

statut SLA de la solution proposée, qui contient un « subset » ou un

« superset » des indicateurs de prestations définis au paragraphe 10.

…

13. Concertation, Traitement des plaintes et anomalies du SLA

a. Procédure de traitement des plaintes

Du SPF Finances à l’adjudicataire

De l’adjudicataire au SPF Finances b. Concertation c. Procédure en escalade

Il faut déterminer quand une concertation structurée doit avoir lieu, qui participera à cette concertation et qui, auprès des deux parties, est responsable des relations réciproques. Un relevé de toutes les personnes de contact et des responsables sera enregistré en cas d’escalation ou de calamités.

moments ou motifs pour une concertation ;

personnes concernées par la concertation ;

personnes responsables pour les relations réciproques ;


relevé des personnes de contact et des responsables (en ce inclus, les numéros de téléphone) en cas d’escalation et/ou de calamités (la plupart du temps, une référence à l’annexe concernée) ;

14. Responsabilité, responsabilité civile

La mention non seulement de la responsabilité pour les appareillages et/ou les programmes placés chez le pouvoir adjudicateur, mais également de la responsabilité de l’organisation du fournisseur pour le fonctionnement du pouvoir adjudicateur.

responsabilité de l’organisation du fournisseur pour le fonctionnement du pouvoir adjudicateur, par exemple en cas de dérangements ou de calamités ;

conséquences du non-respect (ou du non-respect partiel) des accords ;

dédommagements des préjudices en conséquence d’un service fonctionnant de manière insuffisante ;

description de la concertation en cas de problèmes (éventuellement la référence à la clause relative aux litiges) ;

clause des amendes ou autres sanctions éventuelles lorsque les service levels n’ont pas été atteints. (voir également le paragraphe 15 Aspects financiers).

15. Aspects financiers

Description du système d’amendes appliqué ainsi que les pénalités lorsque les niveaux convenus dans le SLA n’ont pas été atteints.

16. Aspects de sécurité Sécurisation des systèmes, des services et des données sont des aspects importants. Ces éléments doivent dès lors être protégés contre des attaques internes et externes.

procédure de sécurisation des systèmes, des services, des données ;

point d’information en cas d’incidents liés à la sécurisation.

…

17. Disaster recovery et Continuity

Description des équipements, des actions, des procédures, … dans le cadre du disaster recovery et de la continuité des services fournis. Recovery Time Objective / Recovery Point Objective (si cela s'applique)

18. Contrôle par des tiers

Le SPF Finances peut faire contrôler et exécuter les mesures du SLA à ses propres frais, par un bureau d’études indépendant.

19. Conclusions et signatures

Clôture formelle du SLA, établissant que les parties concernées ont conclu « ce qui précède », signé par des personnes responsables des deux organisations.

clôture formelle ;


noms et signatures de personnes habilitées à signer.


ANNEXE 5 : Tableau KPI Le tableau des KPI est une annexe séparée à ce cahier des charges (format A3).


ANNEXE 6 : Description des applications Dans cette annexe, le soumissionnaire donne une description des applications dans ce cahier des charges qui portent sur les domaines suivants. Description fonctionnelle Description métier des fonctionnalités couvertes par l’application. Cycle de vie récurrent L’exécution du présent cahier des charges est basée sur un cycle d’exécution annuel, découlant du cycle budgétaire lui-même annualisé. Le présent volet a donc pour vocation de préciser les contours des « prestations récurrentes » en matière de support et de maintenance annuels. Évolutions prévues Cette partie a pour objectif d’informer le soumissionnaire quant aux évolutions prévues et/ou probables à la date de rédaction du présent document, ce afin qu’il dispose de la vue la plus complète possible. Ces informations sont assurément sujettes à évolution et ne constituent aucunement un engagement de réalisation. Documentation FUP Un tableau joint à ce cahier des charges donne un aperçu de la documentation FUP disponible par application. Remarquez que l’existence de cette documentation ne constitue pas une indication de son caractère complet ni de sa qualité.


Lot 1 – Entretien (spécifique) de Zacheus, e-Notariat, Finprof, e-Deduction (SAFS CV), Avis de saisie (FCA).

Application En

production Service window

Zacheus oui 5x12

e-Notariat oui 7x24x365

Finprof oui 7x24x365

e-Deduction (SAFS CV) oui 7x24x365

Avis de saisies (FCA) oui 7x24x365

…

I. Zacheus

a. Description fonctionnelle Les délibérations n° 08/19 et 08/20 émanant du Comité sectoriel de la Sécurité sociale et de la Santé – Section « Sécurité sociale » ont autorisé la communication de certaines données à caractère personnel à l’Administration générale de la Perception et du Recouvrement de l’entité Impôts et Recouvrement et au Service des Créances alimentaires de l’Administration du Recouvrement non fiscal de l’Administration générale de la Documentation patrimoniale du Service public fédéral Finances. Le Service public fédéral Finances a accès aux types de données à caractère personnel suivants : d’une part, les ressources et les revenus des contribuables négligents, des créanciers d’aliments (bénéficiaires d’une avance sur une créance alimentaire) et des débiteurs d’arriérés de créances alimentaires (notamment contribuables de créances alimentaires ou d’arriérés, d’avances SECAL ou CPAS ou de sommes dues), d’autre part l'identité des instances d’octroi de ses moyens et revenus.

Plus précisément, par dossier individuel, le SPF Finances à accès à :

la consultation de l’identité de l’employeur le plus récent d’un contribuable,

La consultation d'un aperçu des revenus, et

le cas échéant, la prise de connaissance du montant liquidé en pécule de vacances. Ces données à caractère personnel sont extraites, via la Banque-Carrefour de la Sécurité sociale (CSS), de la banque de données à caractère personnel DMFA, du Répertoire des employeurs, du fichier du personnel de l’Office national de la sécurité sociale (ONSS) et de l’Office national de sécurité sociale des administrations provinciales et locales (ONSSAPL) et de la base de données à caractère personnel gérée par l’Office national des vacances annuelles portant sur le pécule de vacances. L’accès est accordé aux fonctionnaires de l’Administration générale de la Perception et du Recouvrement et du SECAL compétents pour le recouvrement de l’impôt concerné. Les données à caractère personnel (principalement nature, hauteur et périodicité des revenus et identités des débiteurs des revenus) ne sont utilisées que pour une évaluation et une description objectives, complètes et actuelles de la situation financière des contribuables négligents concernés, des débiteurs d’arriérés de créances alimentaires et des créanciers de créances alimentaires.


L’accès électronique aux données demandées doit permettre une appréciation correcte et une application adéquate

de la procédure d’octroi d’avances sur la pension alimentaire aux créanciers d’aliments/enfants ou de recouvrement de la pension alimentaire, de ses arriérés ainsi que des avances octroyées, offrant ainsi l’occasion d’assurer aux débiteurs le respect des conditions d’intervention et la mise en œuvre des procédures adéquates compte tenu de leurs revenus (saisie-arrêt simplifiée, délégation de somme) ;

de la procédure de saisie-arrêt-exécution simplifiée sur les rémunérations ;

de l’octroi de facilités de paiement au débiteur en difficultés financières ;

de la procédure d’octroi d’exonération du paiement d’intérêts de retard ;

de la procédure de surséance indéfinie au recouvrement ;

de l’établissement d’une V180 ou demande de radiation et son évaluation.

OBJECTIF

L’accès et la mise à disposition d’une application sous la forme d’une application Web naît d’une collaboration entre le SPF Finances (plus précisément l’Administration générale de la Perception et du Recouvrement, l’Administration du Recouvrement non fiscal et le Service d’encadrement ICT) d’une part, l’Office national de la sécurité sociale (ONSS) et l’Office national des vacances annuelles (ONVA) via la Banque-Carrefour de la Sécurité sociale (BCSS) d’autre part. L’objectif du projet est d’accéder aux données à caractère personnel demandées à l’aide du numéro d’identification de la sécurité sociale du contribuable négligent. L’utilisation du numéro d’identification de la sécurité sociale (NISS) permet au Service public fédéral Finances d’identifier l’intéressé de manière univoque. La BCSS consulte l’ONSS (Office national de la sécurité sociale) et/ou l’ONSS/APL (Office national de la sécurité sociale des administrations provinciales et locales) dans le but de rechercher les informations souhaitées dans la base de données à caractère personnel DMFA, le Répertoire des employeurs de l’ONSS et de l’ONSS/APL, le fichier du personnel des employeurs inscrits à l’ONSS et à l’ONSS/APL et l’Office national des Vacances annuelles. La base de données à caractère personnel DMFA est gérée par l’Office national de la Sécurité sociale et l’Office national de la Sécurité sociale des Administrations provinciales et locales et contient, outre des données purement administratives, des données à caractère personnel provenant des déclarations DMFA (« Déclaration Multifonctionnelle/Multifunctionele Aangifte ») introduites auprès de ces organismes publics de la sécurité sociale. La déclaration trimestrielle DmfA contient les données de salaires et de temps de travail de tous les travailleurs occupés chez un employeur durant un trimestre donné. Le Répertoire des employeurs de l’Office national de la sécurité sociale et de l’Office national de la sécurité sociale des Administrations provinciales et locales contient des données à caractère personnel au niveau de l’employeur. Le Fichier du personnel des employeurs inscrits auprès de l’Office national de la Sécurité sociale et de l’Office national de la Sécurité sociale des Administrations provinciales et locales est alimenté par la « déclaration immédiate d’occupation » (DIMONA). La déclaration immédiate d’occupation est un avis électronique par lequel l’employeur communique toute entrée et sortie de service d’un travailleur à l’ONSS/APL.


Les données à caractère personnel suivantes seraient demandées auprès de l’Office national des Vacances annuelles à l’aide du numéro d’identification de la sécurité sociale (NISS) : le montant et la période de paiement des pécules de vacances (uniquement disponible pour les ouvriers). L’identité de la caisse de vacances compétente ne peut pas encore être communiquée. L’ONVA souhaite que ce soit le cas, vu que les saisies-arrêts sont toujours envoyées à l’ONVA, qui doit à son tour les envoyer à la caisse de vacances compétente. L’application contient les écrans suivants :

Ecran de recherche

Ecran « Activités en cours »

Ecran « Pécule de vacances »

Ecran « Revenus »

Ecran « Attestation employeur »

b. Cycle de vie récurrent Zacheus est une application très stable qui n’évolue pas beaucoup. Elle doit cependant s’adapter aux modifications apportées au message xml utilisé par la BCSS au niveau des différents services Web employés pour avoir accès aux données sources (Dimona, Dmfa, …).

c. Indications concernant l'entretien évolutif futur Actuellement, il est possible de consulter, pour un débiteur/demandeur d’avances :

l’identité de l’employeur le plus récent d’un contribuable/débiteur,

un aperçu des dernières rémunérations connues,

un aperçu des derniers employeurs connus,

le cas échéant, le montant liquidé en pécule de vacances.

L’application « Recherche CSS » contient des informations qui n’ont pas encore été entièrement remplies, mais qui peuvent être détaillées à l’avenir.

En outre, il est possible d’obtenir, dans une phase ultérieure et après obtention des autorisations nécessaires, l’accès électronique aux données relatives aux revenus/ressources par diverses instances de la sécurité sociale (voir données sur les pensions, données ONEM (revenus de remplacement, allocations de chômage)…). L’application fera l’objet des extensions nécessaires en fonction des nouveaux besoins.


II. e-Notariat

a. Description fonctionnelle Dans le cadre de leur collaboration obligatoire, e-Notariat veut établir des relations électroniques avec les notaires. Les principaux objectifs sont :

l’installation d’un point de contact unique pour l’envoi de notifications ;

l’aménagement du workflow pour le traitement des notifications.

Le processus est régi à l’art. 433 et suivants, CIR 92 et 93ter et suivant, CTVA. Il prévoit le principe obligatoire de collaboration de certains fonctionnaires ministériels, fonctionnaires publics et d’autres personnes. Les Notaires, les Commissaires de comités d’acquisition (et les autres fonctionnaires publics tenus d’obligations légales similaires) à qui il est demandé d’établir un acte ayant pour objet l’aliénation ou l’affectation hypothécaire d’un immeuble, d’un navire ou d’un bateau situé en Belgique doivent informer un centre unique constitué à cet effet au sein du SPF Finances (et via la FRNB pour les notaires) : 1. du projet de passation de cet acte (avis (1.)) (infra 1.1.) et, 2. le cas échéant et de manière subséquente, de l’insuffisance d’actif pour désintéresser les créanciers ayant fait valoir leurs créances (créanciers inscrits et opposants) (avis (2.))(infra 1.2.). Le centre unique constitué au sein du SPF Finances fait automatiquement trier ces avis et transmet l’information aux différents services impliqués de l’entité P & R. 1.1. L’avis (1.) Les services de taxation établissent le cas échéant les nouveaux impôts et taxes. Le système central constitué à cet effet envoie de manière électronique (via la FRNB pour les notaires) une réponse automatique à l’émetteur :

(soit) néant,

(soit), en fonction du traitement par les services de recouvrement, la notification

globale des impôts et taxes dus qui peuvent donner lieu à l’inscription de

l’hypothèque légale du Trésor avec rang particulier lorsque l’intérêt du Trésor l’exige

(appréciation du ou des receveurs concernés). Dans ce cas, les notaires, les

commissaires de comités d’acquisition (et autres fonctionnaires ou officiers publics

tenus aux obligations légales semblables) paient les créances communiquées.

1.2. L’avis (2.) En cas d’insuffisance d’actif pour désintéresser les créanciers, les notaires, commissaires des comités d’acquisition (et les autres fonctionnaires ou officiers publics tenus aux obligations légales semblables) adressent l’avis (2) par voie électronique. Le ou les receveurs qui ont signifié leurs créances conservent sous forme électronique :

(soit) un avis d’accord,

(soit) un avis dans lequel figure qu’il(s) procède(nt) à l’inscription de l’hypothèque

légale du Trésor avec rang particulier.

L’acte projeté doit être passé dans les trois mois à compter de l’expédition de l’avis notarial (1.) à défaut, pour ce dernier d’être nul et non avenu. Points d’attention Les Notaires, les Commissaires des comités d’acquisitions (et les autres fonctionnaires ou officiers publics tenus d’obligations légales semblables) sont tenus des mêmes obligations


vis-à-vis de la Région flamande, des communes… et (depuis peu) vis-à-vis de la Sécurité sociale (entrée en vigueur prévue le 01.03.2007 – projet « 4e voie » FEDICT). Par conséquent et pour répondre aux standards de l’E-Government, les flux automatisés relatifs à l’e-Notariat qui entrent au SPF Finances et qui quittent le SPF Finances doivent passer par le FEDICT (rôle d’intermédiaire à partir du 01.03.2007). Dans la même optique, les départements – sociaux et fiscaux – impliquées qui procèdent à leur propre analyse e-Notariat ont également été amenés à collaborer à l’instauration d’un projet commun de plus grande ampleur. Bloc d'activités

Le notaire adresse l'avis notarial (1.)

Les Notaires et les Commissaires de comités d’acquisitions qui sont amenés à établir un acte ayant pour objet l’aliénation ou l’affectation hypothécaire d’un immeuble, d’un navire ou d’un bateau situé en Belgique envoient l’avis par voie électronique (et via la FRNB pour les notaires) au centre unique constitué à cet effet au sein du SPF Finances, qui délivre un accusé de réception automatique. Le centre unique trie automatiquement les avis.

Le centre unique constitué à cet effet au sein du SPF Finances reçoit les avis/déclarations décrits dans le 1er bloc d’activité sous forme électronique. Il trie automatiquement ces avis/déclarations. Le tri s’effectue sur la base de critères objectifs de risque appliqués aux clients, au compte (existence ou non de dettes fiscales) du client et aux compétences des services. Lorsque les avis des clients répondent aux critères objectifs (pas de risque et pas de dettes), le centre unique envoie par voie électronique une réponse qui clôture la procédure matérielle, sans intervention des services. En l’absence d’une telle réponse, le centre unique transmet les informations relatives aux autres avis aux différents services impliqués.

Les services impliqués traitent l’information

Les services de taxation compétents traitent les informations des avis / déclarations, ET, le cas échéant, établissent un nouvel impôt à reprendre dans la notification fiscale en réponse au Notaire ou au Commissaire d’Acquisition. Dans tous les cas, ils informent électroniquement dans un délai de 7 jours les services du recouvrement compétents du traitement réservé à l’avis / déclaration. À leur tour, les services du recouvrement traitent les informations des avis / déclarations ainsi que celles provenant des services de la taxation. Chaque receveur concerné apprécie l’utilité de notifier les créances fiscales avant l’expiration du délai légal de 12 jours ouvrables, à compter de l’accusé de réception adressé par le centre unique au Notaire / Commissaire d’Acquisition. S’il estime qu’il n’y a pas lieu de notifier, il fournit une réponse « Néant » dans le même délai. Lorsque tous les receveurs concernés ont fourni une réponse (une Notification ou un avis Néant), le centre unique procède à un regroupement des réponses et adresse électroniquement un message consolidé au Notaire/Commissaire d’Acquisition. Le centre unique réceptionne également les accusés de réception des messages consolidés, provenant du Notariat. Un message consolidé « Néant » clôture la procédure notariale. En cas de notification fiscale, le paiement des créances notifiées, effectué par le Notaire/Commissaire d’acquisition permet de clôturer la procédure. Les acteurs de la procédure effectuent les traitements utiles après la notification


Le Notaire (la FRNB) ou le Commissaire du comité d’acquisition ayant réceptionné électroniquement une Notification ou un avis Néant en accuse réception de manière automatisée. Enfin, il doit, lorsque l’acte prévu a été passé, procéder au partage des sommes ou valeurs parmi les créanciers. En l’absence d’actifs pour désintéresser les créanciers, les Notaires, les Commissaires des comités d’acquisition (et les autres fonctionnaires ou officiers publics tenus d’obligations légales semblables) envoient l’avis (2.) par voie électronique (et via la FRNB) au centre unique constitué à cet effet au sein du SPF Finances. Toutefois, en cas d’insuffisance d’actif pour désintéresser les créanciers, les Notaires, Commissaires des comités d’acquisition (et les autres fonctionnaires ou officiers publics tenus aux obligations légales semblables) adressent l’avis (2.) par voie électronique. Lorsque le centre unique a réceptionné l’avis (2.), le système émet un accusé de réception automatisé et vérifie que chaque service Recouvrement a effectivement réceptionné cette information. La procédure est clôturée.

Outre les clôtures prévues de la notification de créances précitées, la clôture optimale est obtenue par le paiement des créances connues. Toutefois, la diversité du suivi est telle que les actions menant à d’autres types de clôture dépendent, d’une part, des mesures et accords consentis par les acteurs et, d’autre part, de la communication d’informations liées à d’autres fonctionnalités des processus P & R (ex. : l’envoi d’une main levée, …) ou à d’autres programmes à intégrer.

b. Cycle de vie récurrent E-Notariat est en production mais en évolution continue depuis quelques années maintenant. E-Notariat est en interaction avec plusieurs systèmes externes et doit s’adapter aux changements propres à es systèmes qui l’impactent. En moyenne E-Notariat doit effectuer des adaptations tous les 2 ans.

c. Indications concernant l'entretien évolutif futur

Adaptations de l'application aux évolutions technologiques.

Adaptations de l’application aux changements des échanges avec les partenaires (Fedict, Credoc,…)

Adaptations de l'application aux modifications de structure de l'organisation.

Adaptations de l'application aux modifications législatives


III. Finprof

a. Description fonctionnelle

Introduction

Le précompte professionnel est un impôt du type « chaîne avec établissement réparti ». Le traitement des déclarations est assuré par l’application FINPROF, en dehors du périmètre d’ICPC, tandis que la validation des montants est réalisée, dans le périmètre de PrP-Pays (en cobol), par rapprochement des montants des déclarations 274 précompte professionnel avec les montants repris dans les fiches de revenu 325 de l’application BOW (Belcotax On Web). Le précompte professionnel est une perception à valoir sur l’impôt sur le revenu : il est déduit, par l’employeur, du salaire versé au travailleur et payé à l’Etat. Le précompte professionnel est une source de financement importante pour les pouvoirs publics et les modalités de perception intégrées dans les instruments de politique économique doivent pouvoir s’adapter rapidement à des exigences à court terme (ex. loi de relance économique du 27 mars 2009 portant le report du versement du précompte, avec double précompte professionnel au dernier trimestre comme indemnité d’intérêt pour les entreprises qui ont souscrit un emprunt afin de payer ce double précompte).

Déclarations FINPROF.

Les déclarations du précompte professionnel sont réceptionnées par FINPROF. Cette application permet de recevoir les déclarations au format XML (SS274EUR-XML). Dans ce format, une déclaration 274 (Finprof:Declaration274) est un conteneur pour une ou plusieurs déclarations élémentaires (Finprof:SingleDeclaration) qui chacune concerne un employeur, un bureau de recette, une communication structurée de paiement (Finprof:PaymentReference) et comprend un ou plusieurs relevés de revenu (Finfprof:RevenuDeclaration). Chacun de ces relevés de revenu reprend, pour une nature de revenu (Finprof:RevenuNature), le montant du revenu (Finprof:TaxableRevenu), le montant du précompte (Finprof:Prepayment), la période correspondante (Finprof:Year et Finprof:Period) et l’année du relevé 325 correspondant (Finprof:Year325). Une déclaration 274 peut donc contenir des déclarations élémentaires distinctes qui concernent des entreprises différentes et/ou des bureaux différents, et/ou des périodes différentes.

Année Finprof :Year

Année d’attribution des revenus en 4 positions, soit l’année en cours, l’année-1 ou l’année-2

Code période Finprof :Period

Code de la période du précompte. Ce code est en 4 positions. Il s’agit :

soit d’un mois : code 0100 = janvier jusqu’à code 1200 = décembre

soit d’un trimestre : code 0103 = premier trimestre, code 0406 = deuxième trimestre, code 0709 = troisième trimestre, code 1011 : acompte quatrième trimestre, code 1012 = quatrième trimestre,

soit des 15 premiers jours de décembre, code 1215, pour les redevables qui déclarent plus de 2,5 million d’euros.

Année 325 Finprof :Year325

Année du relevé 325 correspondant. Cette donnée est optionnelle et a valeur d’année d’attribution des revenus. Pour une régularisation de revenus, l’année d’attribution peut cependant différer de l’année de


déclaration de revenus pour l’IPP (Year325). Par exemple, pour une récupération (retenue) en 2010 d’un trop versé en 2009, on aura pour la nature de revenu correspondante un relevé Finprof:RevenuDeclaration avec un revenu négatif, un précompte négatif et une année d’attribution Finprof:Year = 2010 et une année 325 Finprof:Year325 = 2009.

Nature des revenus Finprof : RevenuNature

Il s’agit de manière générale du code correspondant au titre des revenus attribués. 10 = rémunérations ordinaires 11 = pensions et sommes y assimilées 12 = revenus de remplacement assimilés aux indemnités de maladie / invalidité 13 = allocation de chômage … 70 = réduction flamande Il existe cependant aussi des codes spéciaux pour la dispense de versement de précompte professionnel retenu (code 46 secteur marchand Art.275(7) CIR92) et pour le précompte professionnel retenu à reverser par l’Etat à un fond spécial (code 47 Maribel Social). [Voice tableau ci-après]

Revenus Finprof : TaxableRevenu

Montant positif ou négatif des revenus. On peut avoir dans le temps des montants positifs, puis négatifs, du fait d’une correction du montant du précompte. Il y a cependant une limite dans le temps à ces corrections (les corrections négatives ne sont plus admises à partir du 1er septembre de l’année clôturée).

Précompte professionnel Finprof : Prepayment

Montant positif ou négatif du précompte retenu. Ce montant est aussi négatif dans le cas des dispenses de versements (Code 46) et du Maribel social (Code 47).

Employeur Finprof : Employer

En général : numéro d’entreprise en 10 positions ; exceptionnellement, l’administration attribue elle-même un numéro qui commence par 01. Le numéro d'entreprise se compose : Position 1 : 0 Positions 2 à 8 : numéro de base Positions 9 et 10 : contrôle : reste de la division du numéro de base par 97 ; si 0 alors 97 Le numéro d’employeur peut encore ne comporter que 9 chiffres Positions 1 à 7 : numéro de base Position 8 et 9 : contrôle : reste de la division du numéro de base par 97 ; si reste=0 alors remplacé par 97

Communication structurée Finprof : PaymentReference

Il s’agit de la communication structurée en 12 positions. Elle est constituée : Positions 1 à 7 : numéro de base de l’employeur Positions 8 à 10 : code période, numérique > 600 Positions 11 et 12 : contrôle, reste de la division des 10 chiffres précédents par 97 ; si reste = 0 alors remplacé par 97. La codification des périodes en 3 positions (au lieu de 8 pour Finprof :Year (4 positions) + Finprof :Period (4 positions) suppose une convention de correspondance avec glissement : En 2008 601 renvoie à 2006 – 0100 701 renvoie à 2007 – 0100 801 renvoie à 2008 – 0100


901 renvoie à 2009 – 0100 En 2009 601 renvoie à 2010 – 0100 701 renvoie à 2007 – 0100 801 renvoie à 2008 – 0100 901 renvoie à 2009 – 0100 En 2010 601 renvoie à 2010 – 0100 701 renvoie à 2011 – 0100 801 renvoie à 2008 – 0100 901 renvoie à 2009 – 0100 Etc.

Bureau de recette Finprof : Receipt

Identification du bureau de recette Le paiement du précompte professionnel est fait sur le compte (général) du Bureau de recette au lieu d’être réalisé sur un ou plusieurs comptes spécifiques (comme c’est maintenant le cas pour les Versements Anticipés). Cette utilisation du compte général pose évidemment problème dans la mesure où la codification utilisée par le précompte professionnel réduit énormément le nombre de communications structurées disponibles pour les autres paiements à ces bureaux de recette.

Pour une entreprise et une période donnée, on peut avoir plusieurs déclarations (Finprof:SingleDeclaration) liées à un même type de revenu, notamment du fait des dispenses de versement du précompte professionnel.

b. Cycle de vie récurrent L’application Finprof est en production. Le cycle des mises à jour et adaptations dépend des accords de modifications de l’application discutés avec l’Union des Secrétariats Sociaux (stackeholder principal) ainsi que des évolutions techniques tant internes qu’externes.




Adaptations de l'application aux modifications législatives


IV. e-Deduction (SAFS CV)

a. Description fonctionnelle Introduction eDeduction vise à établir des transmissions de retenues de façon électronique via la BCSS entre un créancier le SPF FINANCES (les bureaux de recouvrement de l’AGPR) et un tiers-saisi l’ONVA (caisses). Les retenues en question concernent uniquement les saisies-arrêt fiscale simplifiées gérées par l’article 85bis du CTVA et les articles 164/165 de l'AR/CIR92 dérogeant en partie aux dispositions du CJ relatives à la saisie-arrêt. Ce qui prévoit la possibilité au receveur d'intenter une saisie-arrêt sans intervention d'un huissier. La SAFS est la seule poursuite qui peut être décidée et mise en œuvre par le receveur. eDeduction se limite à la communication de données relatives aux retenues et en particulier aux saisies-arrêt fiscale simplifiées (SAFS) entre créanciers et tiers-saisis, de la création d’une SAFS jusqu’à sa mainlevée avec éventuellement des modifications au cours de la durée de vie de la retenue. Seule la gestion de nouvelles SAFS est prise en compte. Les interactions directes avec le débiteur (notification, opposition, etc.) ne sont pas gérables via eDeduction, tout comme les interactions avec la Chambre Nationale des Huissiers de Justice (mise à jour du Fichier Central des Avis de saisies). Flux d’activités eDeduction est le nom du projet côté BCSS et ONVA. Du côté du SPF Finances, le projet est nommé SAFS_CV. L’application SAFS_CV est responsable de la collecte des actes de SAFS introduits par les bureaux de recette à partir de l’application métier source ICPC, de leur validation, de leur transfert et du traitement de la réponse de l’ONVA. Concrètement, on peut résumer les étapes suivantes lors de la création d’une nouvelle SAFS : L’agent d’un bureau de recette encode une SAFS (247.7) dans ICPC pour un certain débiteur et envers une certaine caisse ONVA. Quotidiennement, un batch au niveau d’ICPC détecte les créations de nouvelles SAFS envers l’ONVA et génère un fichier plat reprenant l’ensemble des informations de la saisie qu’il place sur le FTP. Un batch quotidien prévu au niveau système SAFS_CV récupère le fichier des nouvelles saisies et le place dans la DB du système SAFS_CV. Ce dernier contrôle, valide les

Bureau

de recette

Application

Source

ICPC

FTP

SAFS_CV

BCSS

eDeduction ONVA


données contenues dans le fichier et envoi la SAFS de façon électronique vers l’application eDeduction de la BCSS. La BCSS effectue également quelques contrôles de validation puis envoi la SAFS à l’ONVA. L’ONVA reçoit la nouvelle SAFS et après quelques autres contrôles de validation, elle traite la saisie et renvoi à eDeduction la situation de la SAFS en indiquant s’il est le premier créancier concernant ce débiteur ou non. La BCSS transfert alors la réponse de l’ONVA vers l’application SAFS_CV. Via un batch quotidien, SAFS_CV traite ces réponses, les valident puis les renvoi vers le FTP. L’application ICPC va chercher via un batch quotidien les fichiers de réponses de l’ONVA et stocke l’information dans sa DB pour ensuite afficher le résultat sur un écran ICPC. L’agent consulte alors l’information 1ersaisissant ou pas 1ersaisissant sur l’écran ICPC de la SAFS concernée. Concrètement, on peut résumer les étapes suivantes lors de la mise à jour ou de la clôture d’une SAFS déjà crée électroniquement: Les phases sont similaires à celles décrites dans le cadre de l’institution d’une nouvelle SAFS, à cette différence près qu’il n’y a pas de retour de l’ONVA et que le fonctionnaire ne procède à aucune manipulation spécifique dans ICPC. Le flux de la clôture est également effectué mensuellement et est détecté lorsque les soldes de la saisies sont égaux à 0 ou si l’agent encode une date de clôture de saisie. Le flux de clôtures est également exécuté mensuellement et est détecté si les soldes des saisies sont égaux à 0 ou si le fonctionnaire encode une date de clôture de la saisie. Nous pouvons résumer la vie d’une SAFS au moyen des business process suivants (flux d'activités) : Quatre actions principales à effectuer par le créancier : 1. La création de la SAFS; 2. La mise à jour de la SAFS tant que celle-ci n’est pas clôturée; 3. La transmission de la SAFS à un autre créancier (sera utilisé dès l’opérationnalisation du K3); 4. La mainlevée lorsque la retenue n’a plus de raison d’être. Une action importante à exécuter par le tiers saisi : 5. Informer le bureau de recette de la situation de sa demande de SAFS en lui indiquant s’il est le premier créancier concernant ce débiteur ou non.

b. Cycle de vie récurrent SAFS_CV est en production depuis mis mars 2015. Tel que mentionné plus haut, seule l’application métier source ICPC génère des SAFS via le système. Dans un avenir proche, l’application métier source STIRON pourra également envoyer des SAFS via ce système. Le système SAFS_CV a été développé de telle façon que les use cases ne doivent pas être modifiés.



- Adaptations de l'application aux évolutions technologiques. - Adaptations de l’application aux évolutions technologiques externes - Adaptations de l'application aux modifications de structure de l'organisation. - Adaptations de l'application aux modifications législatives


V. Avis de saisies (FCA)

a. Description fonctionnelle Il s’agit d’une application java qui fait appel au web service de la Chambre National des Huissiers de Justice (CNHJ) afin de déposer de manière électronique les avis de saisies structurés au format xml à la centrale des avis de saisie. Différentes applications métiers sources (voir schéma ci-dessous) fournissent un fichier csv qui est ensuite converti en xml par CBB_Fin avant de l’envoyer à CBB Chambre Nationale des Hussiers de Justice (CNHJ) via l’ESB (Entreprise Service Bus).

Schéma :

b. Cycle de vie récurrent L’application CBB est en production. Le cycle des mises à jour et adaptations dépend des releases de CBB_CNHJ qui ont lieu actuellement une fois par an.




Adaptations de l'application aux modifications législatives/CBB_CNHJ.

ICPC

STIRON

CBB-FTP

CBB-FIN

CBB-NKCN ESB

Autres Apps Andere Apps


Lot 2 - Entretien (spécifique) de STIPAD,...

Application En


Stipad oui 5x12

…

I. Stipad


L’Administration générale de la Documentation patrimoniale a intégré et optimisé plusieurs systèmes existants dans un seul système informatique, l’application STIPAD – Système Traitement Intégré Patrimoniumdocumentatie. L’application STIPAD se compose de différents modules qui ont été mis en production au fil des ans :

depuis avril 2009, les modules « Plan de géomètre » « Gestion des dossiers des

services des Grands levers » (lot A) ;

depuis décembre 2012, le module d’inscription des contrats de mariage, des

donations, des biens meubles, des immeubles à l’étranger et des testaments (lot

C/TP) ;

la délivrance des titres trentenaires (lot B/titre) depuis mars 2013 et des extraits

cadastraux (lot B/extraits) depuis octobre 2013 ;

depuis le 19 mai 2015, le dernier module (lot C/D) de la mise à jour de la

documentation patrimoniale.

Avec la mise en production de ce dernier module qui constitue le cœur de l’application STIPAD, la Direction générale de la Documentation patrimoniale (DGDP) franchit une étape importante dans la réalisation de son système informatique, de son organisation et de ses processus spécialisés.

Les principales fonctionnalités de l’application sont actuellement :

• Traitement des actes de transfert de droits immobiliers, notariés et sous seing privé

• Actes de transfert art 1

• Acte de base

• Acte de lotissement

• Mise à jour de la parcelle cadastrale sauf le plan cadastral :

• Etablissements, modification, descriptions (nature et données fiscales)


• Traitement des plans de géomètres qui peuvent être consultés via MyMinFinPro

• Gestion des dossiers des services des Grands levers

• Délivrance :

• Origine de propriété

• Titres trentenaires

• Attestations de revenu cadastral (RC)

• Extraits cadastraux

• Mise à jour d’office, transactions sur biens meubles et biens immeubles à l’étranger,

remplacement de l’application AS-IS (TP380 et 385)

• Consultation de données patrimoniales dans PATRIS (= base de données de

l’application STIPAD)

• Consultation Personnes

• Consultation historique LOCO

• Consultation historique TP380/385

• Consultation, fusion et gestion des documents associés aux fonctionnalités précitées

L’application doit être disponible 7 jours sur 7, 24 heures sur 24.

b. Cycle de vie récurrent

Les premiers modules de STIPAD ont été mis en production en 2009, le dernier en 2015.

STIPAD n’a pas de durée de vie programmée, mais on peut estimer que ce type d’application doit vivre 10 ans. Cela ne signifie pas que l’application devra être entièrement recréée dans 10 ans, mais que ses développements annuels apporteront des modifications profondes par rapport à la version actuelle du point de vue des technologies utilisées (stockage de données, langage de programmation, code, interfaces…) ou même des fonctionnalités de l’application.

Ces changements doivent être mis en œuvre soit par le biais d’un entretien évolutif annuel

qui pourrait être repris dans un contrat-cadre, soit par l’élaboration de nouveaux Business

Cases et cahiers des charges pour la modification ou l’ajout de nouvelles fonctionnalités

importantes (ex. : intégration complète de la publicité hypothécaire dans STIPAD).

Pour résumer, une telle application doit faire l’objet d’un entretien de support permanent afin

de garantir sa disponibilité sept jours par semaine, et ce, avec un SLA strict quand des délais

de réparations sont fixés afin de garantir cette disponibilité.

Les développements visés :


Les développements et améliorations suivants sont visés :

1. Une série de changements pour les premiers modules qui ont été mis en

production (lots A, B, C-TP). Il s’agit principalement d’améliorations destinées

à faciliter le travail des fonctionnaires sur le terrain. Ces changements sont

repris dans l’application Star Team et ont été classés selon leur priorité par

l’AGDP :

Amélioration de la différenciation des dossiers Redéfinition des valeurs standards de plusieurs champs Amélioration de la sélection des données lorsqu’une recherche donne plus de 100 résultats Amélioration du contenu de l’information fournie au client Uniformisation des écrans des zones de commentaires Déplacement du produit « Attestation RC » pour l’insérer dans la délivrance de l’extrait cadastral

2. Une série d’améliorations pour le dernier module (lot C/D) livré le 19 mai

2015. Une première liste de ces améliorations est identifiée un mois après la

production et reprise dans l’application Star Team. D’autres améliorations

nécessaires pourraient cependant s’ajouter au cours des prochaines

semaines d’exploitation. La liste ci-dessous n’est donc pas limitative et pourra

faire l’objet d’une nouvelle répartition selon la priorité au moment de la

négociation du contenu de la mission. Ces améliorations sont réparties par

flux spécialisé :

Amélioration du flux de production des actes notariés :

Amélioration du suivi des clauses et conditions Amélioration et extension de l’échange XML avec l’application HYPO Amélioration et extension de l’échange XML avec l’application DER Amélioration des règles de consolidation et de validation des droits Amélioration du traitement des actes complexes comprenant plusieurs transactions

Améliorations du flux de production des successions : Ajout de traitements automatiques pour l’attribution de droits Adaptation pour le traitement de déficits

Améliorations du flux de production du lot cadastral : Permettre des identifications préalables étagées, y compris les identifications de modification préalable Amélioration des règles de contrôle lors de la clôture des dossiers Amélioration du calcul des superficies Ajout de nouveaux types de parcelles Amélioration du suivi et du traitement des notifications des revenus cadastraux

Améliorations relatives à l’ensemble des flux : Amélioration des possibilités en matière de réattribution et d’orientation des dossiers


Suivi automatique des changements de PERSIDF dans l’application SITRAN Optimisation des écrans et de la navigation

3. Une série de développements identifiés afin de satisfaire aux nouveaux

besoins, souvent en dehors du projet. Ces développements consistent pour la

plupart en la configuration d’interfaces sous la forme de services Web

Une interface avec adaptation de l’écran entre les applications STIPAD et FedCom Une interface automatisée entre les applications STIPAD et CadBuild11

Une interface automatisée entre les applications STIPAD et CadGIS12

Une interface automatisée entre les applications STIPAD et ANNUCOMP13

Une interface automatisée entre les applications STIPAD et COMFOR14

Consultation intégrée des documents d’autres applications (ex. : ScanDosi15, Auto-Norif16…)


L’entretien prévu est indiqué dans les points précités.

Il existe également dans l’outil ProjectMaster une série de Business Cases qui courent

jusque 2016-2017, mais qui doivent à nouveau être pris en considération dans le cadre des

négociations en cours (objet de cette note) pour un contrat-cadre relatif à l’entretien des

applications du SPF Finances.

L’application est couverte par un entretien de support jusqu’au 31/03/2016.

11) CADBUILD est l’application utilisée par l’Administration Mesures et Evaluations pour l’estimation des

parcelles 12) CADGIS est la future application de gestion du plan cadastral 13) ANNUCOMP est le guide des compétences du SPF Finances 14) COMFOR est l’application qui gère la comptabilité et les registres de formalités de l’Enregistrement 15) ScanDosi est l’ancienne application de numérisation des documents liés aux mutations 16) Anto-Notif est l’ancienne application de notification des revenus cadastraux


Lot 3 – Entretien (spécifique) de FSP, Pandora, Cautionnements solidaires (SP10A), Faillites (SP10B), Grootboek/Grand Livre, CDC Dmat.

Application En


Fonds spécial de Protection (FSP) oui 7x24x365

Pandora oui 7x24x365

Cautionnements solidaires (SP10A) oui 5x12

Faillites (SP10B) oui 5x12

Grand Livre oui 7x24x365

CDC Dmat non 5x12

…

I. Fonds spécial de Protection (FSP)

d. Description fonctionnelle L’application FSP a été développée pour permettre au Fonds spécial de Protection d’intervenir en cas de défaillance d’une institution financière ou d’une entreprise d’assurances. Ce fonds offre une garantie aux clients de ces institutions et les indemnise sous certaines conditions à concurrence d’un montant maximal de 100.000 euros lorsque l’institution ne peut plus honorer ses engagements. À titre d’information : la description ci-dessous concerne l’application telle qu’elle a été mise en production au terme du projet de FSP2 (prévu à fin avril – début mai 2015). Le point 3 présente un aperçu des adaptations qui ont été prévues dans le cadre du projet FSP3, qui sera lancé en 2016. Dans le volet « administration », le collaborateur du Fonds spécial de Protection peut créer de nouveaux paramètres. Il le fera en cas de défaut effectif d’une institution, lorsque le Fonds doit intervenir. Dans ce volet, il est également possible de modifier ou de supprimer les données des institutions. Lors de la connexion à l’application, le collaborateur doit toujours choisir une institution et les opérations qui suivent s’effectuent toujours par institution. En deuxième lieu, l’application prévoit le chargement des données provenant de l’institution via un fichier CSV (fichier FSP), avec un nombre très limité de validations (la plupart des validations sur le contenu s’effectuent en amont, en dehors de l’application, dans un programme Access). Après le chargement, plusieurs lignes de paiement (= dossiers) s’affichent dans l’application. Elles peuvent être modifiées de plusieurs manières : en modifiant les champs dans l’application, par des demandes d’ayants droit introduites via MyMinFin et par le chargement d’un fichier CSV rempli par un collaborateur du Fonds spécial de protection. Dans ce dernier cas, le matching s’effectue automatiquement par l’application sur la base du numéro de registre national, du numéro d’entreprise ou numéro de TVA. Quelques exemples de modifications qui peuvent être apportées dans le dossier de cette manière : saisie d’un numéro de compte pour le versement, dans le cas d’un contrat d’assurance : choix entre versement ou transfert vers une autre entreprise d’assurances, adresse…

Il existe également une connexion avec Sitran qui ajoute le numéro de registre national des ayants droit sur la base de certaines données.


Un troisième élément important de l’application comprend les fonctionnalités qui portent sur le versement d’une indemnité à un ayant droit (s’il choisit le versement) ou à une autre entreprise d’assurances (s’il choisit le transfert). Cette possibilité de choix est une des fonctionnalités qui ont été développées spécifiquement pour le cas où l’institution défaillante est une entreprise d’assurances.17 Lorsque l’on opte pour le versement en cas de défaut d’une entreprise d’assurances, des calculs fiscaux doivent d’abord être exécutés – en dehors de l’application – sur la base d’un fichier CVS exporté de l’application. Les résultats seront ensuite remplis dans ce fichier, puis à nouveau chargés dans l’application. Le montant à verser – chargé initialement via le fichier FSP – est recalculé sur cette base. Il est ensuite possible de scinder une ligne de paiement et d’effectuer le versement à plusieurs personnes. Le collaborateur saisit le numéro de registre national ou le numéro d’entreprise dans l’application, après quoi les autres données sont automatiquement extraites de Sitran. Ensuite, il est possible de procéder au versement effectif. L’ordre de paiement est donné par le collaborateur dans l’application, après quoi le fichier de paiement aboutit dans BTM via une série de programmes internes de l’AGTrés et le mainframe (donc en dehors de l’application). Là, il est signé, après quoi les paiements sont exécutés. Deux modes de paiement ont été prévus : virement ou assignation postale (pas utilisé actuellement, mais prévu). Au moment où l’ordre du paiement est donné, un fichier est créé pour Fedopress, qui génère et envoie à l’ayant droit et/ou au tribunal des lettres sur la base de modèles avec un décompte. Il existe en outre un volet « comptabilité » dans lequel les fichiers CODA provenant de BPost peuvent être chargés et réconciliés automatiquement dans l’application après paiement. Si le paiement a été exécuté correctement, cela sera indiqué dans le dossier, avec la date d’exécution du paiement. Il n’existe cependant pas de possibilité de traiter des retours à l’heure actuelle. Le statut n’est pas modifiable et une nouvelle tentative de paiement est mise en œuvre entièrement en dehors de l’application. Un dernier volet est prévu spécifiquement pour les entreprises d’assurance : si l’on choisit un versement, plusieurs déclarations fiscales doivent être établies après l’exécution du paiement. Il s’agit d’une déclaration Finprof dans les 15 jours à compter de la fin du mois dans lequel le versement a eu lieu, et d’une déclaration Belcotax durant l’année suivant le versement, d’une déclaration de précompte mobilier peu après le versement et/ou de l’envoi de fiches papier via Fedopress. Pour les déclarations Finprof et Belcotax, un fichier XML est créé. Il pourra ensuite être chargé – manuellement – dans les applications Finprof et Belcotax. Pour la déclaration de précompte mobilier, un fichier CSV est créé. Il contient toutes les données nécessaires à la saisie – manuelle – dans PM-on-web. Pour les fiches papier, un fichier est créé pour Fedopress, qui crée les fiches sur la base d’un modèle et les envoie aux ayants droit. Via IAM, plusieurs rôles sont appliqués dans l’application. Il existe également un système de logging qui enregistre certaines données. Pour ce qui concerne l’introduction d’une demande par un ayant droit via MyMinFin: ce volet spécifique de MyMinFin ne sera ouvert qu’en cas de défaut d’une institution, c’est-à-dire quand le fonds devra intervenir.

e. Cycle de vie En principe, aucune intervention manuelle n’est nécessaire. Il n’y aura entretien que lorsque des bugs sont constatés. Une extension ne sera nécessaire que si l’on constate que des

17 Il n’existe pas de possibilité de choix lorsque l’institution défaillante est une banque.


fonctionnalités indispensables manquent ou si une évolution dans les obligations légales exige le développement de nouvelles fonctionnalités (voir aussi point 3).

f. Indications concernant l'entretien évolutif futur L’application devra être adaptée et/ou étendue ; cela se déroulera dans le cadre du projet FSP3. L’analyse business commencera en 2015 et se terminera en 2016. Le dossier ne sera par conséquent introduit à l’IF qu’en 2016. Il n’est pas encore acquis que l’on travaillera sur le budget du Fonds même, ou sur le budget du SPF Finances. Tout dépendra de la nouvelle législation qui sera développée dans le courant des années 2015-2016. Vous trouverez déjà ci-dessous une première liste non exhaustive des interventions prévues :18

Modification du moment où la lettre est envoyée au demandeur (dans l’application

actuelle, c’est au moment où l’ordre de paiement est donné, mais cela ne peut

normalement se faire que lorsque le chargement du fichier CODA confirme que le

paiement a été exécuté)

Modification de la manière dont un ayant droit est ajouté : même des personnes sans

numéro national doit pouvoir être ajoutées.

Modification de la manière dont les dossiers peuvent être recherchés + modification

de la présentation des résultats de recherche.

Prévoir une navigation plus aisée entre les différentes fenêtres.

Peut-être nécessaire (encore à analyser) : adaptation du mode de réconciliation des

demandes manuelles avec les dossiers présents dans l’application (exemple :

séparément par institution)

Adaptation des fonctionnalités relatives aux déclarations fiscales (Belcotax, Finprof,

précompte mobilier) de sorte que les modifications apportées à ces déclarations

puissent être recueillies plus facilement.

Prévoir les fonctionnalités nécessaires afin que le FSP puisse intervenir en cas de

défaillance d’une société coopérative (nouveau type d’institution)

Ajout d’un contrôle sur le montant maximal de 100.000 euros (pour l’ensemble des

lignes de paiement d’un client)

Mise en relation des différentes lignes de paiement (= dossiers) d’un même client.

Ajout de la possibilité d’exporter des rapports/statistiques/inventaires

Extension de l’utilisation de Sitran (très limitée actuellement)

Intégration du module de pré-validation (actuellement en dehors de l’application,

dans Access) dans l’application pour tous les types d’institutions (= ajout de contrôle

du fichier FSP)

Intégration dans l’application de l’ensemble de la procédure de paiement, y compris

l’envoi à BTM (passe actuellement via le mainframe).

Ajout d’un error log qui pourra être consulté par les utilisateurs de l’application

Prévoir davantage de statuts

Ajout de la possibilité de traiter des retours (paiements non exécutés)

18 Puisque que l’analyse business n’a pas encore été établie et la législation est en plein développement, cette

liste doit être considérée comme provisoire. Elle pourra encore être modifiée en profondeur.


Offrir la possibilité à des personnes non physiques d’introduire une demande avec

annexes via MyMinFin (n’existe aujourd’hui que pour les personnes physiques)

Amélioration de la traçabilité : certaines étapes automatisées doivent être mieux

traçables (consultation par les utilisateurs de l’application), par exemple : chargement

de demandes via MyMinFin, envoi de courrier,...

Ajout de validations supplémentaires

Adaptation du manuel d'utilisation

Tests de performances destinés à vérifier si le service Web est capable de traiter un

fort afflux de demandes via My MinFin dans une période réduite + éventuelle

intervention pour accroître la performance

Plusieurs interventions de moindre envergure accroissant la flexibilité dans le traitement des dossiers et la convivialité de l’application

Peut-être nécessaire (encore à analyser) : chargement de certains documents (attestations/déclarations tribunal) et stockage dans Filenet + consultation de ces documents dans l’application.

Peut-être nécessaire (encore à analyser) : possibilité d’établir une distinction entre différents types de dossiers qui nécessitent un traitement différent

Peut-être nécessaire : prévoir des lettres supplémentaires


II. Pandora

a. Description fonctionnelle L’application Pandora a été développée pour permettre à la Caisse des Dépôts et consignations (CDC) de recevoir, gérer et restituer les avoirs dormants. Les avoirs dormants sont les comptes en liquide et les prestations de contrats d’assurance qui doivent être transférés sous certaines conditions par des banques ou des entreprises d’assurances. À titre d’information : je décris l’application telle qu’elle est en production actuellement. Un projet est actuellement en cours (Pandora extension 1) dans le cadre duquel l’application est modifiée, notamment à la suite du fait que la CDC est confrontée à une nouvelle obligation légale : la réception, la gestion et la restitution des contenus de coffres-forts dormants. Comme l’analyse fonctionnelle est encore en cours et la mise en production n’aura lieu qu’en janvier 2016, je n’ai pas tenu compte de ce nouveau projet dans le premier point et je ne décris que la situation actuelle. Je reviendrai au projet en cours au point 3. La première étape de la procédure est l’envoi de données relatives à l’avoir et à l’ayant droit par l’institution (banque ou entreprise d’assurances) à Identifin, une ASBL qui intervient comme intermédiaire entre l’institution et la CDC. L’envoi s’effectue par message XML ou par fichier Excel. Identifin exécute une première validation et convertit le fichier – si Excel – en un fichier XML. Celui-ci est envoyé à l’application Pandora, qui exécute une validation syntactique et sémantique. Si le fichier ne résiste pas à la validation, il est refusé. S’il est valable, les données sont chargées de l’application. On renvoie à la fois un ACK technique et un message PAM à Identifin (success ou error) qui le fournit à l’institution. L’institution est obligée de virer les avoirs sur le compte de la CDC dans les cinq jours ouvrables après l’envoi du message XML. Dans l’écran « réception des paiements », le collaborateur de la CDC effectue une recherche sur la référence du message XML et saisit manuellement la date à laquelle la CDC a reçu les fonds. La date de prescription et, plus tard, les intérêts en cas de restitution, seront calculés sur la base de cette date. L’application contient en outre une série d’écrans liés à la gestion. Les données suivantes doivent essentiellement y être remplies : taux d’intérêt par devise et taux de précompte mobilier (chaque mois), données relatives à la gestion des titres (pas utilisées actuellement). Les collaborateurs de la CDC peuvent rechercher des dossiers selon différents critères et modifier les données à caractère personnel. De plus, les citoyens peuvent chercher eux-mêmes s’il existe un avoir dormant à leur nom dans le portail MyMinFin. Ils doivent se connecter avec leur e-ID ou un token sur la base desquels ils sont identifiés selon leur numéro de registre national. L’écran affiche ensuite si un avoir dormant a été retrouvé dans la base de données. Les citoyens qui pensent avoir droit à un avoir peuvent introduire une demande de restitution pendant 30 ans. Si le collaborateur retrouve effectivement un avoir auquel le citoyen a droit, il peut procéder à la préparation de la restitution en remplissant un numéro de dossier interne, un numéro de compte et le pourcentage de restitution. Si un citoyen a droit à un avoir au nom d’une personne tierce (par exemple en qualité d’héritier), le collaborateur de la CDC peut ajouter une nouvelle personne dans l’application et préparer ensuite la restitution à cette personne. Il est également possible de restituer un avoir dormant à plusieurs personnes (par exemple plusieurs héritiers). Dans un écran suivant, le dossier parcourt différents statuts avant que la restitution soit confirmée. D’abord, il est placé sous statut W, et un fichier Excel avec les données du


dossier est envoyé vers une boîte de messagerie spécifique de la CDC. Si le montant à verser s’élève au moins à 250 euros, le collaborateur – en dehors de l’application – envoie ensuite ce dossier au fisc, qui a cinq jours pour vérifier si des dettes fiscales sont ouvertes à son nom. Il y a deux options possibles :

a) S’il n’y a pas de dette ou si le montant est inférieur à 250 euros, le collaborateur place

le dossier sous statut F, puis sous statut C. Cela implique la confirmation de la

restitution, après quoi il est possible de tirer de l’application une liste Excel qui est

utilisée comme fichier de paiement. Le paiement s’effectue entièrement en dehors de

l’application, via un programme Access et une signature dans BTM. Lorsque le

dossier est placé sous statut C, les intérêts et le précompte mobilier à retenir sont

calculés automatiquement et une lettre est générée via Fedopress, puis envoyée

localement.

b) En cas de dettes fiscales, le fisc peut demander de bloquer le dossier pendant 30

jours. Le collaborateur placera alors le dossier sous statut B et attendra une saisie

(en dehors de l’application). Dès que la saisie est réceptionnée, le collaborateur peut

introduire le montant de la saisie, et s’il reste encore un montant ensuite, poursuivre

la restitution au citoyen suivant la procédure normale (voire description au point a).

Dans certains dossiers d’assurance, des impôts doivent être retenus. Une fonctionnalité est prévue qui permet de créer des fichiers XML qui peuvent être chargés – manuellement – dans Belcotax. Tant qu’aucune restitution n’a eu lieu, un dossier peut être révoqué à la fois par l’institution et par la CDC. C’est le cas lorsque les données ne sont pas correctes ou quand un dossier a été transmis à tort. Dans ce cas, les données restent cependant présentes dans l’application et consultables, mais le dossier en question est placé sous statut D, ce qui empêche toute restitution. L’institution peut exécuter des révocations en envoyant un fichier XML, suivant la même méthode que pour le chargement des données. En revanche, la CDC peut exécuter une révocation en recherchant un dossier dans l’application, puis en cliquant sur un bouton prévu. Dans les deux cas, il est possible de saisir une date de remboursement. Le remboursement est exécuté en dehors de l’application. Une dernière fonctionnalité concerne une série de rapports exportables (sous format Excel). Il s’agit par exemple d’une fiche qui peut être utilisée pour recalculer mensuellement le précompte mobilier, une liste de toutes les restitutions exécutées (dossiers sous statut C) pour une période à déterminer, une liste de tous les dossiers révoqués pour une période à déterminer…

Il faut cependant évoquer une série de fonctionnalités de base qui ont déjà été prévues pour ce qui concerne la réception, la gestion et la restitution des coffres-forts et comptes titres dormants. Comme cela a déjà été signalé, un projet « Pandora extension 1 » est en cours dans le cadre duquel les fonctionnalités liées aux coffres-forts dormants seront élaborées et complétées. Pour ce qui concerne les fonctionnalités liées aux comptes titres dormants : elles ne sont actuellement pas encore utilisées. Si la CDC procède un jour à l’opérationnalisation du transfert de comptes titres dormants, les fonctionnalités existantes seront abordées et devront être étendues.

b. Cycle de vie En principe, aucune intervention manuelle n’est nécessaire. Il n’y aura entretien que lorsque des bugs sont constatés. Une extension ne sera nécessaire que si l’on constate que des


fonctionnalités nécessaires manquent ou si une évolution dans les obligations légales exige le développement de nouvelles fonctionnalités (voir aussi point 3).

c. Indications concernant l'entretien évolutif futur Le projet « Pandora extension 1 » a été lancé en décembre 2014. Il prévoit une nouvelle version de l’application, dont la mise en production est prévue en décembre 2015. Ce projet comprend trois grands éléments :

ajout de toutes les fonctionnalités nécessaires à la réception, la gestion et la

restitution des coffres-forts dormants, notamment à la génération et au scanning de

codes-barres (= parties 1 à 3),

extension des possibilités de recherche du citoyen via MyMinFin (correction et

extension du matching) et ajout de la possibilité pour les citoyens d’introduire une

demande avec annexes via MyMinFin (= partie 4),

autres fonctionnalités : extension des rapports/inventaires/statistiques, adaptation du

schéma XSD assurances, création de plusieurs profils IAM, ajout d’un journal

d’audit... (= partie 5).

Au terme de ce projet, un projet « Pandora extension 2 » est également prévu, qui pourra commencer au plus tôt en 2016, peut-être seulement en 2017. Vous trouvez ci-dessous une description high level de ces projets pour ce qui concerne l’application Pandora.

a) Pandora extension 119

Partie 1 : réception des coffres-forts dormants

Dans une première phase, la banque transmet – via Identifin – un fichier XLM à l’application Pandora, avec toutes les données relatives au locataire du coffre-fort, le coffre-fort et les enveloppes scellées qui contiennent le contenu du coffre-fort. Dans ce cadre, le schéma XSD est adapté. La validation se déroule de la même manière que pour les comptes et contrats d’assurance dormants (voir point 1). La procédure de révocation qui existe déjà pour les autres types d’avoirs dormants est également reprise. Les données sont ensuite chargées dans l’application, un code-barres étant attribué à chaque enveloppe. L’application Pandora calcule automatiquement la prochaine date de remise disponible. Ce, sur la base d’un calendrier ccff dans lequel certains jours sont prévus et auquel s’appliquent des paramètres modifiables (nombre maximum d’enveloppes par jour et temps d’attente minimal entre la réception des données et la date de livraison). Le collaborateur aura toujours la possibilité de modifier manuellement cette date de remise. Une lettre de convocation et des étiquettes sont générées via Scriptura. Elles sont envoyées par un collaborateur à la banque. La banque doit coller les étiquettes sur les enveloppes et les proposer ensuite à la CDC. Là, les étiquettes seront scannées, et l’application enregistre ainsi les coffres-forts concernés comme reçus. Le collaborateur peut confirmer par une option à cocher que l’inventaire a également été fourni. Cet inventaire sera ensuite scanné par un collaborateur (pas de codes-barres, photo de l’inventaire) et joint au dossier dans l’application. Un accusé de réception est généré pour chaque coffre-fort. Il est remis sur papier à la banque.

19 Cette description contient un aperçu des principales fonctionnalités, mais ne peut pas être considérée comme

exhaustive.


Identifin

1.Traiter le fichier

3.Attribuer un

code-barres/

enveloppe

5.Générer une

étiquette Code-

barres / enveloppe

7.Enregistrer code-

barres des

enveloppes reçues

4.Enregistrer les

données

8.Réconcilier

l’enveloppe avec

les données DB

12.Consultation

des données

BG

Avoirs dormants

CDC13.Gestion des

exceptions

€

Banque

Fichier XML

Fichier

XML

Excel

Monnaie Royale

6. Générer lettre

d’accompagne-

ment

Mail Room

Enveloppes

Avec

Codes-barres

Print room

2.Contrôler la

validité des

données

Scanner code-barres

Des enveloppes reçues 9.Enregistrer

enveloppe comme

reçue

10.Générer accusé

de réception

Print

User CDC

À la Monnaie Royale

11. Lier image de

l’inventaire à

l’enveloppe

Scanner inventaires

Message

PAM

Message

PAM

Partie 2 : traitement de demandes de restitution des coffres-forts dormants

Un ayant droit pourra introduire une demande de restitution du contenu d’un coffre-fort dormant pendant 30 ans. Lorsqu’un collaborateur du CDC reçoit une demande, il effectue une recherche dans l’application. Si un coffre-fort dormant est retrouvé auquel le demandeur peut avoir droit, le collaborateur le réservera. Il peut le faire pour plusieurs coffres-forts. Ensuite, il introduit la demande dans l’application et relie les coffres-forts réservés à cette demande. S’il y a plusieurs ayants droit pour un même coffre-fort (par exemple plusieurs héritiers), ceux-ci devront désigner une personne qui devra se présenter plus tard pour prendre réception du contenu du coffre-fort. La demande peut être assortie d’un statut « OK » ou « non OK », selon que le demandeur a rempli toutes les formalités nécessaires ou non (gestion en dehors de l’application). Dès que le statut est OK, une date de remise est automatiquement calculée (de manière semblable au calcul de la date de remise dans la partie 1). Une lettre de convocation est générée via Scriptura et envoyée par le collaborateur au citoyen.


1.Rechercher la/

les enveloppe(s)

13.Consultation

des données

BG

Avoirs dormants

CDC

14.Gestion des

exceptions

2.Afficher le

résultat

Ayant-droit

Demande écrite

Via MyMinfin

E-mail

Fax

Courrier

Remise CDC

Critères de recherche

enveloppes 3.Réserver les

enveloppes

cochées

Cocher enveloppe

4.écran

d’encodage des

demandesEncoder

5.Enregistrer

demande et lier aux

enveloppes

réservées

Garder dossier en

instance avec

enveloppes réservées

Critères de

recherche dossier6.Afficher résultat

Statut dossier NOK

9. Enregistrer statut

OK

7.Sélectionner un

dossier

8.Encoder

modification de statut

(NOK -> OK)

Statut dossier = OK

Mail Room

Print room

11.Enregistrer

enveloppe(s)

comme à restituer

12.Générer

courrier vers

l’ayant droit

10.Calculer date de

remise et enregistrer

Partie 3 : restitution des contenus des coffres-forts dormants

Le demandeur devra ensuite se présenter à la CDC. Le collaborateur établira à l’avance, pour chaque date de restitution, une liste des contenus des coffres-forts à restituer à cette date, afin que toutes les enveloppes puissent être préparées. Au moment de la remise, le code-barres de l’enveloppe sera scanné, après quoi l’application enregistrera l’enveloppe (et donc le coffre-fort) comme restituée. À ce moment, un accusé de réception sera généré qui devra être signé sur papier par le demandeur.


1.Sélectionner

enveloppes à

remettre jour J

10.Consultation

des données

BG

Avoirs dormants

CDC

11.Gestion des

exceptions

2.Afficher le

résultat

9.Clôturer dossier

Ayant-droit

Lancer requête

3.Générer un AR

personalisé par

enveloppe

7.Enregistrer AR

Liste

+

AR

Lancer l’impression

4.Enregistrer code-

barres des

enveloppes

5.Réconcilier

l’enveloppe avec

les données DB

8.Enregistrer

enveloppe comme

restituée

Gestionnaire

CDC

Avoirs dormants

(à la

Monnaie Royale)

Scanner

Codes-barres

6.Enregistrer

enveloppes

comme Sorties

Remise

enveloppes

Signature

AR

Encoder

AR

Partie 4 : MyMinFin

Le demandeur disposait déjà de la possibilité d’accomplir lui-même des recherches sur des avoirs en son nom propre dans notre base de données, et ce, via le portail MyMinFin. Cette possibilité de recherche était cependant insuffisante. En effet, les recherches étaient uniquement réalisées sur le numéro de registre national. Cela signifie que les dossiers dont la banque/entreprise d’assurances n’a pas transmis le numéro de registre national de l’ayant droit n’étaient pas retrouvés et que le demandeur voyait s’afficher un résultat négatif à tort. La recherche devra dès lors être adaptée. On devra pouvoir effectuer des recherches sur plusieurs critères, et ce, en deux phases. Dans une première phase, la recherche s’effectuera sur le numéro de registre national, comme c’est déjà le cas actuellement. Si elle ne donne aucun résultat, on effectuera dans une deuxième phase une recherche sur le nom, le prénom et la date de naissance. Si rien n’est retrouvé dans la base de données, le demandeur pourra quand même introduire une demande auprès de la CDC via MyMinFin (puisque les collaborateurs de la CDC peuvent effectuer des recherches plus ciblées). Pour ce faire, il pourra remplir et signer de manière électronique un formulaire qui aboutira dans la boîte de messagerie de la CDC.


Jusqu’à présent, un citoyen ne pouvait jamais réaliser de recherche au nom d’un tiers. Pour réaliser une recherche au nom d’un tiers, le demandeur doit en effet disposer d’un intérêt légitime. Celui-ci devra être démontré à l’aide d’éléments probants qui varient selon la qualité du demandeur, le montant de l’avoir… Il est impossible d’automatiser le contrôle de cet intérêt légitime, c’est pourquoi le demandeur n’aura pas la possibilité d’effectuer des recherches directement dans la base de données. Il sera cependant possible de remplir un formulaire de demande via MyMinFin, de le signer de manière électronique et de l’envoyer à la boîte de messagerie de la CDC. Ce formulaire devra contenir les données du tiers ainsi que les éléments probants (en annexe) qui démontrent l’intérêt légitime. Partie 5 : divers

Le projet « Pandora extension 1 » prévoit enfin encore quelques adaptations/extensions plus modestes. Une partie du projet porte sur la sécurisation de l’application.

Un module d’identification et/ou d’authentification pour gérer les accès aux

fonctionnalités. Il doit permettre de moduler les autorisations en fonction du type

d’intervenant et des fonctionnalités en question.

Un journal d’audit

Une sécurisation de l’application et du transfert de données qui empêche toute

intrusion et garantit l’intégrité des données.

Il existe déjà plusieurs possibilités de rapports dans l’application, elles seront étendues aux recherches multicritères, aux historiques et à des rapports supplémentaires Plusieurs petites adaptations au schéma XSD sont prévues pour ce qui concerne le transfert des contrats d’assurance dormants.

b) Pandora extension 220

Ci-dessous, vous trouverez une description high level des éléments qui devront être modifiés et/ou ajoutés dans l’application dans le cadre du projet « Pandora extension 2 ».

Modifications concernant le traitement de la réception des avoirs dormants, notamment aux niveaux suivants :

La génération et la fourniture d’une communication structurée aux institutions à la réception des données relatives aux avoirs dormants qui devra être utilisée lors du versement.

La possibilité de charger les fichiers comptables (par exemple CODA) dans l’application pour relier automatiquement la remise des avoirs dormants aux données reçues à l’aide des contrôles nécessaires. Un traitement manuel doit rester possible lorsqu’un traitement automatique ne fonctionne pas.

La saisie et le traitement des demandes de restitution dans l’application.

Modification de la manière dont les restitutions sont exécutées, enregistrées et traitées, notamment aux niveaux suivants :

20 Cette description contient un aperçu des principales fonctionnalités, mais ne peut pas être considérée comme

exhaustive. Il s’agit en effet d’une description très high level qui pourrait encore subir de profondes

modifications. De plus, il n’est pas certain que le projet sera lancé en 2016.


Intégration de l’ensemble du cycle de paiement dans l’application (notamment l’envoi des paiements vers BTM).

Chargement de fichiers comptables (par exemple CODA) dans l’application pour enregistrer les restitutions et les éventuels échecs de restitutions.

Prévoir la possibilité de traiter les retours

Modifier la manière de préparer les restitutions, afin d’accroître la vitesse de réaction de l’application (la liste de toutes les restitutions préparées est chargée inutilement à chaque fois)

La génération et l’exportation d’une déclaration 201 (droits de succession) après restitution d’un avoir dormant.

Extension des rapports, statistiques et inventaires exportables qui permettra notamment d’extraire de l’application les données nécessaires au suivi du KPI et de mieux suivre les flux financiers

Modification de la procédure de révocation, notamment aux niveaux suivants :

remboursement possible via l’application

adaptation de la manière d’enregistrer les révocations par les institutions d’une part, la CDC d’autre part

La possibilité de corriger certaines données dans l’application même

La possibilité de consulter l’historique des modifications apportées par les utilisateurs

Tests de performance et garantie d’un délai de réaction raisonnable

Intégration de certaines fonctionnalités de SITRAN dans l’application Pandora, afin d’utiliser une source authentique lorsque c’est possible, en application du principe « only once »

Ajout de certains éléments concernant la réception, la gestion et la restitution des avoirs dormants (tous les types) qui s’avèrent indispensables au terme de l’analyse fonctionnelle effectuée dans le cadre du projet « Pandora extension 1 » et de l’analyse business réalisée dans le cadre du projet « Pandora extension 2 »


III. Cautionnements solidaires - Cautions (SP10A)

a. Description fonctionnelle L’application SP10A – Cautions solidaires est utilisée par le Bureau de Gestion 2 – Cautions solidaires de la Caisse des dépôts et Consignations. Elle permet

d’encoder les actes de cautions solidaires transmis par les banques ou les sociétés

de cautionnement ;

de vérifier que les actes transmis sont couverts par le dépôt en titres ou en liquide

effectués par cette société conformément aux règles fixées par la loi ;

de procéder aux prélèvements sur ces actes au cas où la caution doit jouer ;

de libérer la caution quand elle devient sans objet.

L’application n’est accessible que pour des utilisateurs internes.

b. Cycle de vie récurrent L’application SP10A a fait l’objet d’une stabilisation dans le cadre du projet TRES-0314 . Ce projet a été entamé en 2012 avec l’objectif initial d’ouvrir l’application aux intervenants externes. Lors d’un projet précédent, l’application avait été acceptée dans l’urgence, suite de graves problèmes sur d’autres projets dans la gestion du contrat avec le fournisseur externe. Il a été assez rapidement constaté que l’objectif du projet TRES-0314 ne pourrait être atteint sans une phase de stabilisation préalable de l’application existante. Suite aux restrictions budgétaires décidées en 2014, le scope du projet a finalement été réduit à cette seule phase de stabilisation de l’application existante. Cette stabilisation s’est révélée particulièrement délicate dans la mesure où aucune documentation fonctionnelle et technique ne subsiste pour l’application. Nous n’avons donc plus de « document business » décrivant ce que l’application est censée faire. Le document concernant le traitement n’est pas non plus visible pour l’utilisateur. On ne dispose pas non plus d’un document détaillant les choix techniques opérés par le fournisseur initial. Cette situation a rendu difficile l’analyse des problèmes et l’identification de leur cause. Elle a également rendues hasardeuses les interventions pour tenter de résoudre les problèmes, la solution développée pour un problème spécifique entraînant parfois une chaîne de nouveaux problèmes. A ce jour, on ne peut pas affirmer que l’objectif de stabilisation est pleinement atteint. L’application fonctionne maintenant de manière suffisante pour être utilisée par le bureau de gestion de la CDC, mais on ne peut affirmer qu’elle est « stable ». En effet, on ne peut pas exclure la réapparition de problèmes dont la cause n’a pas pu être identifiées, ni l’apparition de nouveaux problèmes qui n’ont pas pu être anticipés étant donné l’absence de documentation fonctionnelle et technique sur l’application. Si de tels problèmes se posaient, ils demanderaient une intervention en maintenance adaptative.



Les adaptations dans le cadre légal et réglementaire ou les modifications dans l’organisation de l’administration peuvent entraîner des adaptations dans l’application. Toutefois aucune adaptation de ce type n’est actuellement prévue.


IV. Faillites (SP10B)

a. Description fonctionnelle L’application SP10B Faillites est utilisée en matière de consignations judiciaires, et plus particulièrement de faillites, par les 27 agences de la Caisse des dépôts et consignations et, pour le contrôle de leur comptabilité, par le Bureau de Gestion 1-Consignations. Elle a été initiée pour encourager l’application de l’article 51 de la loi sur les faillites obligeant les curateurs de faillite à déposer à la CDC le produit de leurs ventes et recouvrements. Cette obligation est en effet très peu respectée (on estime que la moitié des fonds devant être versés ne le sont pas). Cette application doit permettre :

- aux curateurs un accès on-line à tous leurs dossiers et la possibilité d’effectuer des simulations d’intérêts.

- aux juges-commissaires d’avoir accès à tous les dossiers dont ils ont la charge. - aux présidents des tribunaux de commerce d’avoir le contrôle de tous les

dossiers faillites de leur arrondissement judiciaire. L’application est actuellement accessible aux utilisateurs « internes », agences et siège central de la CDC. Elle est en cours de stabilisation pour tout ce qui concerne la comptabilité, les paiements via BTM et les derniers problèmes introduits dans HP ALM : release 6.2 en acceptance. Une fois 6.2 en production (fin 04/ 2015), le release 7 devrait permettre l’ouverture de l’application aux utilisateurs externes (via FEDIAM) : curateurs, juges commissaires et présidents des tribunaux ce commerce. Cette application ne permet toutefois pas d’avoir accès à une source unique d’informations concernant les faillites. Bien qu’elle facilite la tâche des curateurs, des juges-commissaires et des présidents des tribunaux du commerce, elle ne donne aucune indication à la CDC sur le respect de l’obligation légale de dépôt.

b. Cycle de vie Le planning initial prévoit la clôture de l’application SP10B pour fin juillet 2015. Même en cas de retard, l’application sera clôturée et mise en production avant la fin de l’année 2015. L’expérience nous apprend qu’il n’est pas exclu que des problèmes puissent se produire et exiger une intervention dans le cadre d’un entretien adaptatif même dans une application stabilisée.

c. Indications concernant l'entretien évolutif futur Un programme privé de gestion de faillites, né de l’initiative du barreau de l’Ordre des avocats néerlandophones et du président du tribunal de commerce de Veurne, a vu le jour en Flandre orientale et occidentale. Cette application, appelée FAILMANAGER, va bientôt être étendue à tout le pays ; un projet de loi est en cours d’élaboration pour en assurer la légalité. Elle dispose de toutes les informations en matière de faillites dont la CDC a besoin au plan administratif mais n’a pas les données financières exactes dont la CDC dispose.


En effet FAILMANAGER sait exactement le nombre de faillites déclarées et quels en sont les acteurs mais ignore totalement le nombre et le montant des dépôts effectués à la CDC. L’idéal serait donc un échange de données pour nourrir mutuellement nos data bases. Pour le moment, il n’y a rien dans SP10B qui permette l’échange de données. Une question qui est actuellement posée et pour laquelle aucune réponse n’a encore été apportée est de savoir le scenario qui va être choisi :

- soit la poursuite de SP10B : on continue avec le release 7 comme prévu initialement et on clôture le projet en 2015. RealDolmen a déjà réalisé une grosse partie de ce release 7.

- soit on crée un nouveau Business Case « Interface FAILMANAGER ». Ce qui a été réalisé dans SP10B reste valable puisque ce programme a réaménagé toute la comptabilité et reste valable pour toutes les autres consignations judiciaires mais on laisse tomber le release 7 qui n’est plus nécessaire puisqu’il concerne exclusivement les faillites.

Si SP10B Faillite est une des applications de la CDC, il est prévu dans le futur de migrer toutes les applications de la CDC se trouvant sur le mainframe IBM vers des applications utilisant les technologies Java.


V. Grootboek – Grand Livre

a. Description fonctionnelle L’application GBGL est une application liée à l’émission et la gestion des titres de l’Etat détenus auprès du service des « Grands Livres ». Cette application est utilisée aussi bien en externe qu’en interne Gestionnaires externes (citoyen) :

Identification via eID ou Token

Souscription aux bons d'État sur le marché primaire pendant la période de souscription (et reconduction)

Paiement en ligne via Ogone

Consultation du portefeuille

Modification du profil (téléphone, numéro de compte) Gestion interne (Agence de la dette) :

Initialisation de la souscription (liens, données …)

Introduction des souscriptions « hors ligne » via l’identification en Sitran

Gestion des souscriptions durant la période d’émission

Consultation et réconciliation des paiements avec les souscriptions (BTM, Ogone, SAP)

Module de paiement pour les remboursements (intérêts et/ou capital)

Consultation, modification du portefeuille des clients

Gestion juridique (paiement bloqué, retour…)

Rapportage, statistique

b. Cycle de vie Le projet est terminé, le dernier comité de pilotage a eu lieu le 20 mai 2014.

c. Indications concernant l'entretien évolutif futur Plus particulièrement dans le cadre d’une modification des programmes sous-jacents (CSAM, SiTRAN, BTM, Ogone,…) ainsi que dans l’éventualité d’un nouveau produit, d’un nouveau mode de calcul.


VI. CDC Dmat

a. Description fonctionnelle L’application CDC-Dmat, en cours de développement, vise à permettre à la CDC d’assumer la mission qui lui est assignée dans le cadre de la loi portant suppression des titres au porteur. Cette application offre :

aux émetteurs de titres d’encoder les données relatives au transfert vers la CDC du

produit de la vente des titres et aux titres invendus ;

aux gestionnaire de titres de la CDC d’introduire les demandes de restitution de titres

des citoyens ;

aux agents de la CDC

o d’assurer le suivi des transferts effectués par les émetteurs de titres, en ce

compris les transferts de liquide ;

o d’assurer le suivi des demandes de restitution introduites par les citoyens, en

ce compris l’encaissement de l’amende prévue par la loi ;

o d’assurer le suivi comptable de tous les mouvements financiers.

L’utilisation est accessible aux

utilisateurs internes (via IAM) :

o les agents attachés au Bureau de gestion 7 de la Caisse des Dépôts et

Consignations.

o les fonctionnaires de l'administration fiscale

utilisateurs externes (via Fediam) :

o les émetteurs et leurs intermédiaires financiers ;

o le gestionnaire de titres de la CDC (Belfius).

Cette application utilise l’application SITRAN ainsi que BTM.

b. Cycle de vie A définir : l’application ne sera mise ne production que le 30/11/2015.

c. Indications concernant l'entretien évolutif futur Provisoirement pas d'indications.


Lot 4 - Entretien (général) À titre d’information, une énumération des applications qui peuvent être attribuées au lot entretien « ouvert ». Cette énumération n’est ni limitative, ni contraignante. Le pouvoir adjudicateur décline toute responsabilité pour la reprise ou non d’une application dans ce lot.

Application En production Service window

COMFOR Oui, partiellement depuis le 1er jan

2015 5x12

eSUCC oui 7x24x365

eSUCC – STAT oui 7x24x365

eSUCC CONSULT oui 7x24x365

RE (remboursements enregistrement) oui 7x24x365

TR Consult oui 7x24x365

RESPO oui 7x24x365

PAPERLOCO oui 5x12

Hypothèques maritimes et fluviales oui 5x12

MyRent oui 7x24x365

Extraction CadNet-Loco (ECL) oui 5x12

Locostat oui 5x12

Regeval oui 5x12

URBAIN II oui 7x24x365

REGONDES 2 Non, prévu fin 2015 7x24x365

DER oui 7x24x365

Services web d’optimisation de l’échange d’informations avec les partenaires externes/clients

Oui, partiellement 7x24x365

Adhésion à la 4e voie oui 7x24x365

WS Consultimmo oui 7x24x365

Output services AGDP Oui, partiellement 7x24x365

Hypo

Hypocomptabi

Hyporeg

Stiron Fraude ja 5x12

MyMinfin ja 7x24x365

Zoomit ja 7x24x365

Doctran ja 7x24x365

Mandats FedIAM ja 7x24x365

…


I. COMFOR

a. Description fonctionnelle COMFOR (Comptabilité-formalité) est une application Web existante qui est utilisée au sein de l’administration générale de la documentation patrimoniale, administration sécurité juridique, en remplacement de certains registres de formalités papier et de la comptabilité des bureaux d’enregistrement.

b. Cycle de vie Une première version de l’application COMFOR a été mise en service dans les bureaux d’enregistrement le 02/01/2015. De nouvelles fonctionnalités ont été ajoutées depuis et il reste de nouvelles fonctionnalités à ajouter. L’application doit être disponible 7 jours sur 7, 24 heures sur 24.


Évolutions prévues

Automatisation de certains registres et journaux existants encore sur papier. Échange de données avec diverses autres applications (DER, STIPAD, FEDCOM, RESPO, eSUCC, SITRAN, …)

Entretien prévu (évolutif, adaptatif, critique… tout entretien possible qui pourrait s’avérer nécessaire au cours des années à venir)

Conversion de l’application aux standards à ICT.


II. eSUCC

a. Description fonctionnelle eSUCC (dossier de succession électronique) est une application Web existante utilisée au sein de l’Administration générale de la Documentation patrimoniale, administration Sécurité juridique. Elle aide le receveur des droits de succession dans la gestion des dossiers de succession.

b. Cycle de vie Une première version de cette application est entrée en production le 1er décembre 2005 en remplacement de l'Etat des décès, de la Table des décès et de la Matrice 43 sur papier. Depuis, de nombreuses nouvelles fonctionnalités ont été ajoutées (reprise automatique des dossiers de décès provenant du registre national, intégration avec un module de scannage, module de calcul pour les différentes régions, intégration avec l’application RESPO, bilan fiscal, procédure de délivrance du certificat d’hérédité, service Web avec CRT, reprise de la 4e voie…). La délégation a été adaptée à la formation d’antennes de l’administration Sécurité juridique du 01/04/2014, à la formation d’antennes de l’administration Sécurité juridique du 01/01/2015 et à la reprise du service fiscal par VLABEL (service fiscal flamand) du 01/01/2015.



Application PHP avec base de données MySQL

La conversion au standard DB2 a été réalisée

Conversion aux autres standards ICT encore à réaliser


Adaptation des modules de calcul des droits de succession à la nouvelle législation (depuis le 01/01/2015, uniquement encore pour la Région Bruxelles-Capitale et la Région wallonne) Remarquez que les récentes modifications de loi ont déjà été confiées aux services internes PHP ICT du service d’encadrement ICT Adaptation aux modifications apportées dans le projet « 4e voie » (conversion du schéma version 2.5 à la version 3 ; ajout de nouveaux partenaires…) Modification dans la procédure de délivrance du certificat d’hérédité Modifications nécessaires pour la mise au point de tableaux de bord


Modifications nécessaires dans l’éventualité où une autre région (Bruxelles/Wallonie) reprendrait également le service fiscal Éventuelle transmission des données du calcul validé à l’application FEDCOM (dans le cadre de la législation comptable – droits établis). Adaptation à d’autres applications (COMFOR, STIPAD, …)


III. eSUCC – STAT

a. Description fonctionnelle eSUCC - STAT est une application Web utilisée au sein de l’Administration générale de la Documentation patrimoniale, administration Sécurité juridique, par ceux qui ont besoin de consulter des statistiques calculées et validées de déclarations de succession. Sur la base de calculs automatiques validés, les statistiques comptables des droits de succession sont créées de manière entièrement automatique. La saisie des résultats des calculs manuels et des cases à remplir pour les statistiques comptables correspondantes permet également d’ajouter ces données aux statistiques automatisées. Le module eSUCC – STAT a été développé pour la consultation de ces statistiques (au niveau des déclarations, des bureaux, des arrondissements, des directions ou des régions) par le service Expertise et support opérationnel de l’Administration générale de la Documentation patrimoniale

b. Cycle de vie Le service précité peut consulter ce module statistique depuis le 28 octobre 2008.







Adaptations en cas de modification de la législation Modifications nécessaires pour la mise au point de tableaux de bord


IV. eSUCC CONSULT

a. Description fonctionnelle Depuis sa mise en production le 1er décembre 2005, l’application eSUCC a été constamment complétée de nouveaux modules et fonctionnalités. L’application contient de nombreuses informations qui peuvent également intéresser d’autres administrations. Via l’application eSUCC CONSULT, une compétence de consultation limitée est accordée aux services de l’Administration générale de la Perception et du Recouvrement (bureaux des contributions directes et TVA)21, à l’Administration de la Trésorerie et à quelques autres services. Les données consultables concernent principalement :

quelques données d’identité concernant le défunt, les demandes et certificats d’hérédité (avec possibilité de visualisation de ces

documents en format PDF),

les éventuels documents scannés pour le dossier électronique de succession (seul l’acte notarié authentique scanné ou les déclarations d’acceptation, de refus, et d’acceptation sous bénéfice d’inventaire) sont entièrement visualisables pour les autres services,

quelques données concernant les déclarations de succession déposées Remarque : la déclaration scannée est également visualisable pour le centre de perception DGPR depuis le 1er juillet 2014

les personnes reconnues par le bureau comme ayants droit à la succession

b. Cycle de vie L’application a été mise en production le 31 octobre 2008. En raison d’une surcharge depuis la migration vers le nouveau serveur ICT en 2009, le pouvoir de consultation des différents services a été arrêté et une réintroduction phasée a été mise en place.




La conversion au standard DB2 a été réalisée.


21) Ces services ont besoin de connaître les héritiers d’un ayant droit à une restitution décédé pour leurs dossiers

de restitution. Ils peuvent alors retrouver ces informations dans eSUCC Consult, parmi les certificats

d’hérédité et les actes d’hérédité authentiques scannés.



Adaptation en cas d’ajout de services qui peuvent consulter avec des besoins spécifiques


V. RE (remboursements enregistrement)

a. Description fonctionnelle RE (Remboursements Enregistrement) est une application Web utilisée au sein de l’Administration générale de la Documentation patrimoniale, administration Sécurité juridique, aux bureaux d’enregistrement qui traitent des dossiers de remboursement de droits d’enregistrement. L’administration gère l’ensemble de la procédure de la demande au remboursement : introduction, traitement par le bureau de l’enregistrement compétent, traitement – approbation et ordonnancement par la Direction régionale, versement effectif par l’Administration générale de la Trésorerie.

b. Cycle de vie L’application est en production depuis le 1er janvier 2000. L’application a été adaptée à la formation d’antennes Sécurité juridique du 01/04/2014, à la formation d’antennes Sécurité juridique du 01/01/2015 et à la reprise par VLABEL (service fiscal flamand) du 01/01/2015. Transfert de données vers le bilan fiscal.







Adaptations en cas de modification de la législation Modifications nécessaires pour la mise au point de tableaux de bord Modifications nécessaires dans l’éventualité où une autre région (Bruxelles/Wallonie) reprendrait également le service fiscal Éventuel transfert de données vers l’application FEDCOM Adaptation à d’autres applications (COMFOR, STIPAD, …)


VI. RE CONSULT

a. Description fonctionnelle Module de consultation limitée RE (remboursements enregistrement) pour un nombre limité de services (services centraux, trésorerie).

b. Cycle de vie L’application a été mise en production le 1er janvier 2009.







Adaptation en cas d’ajout de services qui peuvent consulter avec des besoins spécifiques


VII. RESPO

a. Description fonctionnelle RESPO est une application Web utilisée au sein de l’Administration générale de la Documentation patrimoniale, administration Sécurité juridique, qui soutient la responsabilité comptable du receveur enregistrement/succession et de l’inspecteur principal-chef de service. Il regroupe les inscriptions suivantes : déclarations de succession et déclarations d’associations sans but lucratif (ASBL) dans le « registre électronique 47 » et les inscriptions des créances de droits d’enregistrement, de succession et autres dans la « matrice électronique 28 ». Les versions papier du « registre 47 » et de la « matrice 28 » ont été supprimées le 1er janvier 2005.

b. Cycle de vie Une première version de cette application est entrée en production le 1er novembre 2004 pour des bureaux tests et le 1er janvier 2005 pour tous les bureaux d’enregistrement. L’application a été adaptée à la formation d’antennes Sécurité juridique du 01/04/2014, à la formation d’antennes Sécurité juridique du 01/01/2015 et à la reprise par VLABEL (service fiscal flamand) du 01/01/2015. Transfert de données vers le bilan fiscal.



Application PHP avec base de données MySQL.




Adaptations en cas de modification de la législation Modifications nécessaires pour la mise au point de tableaux de bord Modifications nécessaires dans l’éventualité où une autre région (Bruxelles/Wallonie) reprendrait également le service fiscal


Éventuel transfert de données vers l’application FEDCOM Adaptation à d’autres applications (COMFOR, STIPAD, …)


VIII. Paperloco

a. Description fonctionnelle Cette application Web met les comptes mobiles papier scannés à la disposition des bureaux d’enregistrement de l’administration Sécurité juridique. À l’époque, ces comptes mobiles papier reprenaient plusieurs renseignements importants pour l’Administration générale de la Documentation patrimoniale.

renseignements immobiliers : mutations concernant les biens immobiliers au nom

d’un titulaire

renseignements mobiliers (repris par l’application TP380 et plus tard par l’application

STIPAD), y compris les renseignements liés aux testaments, contrats de mariage…

b. Cycle de vie L’application a été mise en production il y a plusieurs années déjà.



Vu la disparition des développeurs ICT, il n’y a que peu de possibilités.


Il reste encore des problèmes techniques à résoudre.


IX. Hypothèques maritimes et fluviales

d. Description fonctionnelle Application utilisée à la conservation des hypothèques maritimes et fluviales à Anvers (seul bureau en Belgique) pour la gestion des hypothèques maritimes et fluviales ainsi que pour la délivrance des certificats hypothécaires. Par analogie aux hypothèques terrestres, le bureau assure la formalité hypothécaire concernant les bateaux maritimes et fluviaux. Il donne des renseignements (certificats) concernant ces mêmes bateaux maritimes et fluviaux ainsi qu’en matière d’affrètement coque nue.

e. Cycle de vie L’application a été mise en production.

f. Indications concernant l'entretien évolutif futur Entretien évolutif, adaptatif et critique.


X. MyRent

a. Description fonctionnelle L’application vise la reprise des contrats de bail enregistrés, et ce, à la fois pour les contrats de bail d’immeubles « affectés exclusivement à l’habitation » et les contrats de bail des immeubles « non affectés exclusivement à l’habitation » (application interne au bureau d’enregistrement – intra). La possibilité est également prévue que le citoyen et l’agence immobilière puissent des contrats de bail pour enregistrement sous forme électronique (applications Internet – extra).

b. Cycle de vie L’application est en production depuis juin 2007.

c. Indications concernant l'entretien évolutif futur L’application sera encore optimisée.


XI. Extraction Cadnet-Loco (ECL)

a. Description fonctionnelle Page Web par laquelle les données relatives aux biens immobiliers qui ont été repris dans les actes/déclarations de succession enregistrées sont importées dans l’application Locostat. En raison de la mise en production de l’application STIPAD et de la clôture de l’application CadNet-Loco (système source d’origine), cette extraction ne peut pour l’instant pas être fournie et doit être remplacée par un service Web qui contient les mêmes modalités de recherche.

b. Cycle de vie Aucun

c. Indications concernant l'entretien évolutif futur Passage au service ConsultImmo Adaptation à la suite de la nouvelle extraction à développer depuis la mise en production de STIPAD.


XII. Locostat

a. Description fonctionnelle C’est une application qui contient plusieurs modalités :

traitement des biens provenant des actes enregistrés

application du modèle mathématique à ces biens création automatisée de la correspondance insuffisance d’estimation et expertise

préalable

suivi des insuffisances d’estimation

tenue des points de comparaison


c. Indications concernant l'entretien évolutif futur Evolutif, adaptatif et critique.


XIII. Regeval

a. Description fonctionnelle Application qui assure l’échange de données dans le cadre des demandes d’estimation par le comité d’acquisition fédéral, l’administration Sécurité juridique et d’autres administrations.

b. Cycle de vie Dépend d’ECL et de l’application Locostat



XIV. URBAIN

a. Description fonctionnelle Dans un premier temps, l’application Web URBAIN a été développée pour l’échange électronique d’informations entre les communes et l’ADDP. Avec cette application, il est possible :

de télécharger les informations concernant les revenus cadastraux et les superficies des parcelles ;

de télécharger les matrices cadastrales et les plans de parcelles cadastrales ;

de communiquer sous forme électronique les permis d’urbanisme délivrés à l’AGPD Ces permis d’urbanisme sont importants pour pouvoir adapter et mettre à jour notre documentation patrimoniale. Entre-temps, on travaille également à l’échange d’informations entre l’AGPD et la Région flamande dans le cadre de la digitale bouwaanvraag (DBA).




XV. REGONDES 2

a. Description fonctionnelle Ce projet porte sur le développement d’une nouvelle application pour la gestion et le traitement des désaccords ou contestations en matière revenu cadastral, de précompte mobilier et le contentieux s’y rapportant. Il s’agit de créer une application web pour l’administration Mesures et Evaluations ainsi que l’administration Sécurité juridique de l’AGDP.




XVI. DER

a. Description fonctionnelle L’application DER permet au notaire d’envoyer son acte par voie numérique et, par la même voie, de recevoir de l’administration les certificats qui confirment l’exécution des formalités demandées par le notaire. L’application DER est la porte d’accès du notariat au SPF pour l’envoi des actes à enregistrer et/ou le dépôt aux conservateurs d’hypothèques. Les principaux systèmes avec lesquels DER est en contact sont

- STIPAD (application interne) ; - HYPO (application interne) ; - HYPOCOMPTABI (application interne) ; - ESB (interne) ; - COMFOR (application interne) ; - eRegistration (application externe).

En outre, l’application DER fournit également des services importants pour les régions. Les services dont il est actuellement question :

envoi des actes enregistrés pour le traitement du volet fiscal (pour l’instant

uniquement vers la Flandre). Il s’agit à la fois des actes introduits sous forme

électronique par le notariat et des actes papier (ces derniers depuis fin 2015) ;

traitement des actes provenant des comités d’acquisition (comités d’acquisition

fédéral et régionalisés)

b. Cycle de vie DER a été mis en production avec succès le 1er avril 2014. Depuis, plus d’un demi-million de formalités d’actes ont déjà été introduites de forme électronique. Tous les bureaux de notaires renvoient désormais leurs actes sous forme électronique. Du côté du SPF Finances aussi, toutes les antennes de l’administration Sécurité juridique (services impliqués) travaillent depuis quelque temps avec l’application. La récente mise en service de l’application STIPAD a contribué à numériser le processus de travail de l’administration Sécurité juridique et continuera à le faire.



- entretien adaptatif pour l’intégration des certificats patrimoniaux - optimisation de la base de données


- entretien nécessaire de l’application


XVII. Service Web d’optimisation des échanges d’informations avec les partenaires externes

a. Description fonctionnelle Au sein de l’Administration générale de la Documentation patrimoniale, on travaille actuellement à des services Web destinés à mettre des informations contenues dans la base de données PATRIS de l’application STIPAD à la disposition de nos partenaires et clients externes.

- Service Web Consultimmo: remplace « l’ancien » SP04 qui échangeait les

informations cadastrales de l’application CadNet

- service Web prix de vente (en développement)

b. Cycle de vie Le service Web Consultimmo a été développé en interne. Le service Web Prix de vente sera disponible dans le courant de l’année 2015.



- Extension au schéma de mutation

- Connexion avec PDF mutation du schéma cadastral

- Développement du service Web « get transaction » sur DB PATRIS

- Couvrir l’accès des « petits utilisateurs » au service Web ConsultImmo au moyen

d’un système d’accès – authentification et autorisation – extérieur aux intégrateurs

classiques (la communication s’effectue pour l’instant par fax, papier…)


Entretien nécessaire de ces services Web + ajout de nouvelles méthodes si nécessaire


XVIII. Adhésion à la 4e voie

a. Description fonctionnelle Lors de transactions immobilières, de ventes de biens mobiliers ou de saisies-arrêts, les notaires, huissiers de justice, comités d’acquisition… sont légalement obligés d’informer les pouvoirs publics (ex. SPF Sécurité sociale et SPF Finances). De cette manière, l’administration a la possibilité de récupérer d’éventuelles dettes. Le projet « 4e voie » numérise les transferts d’avis, d’accusés de réception et de notifications liés à ces transactions entre les parties impliquées.

Cet échange électronique de données s’effectue via le Federal Service Bus développé par Fedict. FSB est une plate-forme sur laquelle plusieurs services Web sont disponibles via une interface claire et uniforme, qui permet d’accéder aux informations des bases de données de l’administration.

À la suite des demandes d’affilier de nouveaux partenaires et conformément la loi-programme portant sur la créance en cas de succession, Fedict a étudié l’architecture existante en 2012 pour vérifier si elle permettait d’affilier ses nouveaux partenaires, puis a adapté cette architecture. La nouvelle architecture a entre-temps été mise en place.

L’éventuelle l’adhésion de nouveaux partenaires au projet « 4e voie » ou l’adaptation de l’architecture de la 4e voie pourra avoir un impact sur les services Web de l’application « eFonctionnaire » et de l’application « eSUCC ».

b. Cycle de vie L’échange de données via la 4e voie doit continuer à exister en continu (obligations légales).

c. Indications concernant l'entretien évolutif futur Évolutions prévues Adaptation du schéma XSD avec ajout de partenaires, réception de notifications électroniques d’autres partenaires que les partenaires sociaux (les notifications électroniques des partenaires sociaux sont déjà reçues). L’adaptation du schéma XSD avec ajout de partenaires aura également un impact sur l’application des Comités d’acquisition et sur l’application des Receveurs succession (eSUCC). Pour ce qui concerne eSUCC :

adaptation des fichiers CLOB (Character Large Object) ou utilisation de services Web développés

ajout de partenaires dans l’application pour la consultation des accusés de réception fonctionnels

ajout de partenaires pour la consultation de notifications électroniques ajout de partenaires pour le chargement de notifications non envoyées sous forme

électronique fusion des nouvelles notifications électroniques/notifications à charger avec certificat

d’hérédité


XIX. WS Consultimmo

a. Description fonctionnelle Via le service Web ConsultImmo, l’information patrimoniale est transmise de manière interactive aux clients internes et externes de l’Administration générale de la Documentation patrimoniale. Le service Web ConsultImmo contient actuellement trois groupes principaux :

1. on properties 2. on transactions 3. Parcel Navigator

On properties: Recherche sur base de :

identification personnelle (numéro de registre national, numéro d’entreprise ou numéro BIS)

nom + prénom + code postal

commune + rue + numéro section cadastrale + numéro de parcelle

On transactions: Recherche sur base de :

Service Web « Prix de vente »

Service Web « Transactions AS IS »

Service Web « Transactions TO BE » Le service Web « Parcel Navigator » donne un aperçu historique de la séparation, de la réunion et de la naissance de nouvelles parcelles.

b. Cycle de vie Ilimité

c. Indications concernant l'entretien évolutif futur Évolutions prévues Poursuivre l’évolution vers une plate-forme SOA à part entière Entretien prévu Les services déjà développés devront être adaptés ou de nouveaux services Web devront être créés si les clients internes et externes de l’Administration générale de la Documentation patrimoniale souhaitent obtenir des données patrimoniales supplémentaires.


XX. Output services AGDP

a. Description fonctionnelle Une des principales missions de l’Administration générale de la Documentation patrimoniale est la délivrance d’informations patrimoniales, notamment aux citoyens, aux professionnels, à d’autres organismes publics et à d’autres Administrations générales du SPF Finances. Dans ce cadre, le projet de « Output Services AGDP (OSA) » a pour but de développer de 5 report layers (= copies de la base de données de production PATRIS de l’application STIPAD pour la consultation des données patrimoniales) afin que la délivrance d’informations puisse se dérouler de manière centralisée et structurée. En outre, ce projet vise également à moderniser la consultation des données et des rapports par la mise en place de webservices et d'outils de rapportage.

b. Cycle de vie Illimité



Intégration des données en provenance d’autres bases de données (CadNet, LOCO, FUN, HYPO, STIPAD, DER, URBAIN, et.) selon les demandes de certains rapports ou services.

Prévoir entretien

D’éventuelles modifications apportées au contenu de bases de données auront des implications sur les rapports et les services et ceux-ci devront donc être adaptés.


XXI. Hypo


b. Cycle de vie



XXII. Hypocomptabi


b. Cycle de vie



XXIII. Hyporeg


b. Cycle de vie



XXIV. Stiron Fraude

a. Description fonctionnelle L’application STIR_Fraude est un des modules qui a été développé dans le cadre du Projet STIRON, lot 3. STIR_Fraude assure le suivi du processus de travail et des activités liées aux enquêtes fiscales de l'Administration générale de l’Inspection spéciale des impôts (AGISI), depuis l’enregistrement des signaux de fraude reçus ou détectés, en passant par le traitement des pré-enquêtes, des affaires et des dossiers, jusqu’aux résultats des taxations effectuées dans les dossiers fiscaux traités. Le cahier des charges de STIR_Fraude a été rédigé en 2008 sur la base de l’analyse réalisée préalablement dans le cadre de Coperfin. Le release 2.6.5 de l’application est en production dans toutes les directions régionales de l’ISI. Tous les agents de l’AGISI (+/- 600 agents) utilisent actuellement STIR_Fraude. L’application STIR Fraude a été conçue en fonction de la structure de l’ISI à l’issue du processus de basculement (K3) finalisé fin 2014. Depuis 2014, STIR_Fraude a également remplacé définitivement les anciennes applications informatiques LCF-base (ancien outil de gestion des services extérieurs) et SB-STAT (outil de statistique et de suivi des résultats). Le cycle de vie de l’application correspond aux années budgétaires dès lors que l’application enregistre les résultats des services de l’ISI en matière de taxation. Stiron Fraude se compose d’un DB2-backend combiné à un middleware basé sur JAVA qui génère des pages html de la deuxième génération. Par rapport aux autres applications du SPF Finances, la DB2 stocke une quantité plutôt limitée de données. Stiron Fraude fait partie d’une constellation d’applications au sein du SPF Finances. L’autorisation et la sécurisation de l’application sont traitées via l’application d’Identity Management (ex. policy manager). Celle-ci fournit également le détail des profils d’utilisateurs via LDAP. Les documents chargés via Stiron Fraude sont archivés dans Filenet et restent consultables via Stiron Fraude. Les activités créées dans Stiron Fraude sont signalées au Task-Manager. La base de données sert également les datawarehouses pour le reporting et le datamining. On tente également de mettre en valeur cette relation au niveau du front-end en reliant directement le plus grand nombre d’applications possible sur la base des connecteurs pertinents.

b. Cycle de vie

Adaptation de l’application de gestion aux nouvelles technologies validées o Backend o Middelware: ex. extension d’API o Front-end: ex. une application exclusivement dédiée à la consultation,

maximisation de la compatibilité navigateurs et appareil, Web 3.0… Rectification des besoins de sécurité et cohérence des données concernant le

middleware

Résolution des défauts ou incohérences

Amélioration de l’expérience utilisateur o Approche intuitive et cohérente de l’interface


o Optimisation du rapportage pour la gestion quotidienne et le suivi de la performance

o Ajout de sous-applications moins consommatrices de ressources

Synchronisation de l’application de gestion avec les processus opérationnels

c. Indications concernant l'entretien évolutif futur Une des adaptations évolutives prévues est l’extension de l’application de gestion aux services de support, notamment les cellules informatiques, les cellules litiges, les cellules douanes, les cellules recouvrement, etc. L’objectif est d’obtenir finalement un système de gestion qui puise dans une source de données (si possible distribuée) pour créer un aperçu complet et cohérent, mais détaillé pour les différents profils de fonction au sein de l’AG-ISI.


XXV. MyMinfin


MyMinFin est aujourd’hui utilisée par plus d’un million de citoyens. De nombreux mandataires et entreprises ont accès à leurs données ou services via cette application. Les fonctionnaires du SPF Finances assurent le support ou accès aux données de manière centralisée. MyMinFin est devenu la carte de visite du SPF Finances.

La plate-forme MyMinfin se compose de :

MyMinfin citoyen : accès du citoyen à son dossier fiscal MyMinfin pro se compose de :

o MyMinfin pro pour les professions du chiffre (mandataires) o MyMinfin entreprises : accès des entreprises à leur dossier fiscal – actuellement,

seules les données de signalétique et de TVA sont affichées. o Un accès pour les banques : JMonnet, FATCA

o Un accès pour les géomètres, o Un accès pour les architectes.

MyMinfin ContactCenter: accès interne pour les fonctionnaires du SPF Finances qui font partie du Contact Center

MyMinfin Intranet: accès sécurisé pour les fonctionnaires du SPF Finances au moyen d’une matrice et d’une plate-forme IAM qui fournit des conseils

Les citoyens, les entreprises et les fonctionnaires du SPF Finances ont accès à une série d’e-services via MyMinfin. MyMinfin permet également d’actualiser des données (téléphone, GSM, e-mail...) et bientôt d’introduire une plainte en ligne (Litiges). MyMinfin procure également un accès centralisé aux documents et offre la possibilité de consulter des données connues du SPF Finances (biens immobiliers, bilan fiscal…)

url: http://www.myminfin.be

b. Cycle de vie Vu l'aspect de coordination et de synthèse de Myminfin, ce portail est constamment en évolution: ajout de nouveaux services et documents, adaptations à des services et documents existants,... MyMinfin évolue donc quasiment en permanence et plusieurs releases par an doivent être prévues.

c. Indications concernant l'entretien évolutif futur Evolution continue avec plusieurs releases par an.


XXVI. Zoomit

a. Description fonctionnelle La fonctionnalité zoomit qui est offerte à l'impôt des personnes physiques permet aux contribuables de consulter, via leur application e-banking, leur avertissement-extrait de rôle et de payer les sommes dues. Ce mode de travail est économique, plus efficace et permet d'éviter les fautes administratives lors du paiement. A ce jour, le SPF Finances offre la fonctionnalité Zoomit uniquement pour l'impôt des personnes physiques. Zoomit est un service électronique traité par Isabel SA, une entreprise spécialisée dans le traitement électronique des transactions financières. Zoomit est sponsorisé au sein du SPF Finances par l'Administration générale de la perception et du recouvrement. La solution zoomit à l'impôt des personnes physiques se compose:

1. d'un module par lequel le contribuable peut indiquer s'il souhaite utiliser zoomit (via Tax-on-web ou via MyMinfin);

2. d'un module qui transmet les références de paiement des contribuables à Isabel; 3. d'un module qui met à disposition des contribuables les avertissements-extraits de

rôle, intégrés dans l'infrastructure Isabel. 4. d'un module qui envoie un e-mail au contribuable si une nouvelle référence de

paiement a bien été délivrée dans Isabel; 5. du software Isabel, utilisé sous licence.

b. Cycle de vie Les modules 1 à 4. sont assez stables et n'exigent en principe pas d'entretien ou d'évolutions annuels. Le software Isable 5 relève d'un contrat avec Isabel. De software est mise à jour en fonction des nouvelles releases disponibles, des aspects de sécurité, de la stabilité et des conseils d'Isabel.

c. Indications concernant l'entretien évolutif futur La solution software zoomit fonctionne à ce jour uniquement à l'impôt des personnes physiques. A terme, le but est de développer un système générique qui offre également aux autres clients (précompte immobilier, TVA, etc.) un accès au service zoomit. A ce propos, l'idée d'intégrer zoomit dans DOCTRAN fait son chemin.


XXVII. Doctran

a. Description fonctionnelle Doctran est une application de consultation générique qui permet à l'utilisateur de visualiser tous les documents archivés électroniquement dans Filene et de lui donner un aperçu du dossier unique. La requête commence par un numéro national (NN) pour les personnes physiques et par le numéro de la Banque Carrefour des Entreprises (BCE) pour les personnes morales. Pour le moment, l'application Doctran est limitée à la consultation des dossiers permanents digitalisés pour l'impôt des personnes physiques (indépendants), pour l'impôt des sociétés et pour la taxe sur la valeur ajoutée. Le Webservice de Doctran Doctran offre la possibilité de consulter un grand nombre d’ObjectStores FileNet du SPF Finances. Il peut être intéressant pour d’autres applications de demander à Doctran d’effectuer une recherche pour un mot-clé (NRN, BCE ou autre) et un type donné de documents Ces demandes peuvent être effectuées via le WebService. Les interactions entre le client et le WebService de Doctran peuvent être représentées à l’aide du schéma suivant :

Doctran récupère l’identité de l’utilisateur qui fait la demande grâce à WS-SSO de CCFF (utilisé par ESB). Grâce à cette information, Doctran peut:

calculer la compétence géographique ;

demander un accès à IAM ;

exécuter des auditlogs chez IAM.


Le Widget de Doctran Les applications du SPF Finances peuvent interagir avec Doctran au moyen d’un widget. Le widget est intégré dans Doctran depuis la version 1.2.1. L’idée générale derrière le widget de Doctran est la possibilité de reprendre le tableau des résultats de Doctran dans une application du SPF Finances sans devoir rien développer. Le widget est proposé sous la forme d’un iFrame qui peut être placé sur n’importe quelle application CCFF.

d. Cycle de vie En raison de la diversité des documents et de leur mode de stockage, Doctran doit évoluer.

e. Indications concernant l'entretien évolutif futur Doctran est dépendant de la gestion documentaire électronique. Chaque application crée ses propres documents et les enregistre suivant ses règles. Les nouvelles évolutions sont nécessaires pour créer une seule méthode d’accès pour la gestion documentaire et l’uniformisation des métadonnées.


XXVIII. Mandats FedIAM

a. Description fonctionnelle Le Self-Service Mandats (SSM) du SPF Finances a été développé dans le cadre des mandats FedIAM. L'e-service SSM permet la gestion des mandats entre le mandant et le mandataire. Une fois que le mandat est conclu, il est à la disposition des applications concernées. Les principales fonctions de SSM sont :

création d’une proposition de mandat, par le mandataire ou le mandant

envoi d’un mail pour validation du mandat à l’autre partie (mandataire ou mandant)

approbation (ou refus) du mandat par le mandataire ou mandant

pas d’implication d’une partie tierce (aspect self-service)

mise à disposition d’un document PDF avec le texte du mandat et la date de l’acceptation par les deux parties impliquées (paperless e-mandate)

transmission des mandats (en vrac) d’un mandataire à un autre mandataire, par exemple en cas de cessation de l’entreprise du mandataire

arrêt d’un mandat par le mandataire ou mandant

aperçu de l’historique d’un mandat

en fonction du type de mandat, le mandant peut être une personne physique ou une entreprise

en fonction du type de mandat, il peut être donné à une personne physique ou à une entreprise

les caractéristiques du mandant et du mandataire sont extraites du registre national ou de la Banque-Carrefour des Entreprises (BCE)

dans le mandat pour e-gov services du SPF Finances, on utilise Sitran

des sources authentiques externes peuvent être consultées pour des mandats spécifiques (via le Federal Service Bus (FSB))

SSM a été initialement développée pour les mandats propres au SPF Finances. En 2014, SSM a été ouverte aux mandats non-SPFFin dans le cadre du CSAM. Le Common Secure Access Management (CSAM) est une initiative de plusieurs SPF visant la création d’une plate-forme commune pour la gestion des accès de tous les organismes publics aux services e-government. SSM en constitue le troisième pilier après le Federal Authentication Service (FAS – FedICT) et la Gestion des Gestionnaires d’accès (GGA – Sécurité sociale). Mandats existants

Tax-on-Web IPP (SPF Finances)

Tax-on-Web INR/PP (SPF Finances)

TVA (Intervat – SPF Finances)

BizTax (SPF Finances)

MyMinfin (SPF Finances)

Finprof (en préparation – SPF Finances)

mandats e-Health (CSAM)

guichet numérique à Anvers (en préparation – CSAM) L’architecture la plus générale est actuellement représentée dans la structure d’e-Health:


Pour les mandats internes au SPFFin, seule la partie au sein du SPFFin et les liens externes à FAS et GGA/RMA (gestion des rôles) restent, tous deux via FedIAM.

b. Cycle de vie L’ajout de nouveaux mandats en concertation avec le business concerné. Ce peut être à la fois au sein du SPF Finances et pour des partenaires externes (dans le cadre de CSAM). L’ajout s’effectue à la demande de l’entité concernée (à n’importe quel moment).

c. Indications concernant l'entretien évolutif futur Aucune évolution spécifique n’est prévue. Suivre les évolutions des services impliqués et des architecture building blocks (ABB) utilisés. Entretien évolutif, adaptatif et critique.

Download - Cahier spécial des charges - SPF Finances · 2016-07-12 · Cahier spécial des charges S&L/DA/2016/060 1/223 Cahier spécial des charges : Appel d'offres ouvert relatif à l'entretien

Top Related