Download pdf - Cahier spécial des charges - SPF Finances · Fiscalité (SPF Finances). Publication au niveau européen Cahier spécial des charges n° S&L/AO/386/2014 Ouverture des offres : 1 octobre

Cahier des charges S&L/AO/386/2014 1/217

Cahier spécial des charges : Appel d’offres ouvert pour la maintenance des applications de l’Administration Générale de la Fiscalité (SPF Finances).

Publication au niveau européen

Cahier spécial des charges n° S&L/AO/386/2014 Ouverture des offres : 1 octobre 2015 à 14h30

Errata page 7 et 8


Contenu

A. DEROGATIONS GENERALES ............................. ........................................................... 5

B. DISPOSITIONS GENERALES ......................... ................................................................ 5 1. OBJET ET NATURE DU MARCHE.................................................................................................................. 5 2. DUREE DU CONTRAT. ................................................................................................................................... 6 3. POUVOIR ADJUDICATEUR – INFORMATIONS COMPLEMENTAIRES. ....................................................... 7 4. DOCUMENTS REGISSANT LE MARCHE ...................................................................................................... 7

4.1. Législation .............................................................................................................................. 7 4.2. Documents du marché ........................................................................................................... 7

5. INCOMPATIBILITES - CONFLITS D’INTERETS. ............................................................................................ 7 5.1. INCOMPATIBILITES ..................................................................................................................................... 7 5.2. CONFLITS D’INTERETS .............................................................................................................................. 8 6. SESSION D’INFORMATION. ........................................................................................................................... 8

A. ATTRIBUTION ....................................... .......................................................................... 9 1. DROIT ET MODALITES D’INTRODUCTION ET OUVERTURE DES OFFRES .............................................. 9

1.1. Droit et mode d’introduction des offres .................................................................................. 9 1.1.1. Offres introduites par des moyens électroniques........................................................... 9 1.1.2. Documents qui ne peuvent être introduits par des moyens électroniques .................. 10 1.1.3. Modification ou retrait d’une offre déjà introduite ......................................................... 11 1.2. Ouverture des offres ............................................................................................................ 11

2. OFFRES ........................................................................................................................................................ 12 2.1. Données à mentionner dans l’offre ...................................................................................... 12 2.2. Structure de l’offre ................................................................................................................ 12 2.3. Durée de validité de l’offre ................................................................................................... 13 2.4. Documents et attestations à joindre à l’offre ........................................................................ 13

3.. PRIX.............................................................................................................................................................. 13 4.DROIT D’ACCES – SELECTION QUALITATIVE – REGULARITE DES OFFRES – CRITERES

D’ATTRIBUTION ........................................................................................................................................ 14 4.1. Droit d’accès et sélection qualitative ............................................................................... 14 4.1.1. Droit d’accès................................................................................................................. 14 4.1.2. Sélection qualitative ..................................................................................................... 17 4.2. Régularité des offres ........................................................................................................ 20 4.3. Critères qui seront utilisés lors de l’évaluation des offres .................................................... 20 4.3.1. Liste des critères d’attribution ........................................................................................... 20

B. EXECUTION ....................................................................................................................38 1. FONCTIONNAIRE DIRIGEANT. .................................................................................................................... 38 2. REVISION DE PRIX. ..................................................................................................................................... 38 3. RESPONSABILITE DU PRESTATAIRE DE SERVICES. .............................................................................. 39 4. RECEPTION DES SERVICES PRESTES. .................................................................................................... 39

4.1. La livraison et l’installation ................................................................................................... 39 4.2. Spécifications techniques ..................................................................................................... 39 4.3. Suivi de la bonne exécution des livraisons et des services ................................................. 39 4.4. Contrôle et encadrement du marché.................................................................................... 40

4.5. ACCEPTATIONS PROVISOIRES .............................................................................................................. 41 4.6. Garantie ................................................................................................................................ 41 4.7. Réception définitive .............................................................................................................. 42 4.8. Frais de réception................................................................................................................. 42

5. CAUTIONNEMENT ........................................................................................................................................ 42 5.1. Constitution du cautionnement ............................................................................................. 42 5.2. Libération du cautionnement ................................................................................................ 43 6. Modalités d’exécution .............................................................................................................. 44 6.1. Clause d’exécution ............................................................................................................... 44 6.2. Clause d’évolution technologique ........................................................................................ 44 6.3. Lieu d’exécution du marché et particularités ........................................................................ 44 6.4. Personnel de l’adjudicataire ................................................................................................. 45 6.5. Sous-traitants ....................................................................................................................... 47

7. FACTURATION ET PAIEMENT. .................................................................................................................... 51 8. LITIGES. ........................................................................................................................................................ 52


9. AMENDES ET PENALITES. .......................................................................................................................... 53 9.1. Pénalités ............................................................................................................................... 53 9.2. Amendes .............................................................................................................................. 53 9.3. Imputation des amendes et pénalités .................................................................................. 53

C .PRESCRIPTIONS TECHNIQUES ...................................................................................54 1. PRINCIPES GENERAUX DU MARCHE. .................................................................................................... 54

1.1. Introduction ...................................................................................................................... 54 1.2. Objectifs généraux du marché ......................................................................................... 55

1.2.1. MODE DE COLLABORATION ENTRE LOTS DE SUPPORT/DEVELOPPEMENT ET LOT DE TESTING .................................................................................................................................................... 55

1.2.2. INTEGRATION ENTRE LES APPLICATIFS FONCTIONNELLEMENT LIES .................................... 55 1.2.3. AMELIORATION DE LA QUALITE DES APPLICATIONS (DISPONIBILITE, PERFORMANCE,

OPTIMISATION, DOCUMENTATION, QUALITE DU CODE, CONSOMMATION DE RESSOURCES,…). 55 1.2.4. SOUPLESSE ET REACTIVITE ......................................................................................................... 56 1.2.5. IMPLICATION DU PERSONNEL INTERNE ET RENFORCEMENT DE LA MAITRISE .................... 56 1.2.6. MAITRISE DES COUTS .................................................................................................................... 56

1.3. Vision et encadrement ..................................................................................................... 56 1.4. Economie générale du marché ........................................................................................ 57

1.4.1. SEPARATION DES ASPECTS DEVELOPPEMENT/SUPPORT ET TESTING ................................. 57 1.4.2. COMPOSITION DES LOTS ............................................................................................................... 59 1.4.3. INCOMPATIBILITE ENTRE LOTS .................................................................................................... 60 1.4.4. COLLABORATION ENTRE LES EQUIPES DE LA COMPOSANTE « DEVELOPPEMENT ET ........ 61 1.4.5. PRISE D’EFFET DE LA MAINTENANCE .......................................................................................... 61 1.4.6. DESCRIPTION DES APPLICATIONS ............................................................................................... 63 1.4.7. MODALITES D’EXECUTION ............................................................................................................. 63 1.4.8. TRANSFERT DE CONNAISSANCE .................................................................................................. 64 1.4.9. CO-SOURCING ................................................................................................................................. 66 1.4.10. PERSONNEL MOBILISE PAR L’ADJUDICATAIRE .......................................................................... 67 2. COMPOSANTE « DEVELOPPEMENT ET SUPPORT » (LOTS 1 A 4) ...................................................... 68

2.1. Missions ........................................................................................................................... 68 2.2. Mode d’exécution au sein d’un lot ................................................................................... 69

2.2.1. ÉVALUATION DES SERVICES EXECUTES .................................................................................... 69 2.2.2. SUPPORT TECHNIQUE PAR TELEPHONE – SERVICE DESK – ITIL ............................................ 69

2.3. Profils ............................................................................................................................... 70 3. COMPOSANTE « TESTING (LOT 5).......................................................................................................... 73

3.1. Missions ........................................................................................................................... 73 3.2. Contexte. .......................................................................................................................... 74

3.2.1. ENVIRONNEMENT ORGANISATIONNEL ........................................................................................ 74 3.2.2. REFERENCE ..................................................................................................................................... 74 3.2.3. ENVIRONNEMENT TECHNIQUE SPECIFIQUE AUX MISSIONS .................................................... 75

3.2.3.1. Méthodologie de travail ............................................................................................ 75 3.2.3.2. Test tools arsenal ..................................................................................................... 75 3.3. Profils. .............................................................................................................................. 77

3.3.1. PROFILS TESTEURS ET QUALITY ASSURANCE COORDINATOR .............................................. 77 3.3.1.1. Compétences communes ......................................................................................... 77 3.3.1.2. Profils spécifiques ..................................................................................................... 78

4. SLA. ............................................................................................................................................................ 82 4.1. INTRODUCTION ........................................................................................................................................ 82 4.2.PRINCIPE D’ELABORATION DES SLA DANS LE CADRE DE CE MARCHE ET DELIVERABLES

CORRESPONDANTS................................................................................................................................. 83 4.2.1.CONCEPT DE MASTER SLA - TEMPLATE SLA SPFFIN ...................................................................... 83 4.2.2. PROJET DE « DOSSIER ACCORDS ET PROCEDURES (DAP) » – CONTENU ................................... 83 4.2.4.PROJET DE TABLEAU DE KPI AVEC CLAUSES D’AMENDE ................................................................ 86 4.2.5.SERVICE LEVEL REPORTING (SLR) - RAPPORTAGE SUR LE NIVEAU DE SERVICE ..................... 86 4.2.6.SERVICE QUALITY PLAN (SQP) – PLAN DE QUALITE DE SERVICE ................................................... 86 4.2.7.SERVICE IMPROVEMENT PLAN (SIP) – PLAN D’AMELIORATION....................................................... 86 4.2.8.SERVICE LEVEL MANAGEMENT ........................................................................................................... 86 4.2.9.DELAIS ET MOYENS D’ELABORATION DES DAP, APRES L’ATTRIBUTION DU MARCHE ................ 87 4.3.ENCADREMENT SLA.................................................................................................................................. 87 4.3.1.RELATION ENTRE SLA ET ITIL© V3-2011 – GLOSSARY ...................................................................... 87 4.3.2.RELATION ENTRE LES SLA ET LES NORMES ET FONDEMENTS ICT DU SPF FINANCES. ............. 87 4.3.4.GESTION ET CONTROLE DES SLA ....................................................................................................... 88 4.3.5.PRINCIPE DES QUALITY GATES DANS LES CYCLES DE DEVELOPPEMENT ................................... 88 4.3.6.ENVIRONNEMENTS A SUPPORTER DANS LE CADRE DE CES SLA .................................................. 90


4.4.SERVICE LEVELS ET ENGAGEMENTS DE RESULTATS CORRESPONDANTS DANS LE CADRE DE CE MARCHE .................................................................................................................................................... 90

4.5. SERVICE LEVELS RELATIFS A LA GESTION DE PROJET : DELAI, EXHAUSTIVITE ET PLANIFICATION ......................................................................................................................................... 91

4.5.1.PI-PROJECT-BID-DELIVERY-PERIOD .................................................................................................... 91 4.5.2.PI-BID-COMPLETENESS ......................................................................................................................... 91 4.5.2.1.COMPOSITION MINIMALE DU LOT -1-2-3-4-5 .................................................................................... 91 4.5.2.2.DESCRIPTION ...................................................................................................................................... 91 4.5.3.PI-PROJECT PLAN-PLANNING ............................................................................................................... 92 4.6.NIVEAUX DE SERVICE PHASE DE DEVELOPPEMENT : CONFORMITE A LA METHODOLOGIE FUP,

AUX STANDARDS ICT ET QUALITE DU CODE ....................................................................................... 92 4.6.1.PI-FUP-DELIVERABLES .......................................................................................................................... 93 4.6.2.PI-FUP-TOOLS & ICT- STANDARDS....................................................................................................... 93 4.6.3.PI-QUALITY-OF-CODE ............................................................................................................................ 94 4.6.4.PI-SECURITY-INTEGRITY-CODE ........................................................................................................... 94 4.7.SERVICE LEVELS MISE EN PRODUCTION .............................................................................................. 94 4.7.1.PI-CONTINUOUS-INTEGRATION-TOOL-CHAIN .................................................................................... 94 4.7.2.PI-RELEASES-IN-PRODUCTION............................................................................................................. 95 4.8.SERVICE LEVELS EXIGENCES NON FONCTIONNELLES ....................................................................... 95 4.8.1.PI–AVAILIBILITY-7X24X365 ET PI-AVAILIBILITY-5X12 .......................................................................... 95 4.8.1.1.PERIODES D’OUVERTURE DU SERVICE (SERVICE WINDOW) ET PERIODES DE MAINTENANCE

DANS LE CADRE DE CES SLA ................................................................................................................. 95 4.8.1.2.SERVICE WINDOWS PAR CATEGORIE D’APPLICATIONS ............................................................... 95 4.8.1.3.NORMES PI–AVAILIBILITY-7X24X365 ET PI-AVAILIBILITY-5X12 ...................................................... 97 4.8.1.4.CLAUSES D’AMENDE PI–AVAILABILITY ............................................................................................. 97 4.8.2.PI-PERFORMANCE.................................................................................................................................. 97 4.9.SERVICE LEVELS EN MATIERE DE TRAITEMENT D’INCIDENTS, D’INTERVENTIONS CORRECTRICES

ET REACTIVES .......................................................................................................................................... 99 4.9.1.PRIORITES DES INCIDENTS .................................................................................................................. 99 4.9.2.MATRICE DE PRIORITES ...................................................................................................................... 100 4.9.3.PI-INCIDENT-RESPONSE-TIME ............................................................................................................ 101 4.9.4.PI-INCIDENT-RESOLUTION-TIME ........................................................................................................ 101 4.10.SERVICE LEVELS CONCERNANT LES SERVICES DU PERSONNEL MIS A DISPOSITION PAR

L’ENTREPRENEUR ................................................................................................................................. 102 4.10.2.PI-BID-REACTIVENESS ....................................................................................................................... 102 4.10.3.PI-STAFF-TIMESHEET ........................................................................................................................ 102 4.11.SERVICE LEVELS CONCERNANT LE LOT 5 TESTING. ....................................................................... 103 4.11.1.APERÇU ............................................................................................................................................... 103 4.11.2.KPI TEST PROJECT ............................................................................................................................ 103 4.11.2.1PI-TEST-EXECUTION-RATIO ............................................................................................................ 103 4.11.2.2.PI-ACTUALIZED-TESTING-EFFORT- BURN- DOWN-RATE (MANAGEMENT KPI) ........................ 104 4.11.3.KPI’S TEST QUALITY ........................................................................................................................... 104 4.11.3.1PI-TEST-EXECUTION-COVERAGE ................................................................................................... 104 4.11.3.2.PI-TEST-BUILD-COVERAGE ............................................................................................................ 104 4.11.3.3.PI-DEFECT-DETECTION-RATIO ...................................................................................................... 104 4.11.4.KPI TESTING PROCESS PERFORMANCE ........................................................................................ 105 4.11.4.1.PI-TEST-EFFICIENCY ....................................................................................................................... 105 4.11.4.4.PI-TEST-CASE-AUTOMATION ......................................................................................................... 105 4.12.PERIODES D’APPLICATION DES DIFFERENTS SLA ........................................................................... 105 4.13.SANCTIONS ............................................................................................................................................ 106 4.13.1.PRINCIPE DES PROPOSITIONS D’AMENDES .................................................................................. 106 4.13.2.TABLEAU DES CLAUSES DE PENALITE ........................................................................................... 106 4.14. SLA MONITORING, RAPPORTAGE ET ANALYSE, CONCERTATION DU SERVICE MANAGEMENT 106 4.14.1.SLA-MONITORING ............................................................................................................................... 106 4.14.1.1.MONITORING DE BASE AU SEIN DU SPF FINANCES ................................................................... 106 4.14.1.2.ASSISTANCE DANS LE CADRE DU MONITORING PAR L’ADJUDICATAIRE ................................ 107 4.14.2.RAPPORTAGE SLA, REVIEWS, IP-SLR ............................................................................................. 107 4.14.2.1.RAPPORTAGE SERVICE LEVEL (SLR) GENERAL ......................................................................... 107 4.14.2.2.PI-SLR ............................................................................................................................................... 108 4.14.2.3.CONCERTATION SERVICE MANAGEMENT ................................................................................... 108 4.15.AUTRES SERVICE LEVELS, OBLIGATIONS DE RESULTATS ET CONCLUSION ............................... 109

C. ANNEXES ..................................................................................................................... 111

ANNEXE 1 : FORMULAIRE D’offre ..................... ............................................................. 112

ANNEXE 2: Modèle de référence ..................... ................................................................ 118

ANNEXE 3.a.: Curriculum vitae - INDIVIDUEL ........ ........................................................ 119

ANNEXE 3.B.: Curriculum vitae - SYNTHESE........... ...................................................... 121


ANNEXE 4: SLA a completer ......................... .................................................................. 122

ANNEXE 5 –DESCRIPTIF DES APPLICATIONS ............. ................................................. 123

ANNEXE 6 : SLA TEMPLATE ........................... ................................................................ 209

ANNEXE 7 : CYCLE DE MAINTENANCE…………………………………………………… 215 SERVICE PUBLIC FEDERAL Finances

Service d’Encadrement Logistique Division Achats

North Galaxy – Tour B4 – bte 961 Boulevard du Roi Albert II, 33

1030 BRUXELLES

CAHIER SPÉCIAL DES CHARGES n° S&L/AO/386/2014 APPEL D’OFFRES OUVERT POUR LA MAINTENANCE DES APPLI CATIONS DE

L’ADMINISTRATION GENERALE DE LA FISCALITE (SPF FINA NCES).

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 le présent cahier spécial des charges, il a été dérogé aux articles : - 154 de l’arrêté royal du 14 janvier 2013 relatifs aux amendes ; - 25 de l’arrêté royal du 14 janvier 2013 relatifs au cautionnement.

B. DISPOSITIONS GENERALES

1. Objet et nature du marché. Le présent appel d’offres ouvert a pour but de réaliser la maintenance des applications de l’Administration Générale de la Fiscalité (SPF Finances). La procédure de l’appel d’offres ouvert avec publicité européenne est choisie. Le présent marché comporte 5 (cinq) lots :

- Lot 1 : Développement/support opérationnel des applications de l'Administration Générale de la Fiscalité - Domaine TVA

- Lot 2 : Développement/support opérationnel des applications de l'Administration Générale de la Fiscalité - Domaine Impôts des Personnes Physiques (Impôts des personnes physiques et des non-résidents)

- Lot 3 : Développement/support opérationnel des applications de l'Administration

Générale de la Fiscalité - Domaine Impôts des Personnes Morales (Impôt des Sociétés, Impôt des Personnes morales et Impôt des Sociétés non résidentes) et domaine transversal (par exemple Précompte mobilier et épargne à long terme)


- Lot 4 : Développement/support opérationnel des applications de l'Administration

Générale de la Fiscalité - Domaine STIRINT

- Lot 5 : Test des applications de l’Administration Générale de la Fiscalité Le lot 5 ne pourra pas être attribué à un adjudicataire des lots 1, 2, 3 et 4. Le contenu applicatif de chacun des lots 1 à 4 est déterminé par le domaine d’activité précisé notamment dans sa dénomination (objet du marché). L’attention est attirée sur le fait que la liste (applications par lot) communiquée au présent document est ouverte. La maintenance d’une application non listée sera rattachée par le SPF à l’un des 4 lots, tenant compte de la même règle. En cas de situation indécise (application à la frontière entre plusieurs lots), le SPF Finances reste seul décisionnaire en la matière. Il s’agit d’un marché à bordereau de prix (A.R. 15 juillet 2011, art. 2, 5°). Les variantes ne sont pas autorisées. Ce marché est composé de cinq lots. L’estimation budgétaire annuelle (TVAC) pour ces lots est la suivante : lot 1 : 2.500.000€ lot 2 : 1.900.000€ lot 3 : 1.850.000€ lot 4 : 2.700.000€ lot 5 : 1.580.000€ Ces montants sont donnés à titre indicatif, ils ne constituent pas un engagement pour le SPF FINANCES.

2. Durée du contrat.

Le contrat prend cours le 1er jour 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 au cours de laquelle les commandes peuvent être remises au prestataire de services. Chaque partie peut mettre fin au contrat à la fin de la première, de la deuxième de la troisième, de la quatrième, de la cinquième ou de la sixième année à 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 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.

3. Pouvoir adjudicateur – Informations complémentai res. Le pouvoir adjudicateur est l’Etat 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].

4. Documents régissant le marché

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

4.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 présent cahier spécial des charges n° S&L/AO/3 86/2014. - Les offres approuvées des soumissionnaires.

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

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


5.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é.

6. Session d’information. Pour le présent marché, le pouvoir adjudicateur organisera une session d’information à l’intention des soumissionnaires. Cette session d’information se déroulera le 2 septembre 2015 dans l’une des salles du bâtiment « North Galaxy » situé Boulevard du Roi Albert II, 33 à 1030 Bruxelles. Il sera répondu aux questions posées préalablement. Afin de permettre un déroulement correct de la session d’information, les candidats potentiels qui souhaitent y assister sont priés de faire parvenir leurs questions au pouvoir adjudicateur par courrier électronique à l’adresse suivante : [email protected]. en mentionnant la référence et l’objet du marché . Seules les questions qui seront parvenues au pouvoir adjudicateur au plus tard le 24 août 2015 à 17 h.00 avant la session d’information seront traitées pendant cette session. A l’entrée de la salle de réunion, il sera demandé aux participants d’indiquer l’identité de l’entreprise qu’ils représentent ainsi que leur adresse complète sur une liste de présence. Un participant ne pourra être représenté par plus de deux personnes lors de la session d’information.


C.ATTRIBUTION

1. Droit et modalités d’introduction et ouverture d es offres

1.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 électroniquement via l’application e-tendering (voir ci-dessous pour plus d’informations). 1.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 juil let 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 d’ouverture des offres. 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.


1.1.2. Documents qui ne peuvent être introduits par des moyens électroniques Les documents qui ne peuvent être introduits par des moyens électroniques sont glissés dans une enveloppe fermée. L’enveloppe fermée sera déposée par le soumissionnaire ou son représentant soit: - le jour de la séance d’ouverture, en mains propres au président, avant que celui-ci

n’ouvre la séance; - en mains propres à un fonctionnaire de la Division Achats, au plus tard le jour ouvrable

précédant la date de l’ouverture des offres; - à la poste. Toute autre modalité d’expédition (comme Taxipost, courrier exprès, etc.) se fera sous l’entière responsabilité du soumissionnaire. Les documents sont acceptés pour autant que la séance d’ouverture des offres n’ait pas été déclarée ouverte. Toutefois, une enveloppe arrivée tardivement est prise en considération pour autant: - que le pouvoir adjudicateur n'ait pas encore notifié sa décision à l'adjudicataire, - et que l’enveloppe ait été déposée à la poste sous pli recommandé, au plus tard le

quatrième jour de calendrier précédant le jour fixé pour la réception des offres. Les documents seront déposés en deux exemplaires sur papier dont un original. Les documents seront glissés dans une enveloppe fermée portant les deux indications suivantes - la référence du cahier spécial des charges : S&L/AO/386/2014 - a date et l’heure de l’ouverture des offres : le 1 octobre 2015 à 14u30 Ce pli scellé est glissé dans une seconde enveloppe portant les mentions suivantes: - dans le coin supérieur gauche: - le mot « OFFRE » - la référence du cahier spécial des charges : S&L/AO/386/2014 - si la soumission est déposée par porteur, les données relatives aux personnes de

contact chargées de la réception des offres: − OPDECAM Christine 0257/63482 − VAN OVERWAELLE Wendy 0257/68347 − AUBRY Céline 0257/89634 − DEBANDE Michaël 0257/79775 − DE PROOST Patricia 0257/73122

- à l’endroit prévu à cet effet l’adresse du destinataire. Le soumissionnaire qui remet son enveloppe par porteur doit savoir que le North Galaxy n’est accessible que par l’entrée « visiteurs » située au rez-de-chaussée, boulevard du Roi Albert II, 33 à 1030 BRUXELLES et ce, uniquement pendant les heures de bureau soit de 9 à 11h45 et de 14 à 16 heures. Si l’enveloppe est déposée par porteur, un accusé de réception ne sera délivré que si la demande en est faite expressément. Il est important de noter que seul cet accusé de réception peut servir de preuve du dépôt de l’enveloppe.


Le soumissionnaire assume l’entière responsabilité des modalités d’envoi et de réception de son enveloppe dans les délais impartis. Les enveloppes doivent être expédiées ou déposées à l’adresse suivante: 1.1.3. 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 mentionnés de façon précise. 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.

1.2. Ouverture des offres La séance d’ouverture des offres aura lieu le 1 oct obre 2015 à 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.

Service Public Fédéral FINANCES Service d’Encadrement Logistique

Division Achats A l’attention de Monsieur Pierre THONON, Conseiller

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

1030 BRUXELLES


2. Offres

2.1. Données à mentionner dans l’offre Il est fortement recommandé au soumissionnaire d’utiliser le formulaire d’offre. 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 et à compléter le métré récapitulatif ou l’inventaire, le soumissionnaire en fait usage. A 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. 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. Les renseignements suivants seront mentionnés dans l’offre : - les montants unitaires de l’offre en lettres et en chiffres (hors TVA) ; - les montants unitaires de l’offre en lettres et en chiffres (TVA incluse) ; - l’ordre de priorité des lots ; - 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 nom, 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.

2.2. Structure de l’offre L’offre du soumissionnaire se compose obligatoirement de trois volets distincts, pour chaque lot auquel il soumissionne : Volet A « Volet administratif » Ce volet se compose des éléments suivants : I. Formulaire d’offre Le soumissionnaire présente dans ce chapitre les pièces suivantes dans l’ordre imposé :


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.

II. Documents relatifs aux critères de sélection Le soumissionnaire présente dans ce chapitre les pièces suivantes :

1. 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 services auxquels se

réfère le marché et réalisés au cours des trois dernières années.

2. Documents relatifs aux critères de sélection permettant d’évaluer la capacité technique du soumissionnaire :

- Les références relatives à des prestations d’un niveau au moins équivalent exigées

au point 5.1.2. « sélection qualitative » du volet C. Attribution du cahier spécial des charges. Pour communiquer ces références, le soumissionnaire fait usage du modèle joint en annexe 2 de ce cahier spécial des charges.

Volet B « Volet technique » Dans ce volet, le soumissionnaire joint tous les éléments et documents techniques pour l’évaluation de l’offre. Volet C « Annexes » Dans ce volet, le soumissionnaire joint l’ensemble des annexes et des documents utiles non exigés dans les volets précédents.

2.3. Durée de validité de l’offre Les soumissionnaires restent liés pendant un délai de 240 jours à compter du premier jour calendrier qui suit le jour de l’ouverture des offres déposées.

2.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).

3. Prix. Le présent marché est un marché à bordereau de prix. Le prestataire de services est censé avoir inclus dans son prix global tous les frais possibles grevant les services, à 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.

4. Droit d’accès – Sélection qualitative – Régulari té des offres – Critères d’attribution

4.1. Droit d’accès et sélection qualitative Les soumissionnaires sont évalués sur base du droit d’accès et de la sélection qualitative repris 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. 4.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. Premier critère d’exclusion § 1er 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é Socia le 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 coti sations 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é à l’alinéa 2, à


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

§ 2. Le soumissionnaire étranger doit, au plus tard la veille de la date limite de réception des offres:

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, 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 tell e que définie à l’article 324bis du Code

pénal 2° corruption, telle que définie aux articles 246 e t 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’artic le 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 Sera exclu de l’accès au marché, à quelque stade que ce soit de la procédure, le soumissionnaire: 1° qui 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 Sera 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é, 1 957) 2° le droit à la liberté syndicale (convention n° 8 7 sur la liberté syndicale et la protection du

droit syndical, 1948)

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

4° l’interdiction de toute discrimination en matièr e de travail et de rémunération (conventions n° 100 sur l’égalité de rémunération, 1951 et n° 11 1 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).

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’arrêté royal 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 ses obligations relatives au paiement de ses impôts et taxes selon la législation belge ou celle du pays dans lequel 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 o u d’une entreprise publique au sens de


l’article 2,2°, de la loi, à la fin de la période f iscale 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 taxes. 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 porter sur la dernière période fiscale écoulée avant la date limite de réception 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. 4.1.2. Sélection qualitative Critères de sélection relatifs aux moyens financier s du soumissionnaire (article 67, 3° de l’arrêté royal du 15 juillet 2011) IMPORTANT Pour les soumissionnaires introduisant une offre pour plusieurs lots, les exigences imposées dans les critères de sélection relatifs aux moyens financiers sont cumulatives. En d’autres termes, s’il remet une offre pour plusieurs lots, le soumissionnaire doit avoir réalisé un chiffre d’affaires annuel au moins égal à la somme des chiffres d’affaires annuels exigés par lot pour lequel il soumissionne. A défaut de justifier un chiffre d’affaires suffisant pour l’ensemble des lots pour lesquels il remet une offre mais suffisant pour soumissionner pour un ou plusieurs lots parmi ceux qu’il a choisis, le soumissionnaire indique dans le formulaire d’offre l’ordre de priorité des lots pour lesquels il soumissionne. En l’absence d’une indication de cette priorité, le pouvoir adjudicateur procèdera par tirage au sort. Un soumissionnaire peut, le cas échéant et pour des marchés déterminés, faire valoir les capacités d’autres entités, quelle que soit la nature juridique de son lien avec ces entités (un sous-traitant par exemple). Il doit, dans ce cas, prouver au pouvoir adjudicateur que, pour l'exécution du marché, il disposera des moyens nécessaires par la production de l'engagement de ces entités de mettre de tels moyens à la disposition de l’adjudicataire.

Le soumissionnaire doit avoir réalisé au cours de chacun des trois derniers exercices comptables 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 : 1.000.000,00 EUR Pour le lot 2 : 1.000.000,00 EUR


Pour le lot 3 : 1.000.000,00 EUR Pour le lot 4 : 1.000.000,00 EUR Pour le lot 5 : 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 d u 15 juillet 2011) IMPORTANT Pour les lots 1, 2, 3, 4 et 5, un dossier incomplet ne sera pas pris en considération comme une référence valable. Pour les lots 1 à 4 : Le soumissionnaire doit disposer, au cours des trois dernières années, au minimum de 3 références similaires, d’une charge annuelle d’au moins : Pour le lot 1 : 1000 jours/homme. Pour le lot 2 : 1000 jours/homme. Pour le lot 3 : 1000 jours/homme. Pour le lot 4 : 1000 jours/homme. Pour démontrer le caractère similaire, le soumissionnaire remplit le tableau en annexe 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 accompagné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. Parmi ces références, une devra être présentée sous la forme d’un dossier complet. Ce dossier mentionnera les informations suivantes :

- Nom et adresse de la société ainsi que le nom, le numéro de téléphone et adresse mail d'une personne de contact chez le client (par exemple le chef de projet ou le sponsor du projet) ;

- Date de début et de fin du projet ;


- Objet du projet. Celui-ci devra être pertinent à l’égard des objectifs prévus pour chacun des lots dans la partie «dispositions techniques et fonctionnelles » du présent cahier spécial des charges ;

- Budget du projet ; - Synopsis complet du projet ; - Complexité (nombre d’entités, nombre d'utilisateurs clés, nombre d’utilisateurs

finaux, ….) ; - Outils/méthode pour la gestion du projet ; - Outils/méthode pour l’analyse ; - Outils/méthode pour le développement ; - Outils/méthode pour les tests ; - Outils/méthode pour la documentation ; - Outils/méthode visant à garantir un haut niveau de qualité des délivrables

produits ; - Outils/méthodes pour garantir la communication et la coopération des autres

équipes parties prenantes au projet (testing, production, Business…) ; - Listes des profils, nombre de personnes et d’hommes/jours pour l’ensemble du

projet. Pour le lot 5 : Le soumissionnaire doit disposer, au minimum de 3 références 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é

• Software testing d'application d'au moins 100.000 lignes de codes

• 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 accompagné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 les dites références ont été dûment exécutées, conformément aux exigences reprises ci-dessus. Parmi ces références, une devra être présentée sous la forme d’un dossier complet. Ce dossier mentionnera les informations suivantes : - Nom et adresse de la société ainsi que le nom, le numéro de téléphone et adresse mail d'une personne de contact chez le client (par exemple le chef de projet ou le sponsor du projet) ; - Date de début et de fin du projet. - Objet du projet. Celui-ci devra être pertinent à l’égard des objectifs prévus pour chacun des lots dans la partie «dispositions techniques et fonctionnelles » du présent cahier spécial des charges ; - Budget du projet. ; - Synopsis complet du projet ; - Complexité (nombre d’entités, nombre d'utilisateurs clés, nombre d’utilisateurs finaux, ….) ; - Outils/méthode pour la gestion du projet ;


- Outils/méthode pour l’analyse ; - Outils/méthode pour le développement ; - Outils/méthode pour les tests ; - Outils/méthode pour la documentation ; - Outils/méthodes pour garantir la communication et la coopération des autres équipes parties prenantes au projet (testing, production, Business…) ; - Listes des profils, nombre de personnes et d’hommes/jours pour l’ensemble du projet.

4.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 seront exclues. Seules les offres régulières seront prises en considération pour être confrontées aux critères d’attribution.

4.3. Critères qui seront utilisés lors de l’évaluat ion 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 Pour les lots 1, 2, 3, 4 et 5, Une commission d’évaluation attribue les points pour les critères d’attribution. 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. 4.3.1. Liste des critères d’attribution Pour les lots 1, 2, 3 et 4 : 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 30 II Mode d’exécution 50 (min 30) III SLA, garantie,

maintenance 20 (min 12)

Sous peine d’exclusion, le soumissionnaire doit obt enir au moins 60% des points pour les critères II et III.


Pour le lot 5 : 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 30 II Mode d’exécution Compréhension de la

méthodologie de test 15 (min 10) 50 (min 30)

Organisation équipe test par rapport à l’environnement organisationnel du SPF Finances

15 (min 10 )

Partenariat – garantie expertise sur nos standards

5

Capacité de mobilisation du personnel

15 (min 10)

III SLA 20 (min 12)

Pour le lot 5 : Sous peine d’exclusion, le soumissionnaire doit obt enir au moins le minimum repris entre parenthèses pour chacun des sous-critères et 60 % pour les critères principaux II et III à l’exception du troisième sous-critère « Partenariat – garantie expertise sur nos standards» dans le deuxième critère « mode d’ex écution ».

4.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, 2, 3 et 4 I.Le prix 30 points Concernant l’évaluation du critère d’attribution « Prix », la formule suivante sera appliquée pour calculer les points : Mo = P x 30/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 Task Manager Senior P1 (sur 10 points) Lead Technical Architect / Methodologist Senior

P2 (sur 10 points)

Analyste Business / Métier expert P3 (sur 25 points) Designer / Data Architect expert P4 (sur 25 points) Développeur senior P5 (sur 30 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 Task Manager (10 points) Le critère ‘Prix’ est pondéré de la façon suivante :

où : Proffre = prix de l’offre pour ce profil, Prmin = le prix de l’offre la moins chère dans les offres régulières pour ce profil. P1 = points attribués au critère ‘Prix profil Task Manager’ Les prix sont exprimés TVAC Prix profil Lead Technical Architect (10 points) Le critère ‘Prix’ est pondéré de la façon suivante :

où : Proffre = prix de l’offre pour ce profil, Prmin = le prix de l’offre la moins chère dans les offres régulières pour ce profil. P2 = points attribués au critère ‘Prix profil Lead Technical Architect’ Les prix sont exprimés TVAC Prix profil Analyste Business / Métier Expert (25 p oints) Le critère ‘Prix’ est pondéré de la façon suivante :

où : Proffre = prix de l’offre pour ce profil, Prmin = le prix de l’offre la moins chère dans les offres régulières pour ce profil. P3 = points attribués au critère ‘Prix profil Analyste Business / Métier Expert’ Les prix sont exprimés TVAC Prix profil Designer / Data Architect expert (25 po ints) Le critère ‘Prix’ est pondéré de la façon suivante :

où : Proffre = prix de l’offre pour ce profil,

offreP4

Pr

minPr 25× =

offreP3

Pr

minPr 25× =

offreP2

Pr

minPr 10× =

offreP1

Pr

minPr 10× =


Prmin = le prix de l’offre la moins chère dans les offres régulières pour ce profil. P4 = points attribués au critère ‘Prix profil Designer / Data Architect expert’ Les prix sont exprimés TVAC Prix profil Développeur senior (30 points) Le critère ‘Prix’ est pondéré de la façon suivante :

où : Proffre = prix de l’offre pour ce profil, Prmin = le prix de l’offre la moins chère dans les offres régulières pour ce profil. P5 = points attribués au critère ‘Prix profil Développeur senior’ Les prix sont exprimés TVAC Les compétences minimales et activités attendues sont décrites plus loin dans le texte. Rappel : le total des points est ensuite ramené sur 30 points. II. Le mode d’exécution 50 points IMPORTANT Le soumissionnaire qui n’obtiendrait pas les minimums décrits ci-dessous aux conditions n’entrerait pas en compte pour l’attribution du marché et l’offre sera dès lors considérée comme substantiellement irrégulière. Préambule Le critère d’évaluation « mode d’exécution » est répartis en treize (13) sous-critères. Chacun de ces sous-critères sont calculés sur 10 points. Le total obtenus sur 130 points sera alors ramené sur 50 points. Dans les sous-critères d’évaluation, nous vous demandons de démontrer certaines capacités, engagements, fonctionnements et compétences sur lesquels vous vous engagez pour toute la durée du contrat. Par « démontrer », nous entendons et attendons au minimum et systématiquement un argumentaire personnalisé et adapté au contexte de ce cahier des charges qui couvre au minimum les besoins exposés au niveau de chaque critère. Concrètement, une simple exposition de la théorie ou de la définition des termes, sans démonstration de leur utilisation concrète dans le contexte de ce cahier des charges, sera considérée comme insuffisante et pourra mener à cote d’exclusion. Pour chaque sous-critère, les points sont attribués selon 4 postes de mesure :

- A) points attribué à la présence, à la précision, à l’étendue, à la non-ambiguïté et à l’exhaustivité de la description et de la proposition .

offreP5=

Pr

minPr 30 ×


- B) points attribués à 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).

- C) points attribués à l’adéquation de la proposition aux besoins réels de l’organisation (en se basant essentiellement sur l’organisation, les standards et les fondements du SPF Finances, notamment les ABB – Architecture Building Blocks).

- D) points attribués sur la cohérence des propositions entre elles. Expression de la pondération des points pour chacun des 4 postes de chaque sous-critère

- Très bien : 100 % des points attribués au poste du sous-critère analysé - Bien : 75% des points attribués au poste du sous-critère analysé - Suffisant : 50% des points attribués au poste du sous-critère analysé - Faible : 20% des points attribués au poste du sous-critère analysé - Impossible à analyser : 0% des points attribués au poste du sous-critère analysé

Au maximum 4 postes pour l’ensemble des sous-critères, et au maximum un poste par sous-critère, peuvent présenter une évaluation inférieure à la mention « suffisant », sous peine d’exclusion de l’offre. Chaque sous-critère doit au moins présenter un total pondéré de 50% des points (somme A+B+C+D par rapport au maximum attribuable), sous peine d’exclusion de l’offre. L’exclusion d’un seul sous-critère amène à l’exclusion complète de l’offre. Table des sous-critères Les sous-critères sont répartis en quatre parties, selon la pondération des postes pour chaque critère. Partie 1 Poste A

2.5 pts max

Poste B 2.5 pts max

Poste C 2.5 pts max

Poste D 2.5 pts max

Maximum par ligne = A+B+C+D = 10

Sous-critère Score % Score points

Score % Score points



Total pondéré des points

II.1.Garantie continue des profils et de l’expertise

Partie 2 Poste A

3 pts max Poste B

3 pts max Poste C

3 pts max Poste D

1 pt max Maximum par

ligne = A+B+C+D = 10

Sous-critères Score % Score points





II.2.Mode d’exécution – Organisation de l’équipe

II.3.Mode d’exécution – Coopération avec le SPF Finances


II.4.Mode d’exécution – Coopération test ICT

II.5.Mode d’exécution – Coopération requirements Business

II.6.Mode d’exécution – Coopération test Business

II.8.Mode d’exécution – Reporting régulier

II.9. Compréhension et engagement quant aux standards

II.10. Gestion de la configuration

II.11.Documentation

Partie 3 Poste A

2 pts max Poste B

2 pts max

Poste C 3 pts max

Poste D 3 pts max


Sous-critère Score % Score points





II.7.Mode d’exécution – Méthodologie pour les offres

Partie 4 Poste A

3 pts max Poste B

3 pts max

Poste C 2 pts max

Poste D 2 pts max


Sous-critères Score % Score points





II.12.Coopération des rôles

II.13. Gestion de programme

Quelques exemples : Les exemples proposés sont fournis à titre d’illustration et ne peuvent en aucun cas être opposables.

Exemples chiffrés Poste A

2 pts

max

Poste B

2 pts

max

Poste C

3 pts

max

Poste D

3 pts

max

Maximum par

ligne = A+B+C+D =

10

Sous-critères Score % Score

points

Score % Score

points

Score % Score

points

Score % Score

points

Total pondéré des

points

II.8.Mode

d’exécution –

Méthodologie pour

les offres

50% 1 75% 1.5 100% 3 20% 0.6 6.1

Le sous-critère n’est pas exclu et reçoit la cote 6.1.


II.8.Mode

d’exécution –

Méthodologie pour

les offres

20% 0.4 75% 1.5 50% 1.5 50% 1.5 4.9

(<50%)

� EXCLUSION

Le sous-critère est exclu en raison d’un total insuffisant. � Exclusion de l’offre.

II.8.Mode

d’exécution –

Méthodologie pour

les offres

100% 20%

(<50%) :

1°

100% 0%

(<50%) :

2° �

EXCL.

EXCL. EXCLUSION

Deux postes ont une note inférieure à 50% pour unsous- critère donné � Exclusion du sous-critère et exclusion de l’offre.

II.2.2.Mode

d’exécution –

Organisation de

l’équipe

100% 75% 20%

(<50%) :

1°

50%

II.2.3.Mode

d’exécution –

Coopération avec le

SPF Finances

100% 100% 100% 20%

(<50%) :

2°

II.8.Mode

d’exécution –

Méthodologie pour

les offres

20%

(<50%) :

3°

75% 100% 75%

II.2.10. Gestion de la

configuration

50% 75% 100% 20%

(<50%) :

4°

II.2.11.Documentatio

n

100% 20%

(<50%) :

5° �

EXCL.

EXCL 100% 50% EXCLUSION

Plus de quatre postes ont une note inférieure à 50% pour l’ensemble des sous-critères � Exclusion de l’offre.

Sous-critère d’attribution 1 : Garantie continue des profils et de l’expertise Outre l’engagement écrit relatif à la capacité de mobilisation et la stabilité de l’équipe, la firme doit démontrer qu’elle peut assurer la qualité des profils, et garantir la stabilité des profils, des équipes, des compétences et de l'expertise, notamment en cas de turnover du personnel, et ce, dans tous les types de profil. A cette fin, la firme décrit, dans son offre, une stratégie complète de staff management, de continuité, de gestion et de transfert de la connaissance et de la compétence, composée notamment de rôles et responsabilités (RACI) et des processus nécessaires.

Sous-critère d’attribution 2 : Mode d’exécution – Organisation de l’équipe La firme doit démontrer qu’elle peut assurer l’organisation de l’équipe quant à ses travaux de développement et de support, en ce compris les prestations réalisées en co-sourcing. Elle expose et démontre sa stratégie détaillée à ce sujet, et les bonnes pratiques précises qu’elle mettra en œuvre. Elle détaille en outre un OBS où sont décrits rôles et responsabilité, en cohérence avec la structure organisationnelle actuelle du SPF Finances et son SE ICT. Elle expose comment elle pourrait, le cas échéant, s’adapter à un changement structurel de l’organisation. La firme s’engage enfin à utiliser l’outil Redmine (ou son remplaçant) du département ICT-Development pour la distribution et le suivi des tâches/activités des membres des équipes.


Sous-critère d’attribution 3 : Mode d’exécution – Coopération avec le SPF Finances La firme doit démontrer sa coopération active avec les membres du personnel SPF Finances (avec au minimum le business et l’ICT). A cette fin, elle expose et démontre dans l’offre la manière dont elle compte agréger et faire circuler, de façon organisée, la connaissance et l’information relative aux connaissances des projets et de leur contenu, et assurer la transparence nécessaire avec le personnel ICT et l’implication satisfaisante de ce dernier à tout moment de la vie des projets. La participation occasionnelle à l’élaboration de contenu en eLearning est une piste d’approche à prendre en considération. La firme s’engage à assurer cette coopération de manière continue, implicite et intégrée sans supplément de prestation. Elle doit démonter dans sa stratégie sa méthodologie et sa responsabilisation dans le transfert de son savoir et quant à la garantie que ce savoir sera acquis par les membres du SPF Finances.

Sous-critère d’attribution 4 : Mode d’exécution – Coopération test ICT La firme doit s’assurer d’une coopération avec la ou les équipes de test ICT (internes, externes et notamment le lot 4 de ce cahier des charges), selon leurs méthodologies, dès le début du projet. La firme expose et démontre, de manière détaillée, comment elle compte intégrer cette coopération dans ses plans de projet et leur exécution.

Sous-critère d’attribution 5 : Mode d’exécution – Coopération requirements Business La firme doit s’assurer d’une coopération avec la ou les équipes d’analyse business, dès le début du projet, conformément aux standards du SPF Finances. La firme expose et démontre, de manière détaillée, comment elle compte effectuer la capture des réquirements et la gestion des requirements, et intégrer la coopération – et le support et l’éventuelle guidance vers une professionnalisation du pouvoir adjudicateur à ce sujet – dans ses plans de projet et leur exécution.

Sous-critère d’attribution 6 : Mode d’exécution – Coopération test Business La firme doit s’assurer d’une coopération avec la ou les équipes de test acceptance business, dès le début du projet, conformément aux standards du SPF Finances. La firme expose et démontre, de manière détaillée, comment elle compte intégrer cette coopération – et le support et l’éventuelle guidance vers une professionnalisation du pouvoir adjudicateur à ce sujet – dans ses plans de projet et leur exécution.

Sous-critère d’attribution 7 : Mode d’exécution – Méthodologie pour les offres La firme doit démontrer une totale transparence quant à la méthodologie de pré-analyse et d’évaluation qu’elle emploie pour estimer et confirmer la charge de travail pour la remise d’une offre ou pendant l’exécution d’un projet. A cette fin, elle expose et démontre de manière détaillée les modèles de calcul, les outils et les processus qu’elle s’engage à appliquer pendant l’exécution du marché.

Sous-critère d’attribution 8 : Mode d’exécution – Reporting régulier La firme doit assurer des comptes rendus détaillés des activités de son personnel, quel que soit son mode de prestation (régie, fixed-price, …). Cela doit obligatoirement se faire au moyen de l’outil Redmine (ou son éventuel équivalent) du département ICT-Development, en respectant les guidelines (et leurs mises à jour) développées par le département ICT-Development, et ce, afin d’objectiver les prestations et d’affiner les estimations par un


processus d’amélioration continue. En complément, la firme expose et démontre, de manière détaillée, les processus et artefacts de reporting qu’elle compte utiliser pour rendre compte de ses tâches/activités au SPF Finances, entre autres, l’équipe Intake du département ICT-Development et le client Business.

Sous-critère d’attribution 9 : Compréhension et engagement quant aux standards De manière générale, la firme doit montrer sa compréhension des standards et fondements – actuels et futurs – du SPF Finances, et s’engager à les appliquer pendant toute la durée du contrat. Les standards comprennent notamment les méthodologies, les techniques et technologies, les outils et les processus, du SPF Finances, de ses partenaires reconnus, du Service d’Encadrement ICT et de ses départements. Les standards techniques incluent, sans que cette liste soit exhaustive, les aspects de design et d’architecture conformes, de qualité du code, de sécurité du code, de maintenabilité, d’intégration, de couverture des tests et de documentation. La firme doit exposer et démontrer dans son offre de manière précise comment elle entend respecter les standards, s’y adapter pour des applications qui son issue d’ancien standards, ou intégrer des changements ou des nouveautés dans le panel de standards existants. Elle doit montrer comment elle peut s’accommoder à des processus et standards incomplets, en construction ou en mutation.

Sous-critère d’attribution 10 : Gestion de la configuration La firme doit gérer tous les configurations items qu’elle manipule de manière conforme aux standards du SPF Finances notamment en termes de documentation management et de release management, sous contrôle de versionning. Ceci inclut l’intrégration à la chaine de build (actuellement nommée FUP-ITIL) et la conformité attendue que cela implique aux différentes étapes de cette chaîne. On attend de la firme qu’elle expose et démontre les pratiques qu’elle compte mettre en œuvre à cette fin, de manière conforme aux standards du SPF Finances, en ce compris les aspects de build, de test et de déploiement continus et automatisés, le contrôle de la qualité inhérent, et la gestion des données nécessaires.

Sous-critères d’attribution 11 : Documentation produits et projets

La firme doit documenter les projets (inclus : le reporting) et les produits et artefacts des projets selon standards documentaires (en ce compris les templates) et de processus du SPF Finances (les méthodologies PMFIN et FUP). On attend de la firme qu’elle expose et démontre toutes les pratiques qu’elle compte mettre en œuvre à cette fin.

Sous-critère d’attribution 12 : Coopération des rôles La firme doit fonctionner de manière homogène dans les différents métiers IT qui la composent. Dans l’offre, elle doit exposer les rôles, les responsabilités et les processus qui démontrent une gestion disciplinée des interactions et du fonctionnement de l’équipe, y compris en y intégrant les aspects de co-sourcing.

Sous-critère d’attribution 13 : Gestion de programme La firme doit gérer son portfolio de projet et ses programmes de manière intégrée et transparente. Dans l’offre, elle doit démontrer comment elle compte s’y prendre pour répondre à ces exigences.


III. SLA61, garantie, maintenance 20 points IMPORTANT Pour entrer en ligne de compte pour l’attribution du marché, le soumissionnaire doit obtenir une cote d’au moins 60% pour le critère d’attribution « SLA, garantie, maintenance. En cas de non-respect de cette condition, l’offre sera considérée comme substantiellement irrégulière. Répartition des points sur 100 points à ensuite ramener à un score de 20 points

1. Pondération pour le SQP : 5 points 2. Pondération pour le SIP : 5 points 3. Pondération pour le Master SLA: 40 points 4. Pondération pour le DAP: 15 points 5. Pondération pour le modèle de reporting : 10 points 6. Pondération pour les pénalités : 25 points

Formule pour le calcul des pénalités :

• Les points pour ce critère d’attribution sont attribués sur la base de la formule suivante :

Où : B est le nombre de points qui est attribué au soumissionnaire pour le sous-critère pénalités du SLA ; B_w représente le score pondéré pour le sous-critère pénalités ; n représente le nombre de KPI frappés d’une pénalité ; x fait référence au numéro dans le tableau KPI ; B_(x_o) représente la pénalité de base minimum ou la pénalité supérieure proposée dans l’offre du soumissionnaire pour KPI x ; B_(x_max) représente la pénalité maximum proposée pour KPI x dans les offres de tous les soumissionnaires retenus ou la pénalité de base minimum proposée si aucune pénalité plus élevée n’a été proposée. Pour le lot 5 I. Le prix 30 points Concernant l’évaluation du critère d’attribution « Prix », la formule suivante sera appliquée pour calculer les points : Mo = P x 30/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 Prix profil Testeur P1 (40 points) Prix profil Coordinateur de test P2 (20 points) Prix profil Spécialiste en test tools P3 (10 points) Prix profil Spécialiste en méthodologie de test

P4 (15 points)

Prix profil Quality Assurance Coordinator P5 (15 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 pour ce profil, Prmin = le prix de l’offre la moins chère dans les offres régulières pour ce profil. P1 = points attribués au critère ‘Prix profil testeur’ Les prix sont exprimés TVAC Prix profil Coordinateur de test (20 points) Le critère ‘Prix’ est pondéré de la façon suivante :

où : Proffre = prix de l’offre pour ce profil, Prmin = le prix de l’offre la moins chère dans les offres régulières pour ce profil. P2 = points attribués au critère ‘Prix profil coordinateur de test’ Les prix sont exprimés TVAC Prix profil Spécialiste en test tools (10 points) Le critère ‘Prix’ est pondéré de la façon suivante :

où : Proffre = prix de l’offre pour ce profil, Prmin = le prix de l’offre la moins chère dans les offres régulières pour ce profil. P3 = 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 (15 points) Le critère ‘Prix’ est pondéré de la façon suivante :

offreP3

Pr

minPr 10× =

offreP2

Pr

minPr 20× =

offreP1

Pr

minPr 40× =


où : Proffre = prix de l’offre pour ce profil , Prmin = le prix de l’offre la moins chère dans les offres régulières pour ce profil . P4 = 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 (15 point s) Le critère ‘Prix’ est pondéré de la façon suivante :

où : Proffre = prix de l’offre pour ce profil, Prmin = le prix de l’offre la moins chère dans les offres régulières pour ce profil. P5 = points attribués au critère ‘Prix profil Quality Assurance Coordinator Les prix sont exprimés TVAC II. Le mode d’exécution 50 points IMPORTANT Pour entrer en ligne de compte pour l’attribution du marché, le soumissionnaire doit obtenir une cote d’au moins 60% pour le critère d’attribution « mode d’exécution » et 50% à chacun des sous-critères à l’exception du sous-critère « Partenariat – garantie expertise sur nos standards » composant le critère d’attribution « mode d’exécution ». Le soumissionnaire qui ne répondrait pas à ces deux conditions cumulatives n’entrerait pas en compte pour l’attribution du marché et l’offre sera dès lors considérée comme substantiellement irrégulière. Une attention particulière est apportée à l’organis ation mise en place par le soumissionnaire pour répondre de manière optimale a ux besoins exprimés, ce dans le cadre organisationnel et technique du SPF Finances, ce qui justifie du poids important donné à ce critère. Quatre sous-critères précisent ce critère : 1. Compréhension de la méthodologie de test (15 points)

Afin de vérifier la compréhension et la capacité technique du soumissionnaire de travailler sur base d'une méthodologie de test prédéfinie et actuellement utilisée au SPF Finances, il est demandé au soumissionnaire de faire une représentation textuelle en 5 pages maximum faisant une rapide présentation de sa compréhension de la méthodologie. Une description de la méthodologie propre au SPF Finances peut être consultée à l’adresse suivante : http://finances.belgium.be/fr/sur_le_spf/historique_modernisation/ict/ Cotation :

offreP5

Pr

minPr 15× =

offreP4

Pr

minPr 15× =


Afin de vérifier la documentation fournie, celle-ci sera relue par nos experts internes, celle-ci devra être correctement décrite, complète et cohérente par rapport à l’objet du lot 4 «Test des applications de l’Administration Générale de la Fiscalité » et devra couvrir au moins les points suivants :

� Aperçu et phases (les phases et activités) � Organisation (différents rôles et équipes) � Outils (outils par phase) � TCC Modèle opérationnel � Formation et Coaching � Communication � Amélioration et révision � TMv4 : alignement avec FUP-D5

Excel lent : Le soumissionnaire a couvert les 8 aspects repris ci-dessus de la méthodologie dans sa documentation de manière correcte, claire et précise.

15 points

Très bien : Le soumissionnaire a couvert 7 des 8 aspects de la méthodologie dans sa documentation de manière correcte, claire et précise.

13,15 points

Bien + : Le soumissionnaire a couvert 6 des 8 aspects de la méthodologie dans sa documentation de manière correcte, claire et précise.

11,25 points

Bien : Le soumissionnaire a couvert 5 des 8 aspects de la méthodologie dans sa documentation de manière correcte, claire et précise.

9,30 points

Suffisant : Le soumissionnaire a couvert 4 des 8 aspects de la méthodologie dans sa documentation de manière correcte, claire et précise.

7,5 points

Impossible à analyser/inexistant : Le soumissionnaire a couvert moins de 4 des 8 aspects de la méthodologie dans sa documentation de manière correcte, claire et précise.

Exclu

2. Organisation équipe test par rapport à l’environnement organisationnel du SPF Finances (15 points) Sur base de la méthodologie et également des informations remises au soumissionnaire, il est demandé de fournir un document décrivant et expliquant l’organisation d’une équipe de test fournie par le soumissionnaire en collaboration avec les différents intervenants du SPF finances. Ce document doit :

� être précisément décrit � comprendre une timeline reprenant les phases opérationnelles de la méthodologie

avec les intervenants (équipes) par phase � s’appuyer sur les structures organisationnelles

(http://www.minfin.fgov.be/PORTAIL2/fr/downloads/flowchart-future.pdf) et techniques


(ABB�http://finances.belgium.be/fr/sur_le_spf/historique_modernisation/ict/ict_fundamenten/) mises en place au sein du SPF.

� comprendre les flux de communication et de collaboration entre les différents stakeholders du SPF Finances.

Cotation : Le document sera relu par nos experts internes et devra comprendre au minimum les informations suivantes en termes de relation/communication :

� Business (Client) � Equipe de projet � Management (ICT, ICT QA&ITPS, Test Management) � Equipe de Test interne (ICT Test Management) � Equipe d’ICT Développement � Equipe d’ICT Operations � Equipe d’ICT Quality Assurance & IT Process support � La timeline du document devra couvrir au minimum les phases suivantes :

o Intake o Préparation o Planification o Scripting o Exécution et reporting

Excellent : Le soumissionnaire a couvert les 8 aspects de l’organisation dans sa documentation de manière correcte, claire et précise.

15 points

Très bien : Le soumissionnaire a couvert 7 des 8 aspects de l’organisation dans sa documentation de manière correcte, claire et précise.

13,15 points

Bien +: Le soumissionnaire a couvert 6 des 8 aspects de l’organisation dans sa documentation de manière correcte, claire et précise.

11,25 points

Bien : Le soumissionnaire a couvert 5 des 8 aspects de l’organisation dans sa documentation de manière correcte, claire et précise.

9,30 points

Suffisant : Le soumissionnaire a couvert 4 des 8 aspects de l’organisation dans sa documentation de manière correcte, claire et précise.

7,5 points

Impossible à analyse r/inexistant : Le soumissionnaire a couvert moins de 4 des 8 aspects de l’organisation dans sa documentation de manière correcte, claire et précise.

Exclu

3. Partenariat – garantie expertise sur nos standards. (5 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


Cotation : 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 : 2.5 points � Gold : 3,5 points � Platinium : 4,5 points

(2) La firme possède un partenariat avec Cast software : 0,5 point La cotation finale de ce critère sera égale à la somme du partenariat HP et du partenariat Cast.

Partenariat HP (1) 0 point 2.5 points 3,5 points 4,5 points

Partenariat CAST (2) 0 point 0,5 point

Total (1) + (2) 4. Capacité de mobilisation du personnel (15 points) Le candidat doit disposer, d’au minimum un nombre de profils techniques correspondant au nombre de profils de compétences minimal tel que décrit dans les prescriptions techniques pour le lot 4. Pour démontrer cela, il annexe à son offre au minimum un CV correspondant au profil de compétence proposé. Le CV devra impérativement, pour le lot 5, respecter le modèle fourni par le pouvoir adjudicateur. Cotation : Il est demandé au minimum :

� 4 testeurs � 2 coordinateurs de test � 2 spécialistes en méthodologie de test � 2 spécialistes en outils de test � 2 quality assurance coordinators

Nombre de profil Testeur (P1)

Le soumissionnaire a proposé 8 testeurs ou plus qui correspondent au profil recherché

40 points

Le soumissionnaire a proposé 7 testeurs qui correspondent au profil recherché

35 points


30 points


25 points


20 points

Exclusion : Le soumissionnaire a proposé moins de Exclusion


4 testeurs qui correspondent au profil recherché. Nombre de profil Coordinateur de test (P2)

Le soumissionnaire a proposé 4 ou plus coordinateurs de test qui correspondent au profil recherché

20 points

Le soumissionnaire a proposé 3 coordinateurs de test qui correspondent au profil recherché

15 points

Le soumissionnaire a proposé 2 coordinateurs de test qui correspondent au profil recherché

10 points

Exclusion : Le soumissionnaire a proposé moins de 2 coordinateurs de test qui correspondent au profil recherché.

Exclusion

Nombre de profil spécialistes en méthodologie de test (P3)

Le soumissionnaire a proposé 4 ou plus spécialistes en méthodologie de test qui correspondent au profil recherché

10 points

Le soumissionnaire a proposé 3 spécialistes en méthodologie de test qui correspondent au profil recherché

7,5 points

Le soumissionnaire a proposé 2 spécialistes en méthodologie de test qui correspondent au profil recherché

5 points

Exclusion : Le soumissionnaire a proposé moins de 2 spécialistes en méthodologie de test qui correspondent au profil recherché.

Exclusion

Nombre de profil spécialistes en outils de test (P4)

Le soumissionnaire a proposé 4 ou plus spécialistes en outils de test qui correspondent au profil recherché

15 points

Le soumissionnaire a proposé 3 spécialistes en outils de test qui correspondent au profil recherché

11,25 points

Le soumissionnaire a proposé 2 spécialistes en outils de test qui correspondent au profil recherché

7,5 points

Exclusion : Le soumissionnaire a proposé moins de 2 spécialistes en outils de test qui correspondent au profil recherché.

Exclusion

Nombre de profil quality assurance coordinator (P5)

Le soumissionnaire a proposé 4 ou plus spécialistes en quality assurance coordinator qui correspondent au profil recherché

15 points

Le soumissionnaire a proposé 3 spécialistes en quality assurance coordinator qui correspondent au profil recherché

11,25 points

Le soumissionnaire a proposé 2 spécialistes en quality assurance coordinator qui correspondent au profil recherché

7,5 points


Exclusion : Le soumissionnaire a proposé moins de 2 spécialistes en quality assurance coordinator qui correspondent au profil recherché.

Exclusion

Nombre profils Points Nombre profil Testeur P1 (40 points) Nombre profil Coordinateur de test P2 (20 points) Nombre profil Spécialiste en outils de test P3 (10 points) Nombre profil Spécialiste en méthodologie de test

P4 (15 points)

Nombre profils Quality Assurance Coordinator

P5 (15 points)

Total intermédiaire (P1+P2+P3+P4+P5) P (100 points) Total pour la capacité de mobilisation du personnel

P*10/100

III. SLA 20 points IMPORTANT Pour entrer en ligne de compte pour l’attribution du marché, le soumissionnaire doit obtenir une cote d’au moins 60% pour le critère d’attribution « SLA ». En cas de non-respect de cette condition, l’offre sera considérée comme substantiellement irrégulière. Répartition des points sur 100 points à ensuite ramener à un score de 20 points

7. Pondération pour le SQP: 5 points 8. Pondération pour le SIP: 5 points 9. Pondération pour le Master SLA: 40 points 10. Pondération pour le DAP: 15 points 11. Pondération pour le reporting type : 10 points 12. Pondération pour les pénalités : 25 points

Formule pour le calcul des pénalités :

• Les points pour ce critère d’attribution sont attribués sur la base de la formule

suivante :

Où : B est le nombre de points qui est attribué au soumissionnaire pour le sous-critère pénalités du SLA ; B_w représente le score pondéré pour le sous-critère pénalités ; n représente le nombre de KPI frappés d’une pénalité ; x fait référence au numéro dans le tableau KPI ;


B_(x_o) représente la pénalité de base minimum ou la pénalité supérieure proposée dans l’offre du soumissionnaire pour KPI x ; B_(x_max) représente la pénalité maximum proposée pour KPI x dans les offres de tous les soumissionnaires retenus ou la pénalité de base minimum proposée si aucune pénalité plus élevée n’a été proposée.

4.3.3. Cote finale Par lot, la cote finale est attribuée à chaque offre en additionnant les points obtenus pour les 3 critères susmentionnés. L’offre la plus intéressante obtient la cote finale la plus élevée. 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.


D. EXECUTION

1. 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é. Le fonctionnaire dirigeant est le seul 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 partie de ses compétences.

2. 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 reco mmandée si le prestataire a laissé passer un ou plusieurs anniversaires. La révision des prix ne concerne que les services effectivement prestés après la date visée ci-dessus (attention : l’adjudicataire doit introduire une nouvelle demande pour la révision des prix des services à prester après l'anniversaire suivant).

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

+= 2.0*8,0*

00 S

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 revoir les prix en cas de baisse de

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

3. 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, l’adjudicataire 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.

4. Réception des services prestés.

4.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. Sauf avis contraire du pouvoir adjudicateur, aucune prestation ne peut avoir lieu sans que le service destinataire n’ait été averti par écrit au moins cinq jours ouvrables avant la date d’envoi des biens ou d’installation des logiciels.

4.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. 4.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 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. En vue de l’évaluation des services exécutés et du suivi du projet, le pouvoir adjudicateur peut faire appel à un tiers. L’adjudic ataire est tenu de collaborer avec ce tiers et de lui fournir toute l’information nécessa ire au bon accomplissement des opérations de contrôle. Dans ce cadre, le SPF Finances souhaite mettre l’of fre 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 soumis sionnaire 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.

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

4.5. Acceptations provisoires L’acceptation des résultats intermédiaires ou définitifs se fera suivant un processus standard (par application). Lorsque les opérations de contrôle sont achevées avec fruit et approuvées par le Project Board (comité de pilotage), le SPF Finances dresse un procès-verbal de réception provisoire des résultats (produits et/ou services) de la phase concernée. Le procès-verbal de réception provisoire sera signé par les deux parties.

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


4.7. Réception définitive La réception définitive est déclarée à la demande du fournisseur, après la fin de la période de garantie, pourvu que le SPF Finances n’ait pas formulé de plaintes concernant le bon fonctionnement pendant cette période. En cas d’objection, la réception définitive est reportée jusqu’au moment où le système a fonctionné correctement pendant une période ininterrompue d’un an. 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.

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

5. 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; Pour chacune des commandes passées dans le cadre de ce marché, le cautionnement est fixé à 5% du montant total de la commande, hors TVA. Le montant ainsi obtenu est arrondi à la dizaine d’euro supérieure.

5.1. Constitution du cautionnement 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 (caution). L’adjudicataire doit, dans les trente jours calendrier suivant le jour de la conclusion du marché, justifier la constitution du cautionnement par lui-même ou par un tiers, de l’une des façons suivantes:


1° lorsqu’il s’agit de numéraire, par le virement du montant au numéro de compte 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, p ar le dépôt par une société exerçant

légalement cette activité, d’un acte de caution solidaire auprès de la Caisse des Dépôts et Consignations ou d’un organisme public remplissant une fonction similaire

4° lorsqu’il s’agit d’une garantie, par l’acte d’en gagement de l’établissement de crédit ou de

l’entreprise d’assurances. Cette justification se donne, selon le cas, par la production au pouvoir adjudicateur: 1° soit du récépissé de dépôt de la Caisse des Dépô ts et Consignations ou d’un

organisme public remplissant une fonction similaire 2° soit d’un avis de débit remis par l’établissemen t de crédit ou l’entreprise d’assurances 3° soit de la reconnaissance de dépôt délivrée par le caissier de l’Etat ou par un

organisme public remplissant une fonction similaire

4° soit de l’original de l’acte de caution solidair e visé par la Caisse des Dépôts et Consignations ou par un organisme public remplissant une fonction similaire

5° soit de l’original de l’acte d’engagement établi par l’établissement de crédit ou

l’entreprise d’assurances accordant une garantie. Ces documents, signés par le déposant, indiquent au profit de qui le cautionnement est constitué, son affectation précise par l’indication sommaire de l’objet du marché et de la référence 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 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 de la constitution du cautionnement doit être envoyée à l’adresse suivante :

5.2. Libération du cautionnement

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


Le cautionnement sera libéré en une fois après réception définitive de la derniere commande exécutée sur la base du contrat conclu sur base du présent cahier spécial des charges, à condition que les services fournis aient été réceptionnés.

6. Modalités d’exécution

6.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 tra vail forcé, 1957) 2. le droit à la liberté syndicale (convention n° 8 7 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é roy al 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é.

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

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

6.4. Personnel de l’adjudicataire 6.4.1. Généralités Pour chacune des commandes basée 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 l e représentera dans ses rapports avec le SPF Finances. Le personnel de l’adjudicataire qui sera amené à réaliser le marché devra :

• avoir une expérience dans le cadre de la solution proposée ou de solutions comparables,

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

Le chef de projet doit être en outre capable de :

• communiquer oralement tant en français qu’en néerlandais.

Le service d’assistance (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 génér alement quelconque que le SPF Finances pourrait subir du fait du non-respect par l’adjudicataire ou les membres de son personnel des dispositions légales en question. L’adjudicataire doit disposer de suffisamment de personnel possédant les connaissances nécessaires et adaptées à l’exécution des tâches. Le personnel concerné doit également disposer d'une connaissance suffisante des outils utilisés dans le cadre du projet. Les adjudicataires doivent être capables de répondre immédiatement aux besoins résultant de l’attribution du marché. L’équipe de projet mise à disposition par l’adjudicataire doit être suffisante afin de mener à bien les missions qui lui sont confiées.

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 affecté à l'exécution du marché doit être le même que celui proposé dans l'offre. A défaut, le personnel mis à disposition pour l'exécution sera de niveau et d’expérience équivalents. Le SPF Finances devra marquer son accord sur la composition de l'équipe proposée pour le projet. L'adjudicataire garantit pour toute la durée du marché, la stabilité des personnes affectées à l'exécution du présent marché. En cours d'exécution, l'adjudicataire n'apportera aucun changement dans la composition de l'équipe de projet sans l'autorisation préalable du SPF Finances. 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-dev, 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. Pour cette personne, la firme doit proposer au minimum 3 CV au SPF Finances (le coordinateur ict, le responsable du département ict-dev, le gestionnaire de contrat) dans les deux semaines de la connaissance du départ, de profil au minimum équivalent en qualité et en compétences au membre qui quitte l’équipe, et s’assurer que les personnes adressées l’ont bien reçu.

- Le SPF Finances évalue les CV et donne réponse. 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. Aucune prestation ne doit à ce propos être prévue pour un quelconque intake sur les 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 comprome ttant la bonne exécution du marché par leur incapacité, leur mauvaise volonté o u 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. 6.4.2 Capacité de mobilisation de ressources au sein de l’équipe de développement / support L’adjudicataire s’engage par écrit à pouvoir fournir (capacité de mobilisation), pour toute la durée du contrat, une disponibilité minimale de profils garantis conformes au minimum aux pré-requis (voir ci-dessous la Table des capacités) et une stabilité de l’équipe. Ce minimum est étendu (*) lorsque la firme prend en charge plus de 4 projets concurrents. Il faut ensuite considérer une règle proportionnelle en fonction du nombre de projets concurrents. Table des capacités

- Profil Capacité minimale absolue Capacité minimale étendue * Task Manager senior 1 2 Task Manager junior 0 1 Lead Technical Architect / Methodologist senior

0.5 1

Analyste Business d’Application / Métier expert

3 6

Designer / Data architect expert 2 4 Développeur senior 8 12 On-boarding initial : On peut comprendre que l’équipe de la firme ne soit pas être immédiatement opérationnelle conformément aux standards et méthodologies mis en place par le SPF Finances. Le SPF Finances s’attend néanmoins à ce que la période d’acclimatation soit réalisée dans les plus brefs délais. Cette période d’acclimatation est sans supplément de prix.

6.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 qua litative, 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 par rapport à l’offre, l'adjudicataire informera le SPF Finances qui devra marquer son accord avant que l’adjudicataire puisse procéder au 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. 6.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. 6.7. Engagements particuliers pour le prestataire d e services. 6.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 se porte garant du respect de la confidentialité de ces informations par son personnel et ses sous-traitants. Il s’engage à ne pas les divulguer à des tiers, en ce compris les filiales et autres entreprises liées à l’adjudicataire. Il ne communiquera à son personnel et à celui de ses sous-traitants directement impliqués au marché, uniquement les données nécessaires à l'exécution de leur tâche, dans le cadre du présent marché. Les obligations énoncées ci-dessus ne sont pas applicables aux informations du SPF Finances :


• dont l’adjudicataire peut démontrer par un moyen acceptable par le SPF Finances qu'elles étaient déjà en sa possession au moment où elles lui ont été communiquées pour la première fois par le SPF Finances ;

• qui, au moment où elles ont été connues par le SPF Finances, étaient déjà publiques; • qui, après qu'elles aient été connues par le SPF Finances, ont été rendues publiques

autrement que par le fait de l’adjudicataire ; ou • que l’adjudicataire a obtenues d'un tiers qui disposait de bonne foi des informations

du SPF Finances et qui était autorisé à les communiquer à l’adjudicataire. L’adjudicataire s'engage :

• à ne pas copier tout ou partie de l'information du SPF Finances, si celle-ci se trouve sur un support mis à disposition par le SPF Finances ;

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

Toute l'information mise à la disposition de l’adjudicataire par le SPF Finances et tout support d'information, contenant de l'information du SPF Finances, mis à la disposition de l’adjudicataire par le SPF Finances reste l'entière propriété du SPF Finances. Même si l’adjudicataire a copié ou consigné ces informations ou une partie de celles-ci, elles demeurent la propriété intégrale du SPF Finances. Le SPF Finances a le droit, à tout moment, de demander à l’adjudicataire de lui remettre tout ou partie des supports d’information sur lesquels l’adjudicataire aura stocké de l’information du SPF Finances. L’adjudicataire s’engage à remettre immédiatement les supports réclamés sans les copier. L’adjudicataire s’engage à remettre au SPF Finances, à l’issue de l’exécution du marché et sans délai, tous les supports d’information qui contiennent de l’information du SPF Finances et qui ont été mis à la disposition de l’adjudicataire pour l’exécution du marché, pour autant que ces supports d’information n’aient pas déjà été remis au SPF Finances. L’adjudictaire 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 confidentilité. 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. 6.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. 6.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. Aussi, en cas de résiliation, l'adjudicataire proposera au SPF Finances un plan de transition spécifiant en détail les dispositions et conditions relatives aux tâches à accomplir pour fournir l'information nécessaire à la bonne 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.

7. Facturation et paiement. Les paiements ne peuvent être effectués qu’à posteriori, pour des fournitures ou 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 provisoire, la procédure est la suivante : La facture doit être établie en euros.


L'adjudicataire envoie sa facture à l'adresse suivante :

Service Public Fédéral FINANCES Service central de facturation

Boulevard Roi Albert II, 33 bte 788 – Bloc B22 1030 BRUXELLES

La facture peut être envoyée aussi, sous forme d’un fichier pdf, à l’adresse e-mail suivante : [email protected] La procédure de liquidation s’effectuera conformément au Règlement sur la Comptabilité de l’Etat. 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 EURO.

8. 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 à l'adresse indiquée au point « fonctionnaire dirigeant » de la partie II en présence des personnes désignées à cette fin par les deux parties. Sauf accord contraire, les


négociations ne pourront excéder une durée de 30 jours calendriers, à compter de la première lettre recommandée.

Tous les litiges relatifs à l’exécution de ce marché sont exclusivement tranchés par les tribunaux compétents de l’arrondissement judiciaire de Bruxelles. La langue véhiculaire est le français ou le néerlandais.

Le pouvoir adjudicateur n’est en aucun cas responsable des dommages causés à des personnes ou à des biens qui sont la conséquence directe ou indirecte des activités nécessaires à l’exécution de ce marché. Le prestataire de services garantit le pouvoir adjudicateur contre toute action en dommages et intérêts par des tiers à cet égard.

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

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

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

9.3. Imputation des amendes et pénalités IMPORTANT Pour rappel, le soumissionnaire propose dans son offre un S.L.A. dont les dédommagements s’ajoutent aux pénalités et amendes imposées par le pouvoir adjudicateur. 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

1. Principes généraux du marché.

1.1. Introduction

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

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 s’engage expressément à respecter les fondements actuels et futurs dans le cadre de l’exécution du présent contrat.

Le non-respect de cette règle essentielle du cahier spécial des charges peut entraîner la nullité de l’offre.

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 Java constitue la pierre angulaire de cette stratégie.

Cette migration est à l’heure actuelle très avancée. Les applications métiers de l’Administration Générale de la Fiscalité, qui à quelques exceptions près sont opérationnelles (en production) (voir ci-après pour plus de détail), constituent l’applicatif cible 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, et plus spécifiquement l’Administration Générale de la Fiscalité, 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.

Les domaines métier suivants sont visés:

� Domaine TVA : Intervat, STIR TVA (back-office TVA), Stiron TVA, MOSS (Mini One Stop Shop)

� Domaine impôts directs personnes physiques : TAXI (back office de gestion des dossiers IPP), TOW (Tax-On-Web), BOW (Belcotax-On-Web), PDS


(Proposition de Déclaration Simplifiée), Calculatrix (Calcul, enrôlement de l’impôt et des amendes administratives)

� Domaine impôts directs personnes morales : Biztax (partie front-office et partie back office), Calclsoc (Calcul, enrôlement de l’impôt)

� Domaine transnational AgFisc: STIRInt, FATCA, Auto_DT

� Domaine tranversal AgFisc: STIR Contrôle, STIR Recherches, Prm-on-web, FinELTS.

L’attention est attirée sur le fait que la liste des applications citées ci-dessus n’est nullement exhaustive mais constitue le cœur de la chaine de traitement relative à chacun des domaines considérés. La mention pour chaque métier de ses applications les plus critiques et emblématiques permet également de mieux cibler le scope de chaque lot. D’autres applications relevant de l’Administration Générale de la Fiscalité sont donc susceptibles de voir leur maintenance exécutée dans le cadre du présent marché et seront rattachées au lot du domaine fonctionnel correspondant.

1.2. Objectifs généraux du marché

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.

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), notamment dans les domaines suivants :

1.2.1. Mode de collaboration entre lots de support/développement et lot de testing Les équipes en charge du développement et du testing étant distinctes et dépendantes d’adjudicataires différents, l’organisation d’une collaboration efficace entre elles, tout au long du processus de développement, constitue un facteur clé de succès. Ce point étant central dans l’approche de professionnalisation et d’amélioration de la qualité initiée dans le présent cahier spécial des charges, le SPF Finances accordera une attention particulière à ce point.

1.2.2. Intégration entre les applicatifs fonctionnellement liés

Ainsi que décrit plus en détail ci-dessous, les développements ont été répartis en lots distincts et indépendants réunissant dans la mesure du possible les applicatifs présentant une forte intégration fonctionnelle et/ou technique. C’est le cas en particulier pour les domaines IPP et TVA. Cette approche intégrée vise à améliorer l’intégration entre divers composants étroitement liés mais développés au cours du temps par des prestataires différents et à l’aide de technologies pouvant diverger. L’attention sera donc apportée à des propositions favorisant l’amélioration dans tous les domaines de la qualité.

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

Les applications mises à disposition du personnel de l’Administration générale de la Fiscalité (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 disponibilité, performance, robustesse et impact sur les environnements (optimisation de la charge). L’attention du pouvoir adjudicateur portera donc sur les propositions dans ce domaine.

1.2.4. Souplesse et réactivité

Dans le cadre de l’exécution de sa mission, l’Administration Générale de la Fiscalité est de manière régulière amenée à introduire auprès de l’IT des demandes d’adaptation (« Change Requests »), parfois conséquentes et/ou urgentes, auxquelles il peut s’avérer difficile de répondre en termes de scope et/ou de délai de réalisation. Le SPF Finances, et l’Administration Génération de la Fiscalité en particulier, intègrera l’approche en la matière, notamment quant aux propositions visant à étendre la capacité IT à mieux cerner les besoins et à y répondre au mieux.

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

1.2.6. 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 visées par le présent marché. Le soumissionnaire est donc invité à 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).

1.3. Vision et encadrement

Vu le délai sur lequel s’étend le marché, le soumissionnaire est invité à exposer sa vision de l'exécution du marché, dans le cadre spécifique de l'environnement du SPF Finances. À cette fin, le soumissionnaire décrira de façon générale les aspects suivants, qui feront partie 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 que le soumissionnaire juge utile de mentionner

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.

1.4. Economie générale du marché

1.4.1. Séparation des aspects développement/support et testing Soucieux d’améliorer la qualité de ses applications informatiques, le SPF Finances a depuis quelques années entamé une démarche de professionnalisation du testing applicatif au sens large, ce dans l’esprit suivant :

− Professionnalisation des tests dans le cadre de la méthodologie élaborée pendant les projets PTC (Performance Test Center) et TCC (Test Competence Center) ;

− 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 respectivement en charge du développement et du testing ;

− 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é/testing :

o la partie « Développement et support au projet » (4 lots indépendants regroupés selon une logique fonctionnelle), comprenant globalement les activités liés au support et au développement applicatif (à l’exception des aspects spécifiquement liés au testing),

o la partie « Testing » (transversale aux trois lots de développement)

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 (Dev vs Testing) 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 à 4 sont expressément invités à prendre connaissance du contenu de la composante « Testing » (lot 5) et inversément.

1.4.2. Composition des lots

La partie du marché relative à la composante « Développement et support » est subdivisée en quatre lots distincts selon un critère articulé autour de la notion de domaine d’activité. A titre d’information, les tableaux ci-dessous précisent la composition applicative actuelle de chacun de ces lots.

Les applications non énumérées dans ce document, mais dont la maintenance serait effectuée dans le cadre du présent marché, seront intégrées à l’un de ces 4 lots, sur décision du SPF Finances notamment en fonction du domaine d’activité concerné.

Les tableaux ci-dessous précisent la situation au moment de la publication par domaine.

Lot 1 (Développement et support) : Domaine TVA

En production

Intervat Oui

STIR-TVA Oui

Stiron TVA Oui

MOSS (Mini One Stop Shop)

2015

Lot 2 (Développement et support) : Domaine Impôts directs - Personnes Physiques (IPP + INR PP)

En production

Belcotax-on-Web (BOW) Oui

Tax-On-Web (TOW) Oui

Taxi Oui

Proposition de Déclaration Simplifiée (PDS)

Oui

Calculatrix : Chaine de calcul et d’enrôlement IPP (impôt et amendes)

Oui


Lot 3 (Développement et support) : Domaine impôts directs personnes morales + tranversal AgFisc

En production

Biztax: Module Font-Office (FO)

Oui

Biztax : Modules Back-Office (BO) et Dossier Unique (DU)

Oui

Stir-Contrôle Oui

Stir-Recherche Oui

PRM-on-web Oui

CalcIsoc: Chaine de calcul et d’enrôlement à l’Impôt des Sociétés

Oui

FinELTS Oui

Lot 4 (Développement et support) : Domaine transnational

En production

STIRint Oui

FATCA Oui

Auto_DT Oui

1.4.3. Incompatibilité entre lots

Le SPF Finances estime incompatible la réalisation d’activités de développement dans le cadre des lots 1, 2, 3 ou 4 et la réalisation d’activités de testing dans le cadre du lot 5. 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 5 (testing), le soumissionnaire qui remporterait l’un des quatre premiers lots sera d’office écarté pour l’attribution du lot 5 sauf si le soumissionnaire a choisi le lot 5 comme premier choix dans son ordre de préférence via le formulaire d’offre. Dans ce cas, le soumissionnaire sera écarté pour l’attribution du lot 1, 2, 3 ou 4. Les soumissionnaires retenus pour l’un des lots de développement (lots 1, 2, 3 ou 4) ainsi que tout soumissionnaire intervenant comme membre d’une association sans personnalité juridique constituée pour l’exécution du présent marché ou comme sous-traitant d’un soumissionnaire des lots 1 , 2, 3 ou 4 seront de même écartés.


A 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. Le droit d’accès (voir point 5.1.1. Droit d’accès du volet C. « Attribution ») étant vérifié auprès de chaque membre de l’association, les capacités économique, financière et technique (voir point 5.1.2. Sélection qualitative du volet C « Attribution ») étant évaluées dans le chef de l’association.

Le SPF Finances attribuera d’abord les lots de développements (lots 1, 2, 3 et 4) puis le lot de testing (lot 5).

1.4.4. Collaboration entre les équipes de la composante « Développement et support » et celle en charge du « Testing » et le service de Gestion des Applications de l’Administration générale de la Fiscalité.

L'AG Fisc a développé une base de données en gestion propre dans SQL Server. Cette base de données appelée BDM (Business Data Management) est conçue comme une plateforme qui doit servir à la conservation claire et à un endroit unique de tous les lay-outs des applications opérationnelles. Le contractant s'engage à adapter les modifications qu'il apporte pendant sa mission aux lay-outs des tableaux ou aux fichiers de la base de données dans cette base de données BDM . Les droits d'accès nécessaires à cet effet lui seront accordés. Ainsi qu’indiqué plus haut, les travaux relatifs à la composante « Testing » (voir partie du cahier spécial des charges relative au lot 5) seront réalisés par une équipe distincte (interne ou externe au SPF Finances) et indépendante de l’équipe en charge des développements (lots 1 à 4). Dans un contexte impliquant les équipes de contractants différents, le SPF Finances souhaite naturellement qu’un mode de collaboration efficace soit mis en place et demande donc que des propositions soient faites en la matière. Les propositions seront jugées quant à leur qualité intrinsèque mais aussi quant à l’ouverture permise par le modèle proposé, s’agissant d’accorder les propositions des parties en présence pour chaque lot. Cette intégration 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 correspondante en matière de testing. Il est ici 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 testing et de 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 . Prise d’effet de la maintenance 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.


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


1.4.5. 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’applicatif

− Cycle de vie

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.

− Evolutions 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.

1.4.6. Modalités d’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.

1. Simultanéité des développements

Pour diverses raisons, notamment de respect des prescriptions légales, il est possible que les réalisations de certains projets se chevauchent, impliquant des pics en matière de charge de travail. Le soumissionnaire doit pouvoir faire face à ces fluctuations le plus souvent impératives.

2. Méthodologie FUP

La réalisation des projets devra suivre la méthodologie FUP. Toutefois, pour des raisons historiques, le niveau actuel d’intégration avec FUP peut différer d’une application à l’autre. Dans ce cadre, même si le projet/application n’en intègre pas la totalité des principes, le SPF Finances souhaite entamer un trajet visant l’intégration de la méthodologie. Si les objectifs précis en la matière seront fixés annuellement et par application/domaine, le soumissionnaire est invité à émettre des propositions en la matière et décrire les profils nécessaires pour ce volet.

3. Cycle de maintenance

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) :

− Phase d’initiation ;

− Phase préparatoire et de négociation ;

− Phase budgétaire (hors FUP) ;


− Phase de réalisation.

1.4.7. Transfert de connaissance

1. 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 (ex. MOSS). Dans ce cadre, les autres langues ne sont pas autorisées.

Le soumissionnaire décrira la méthode d'actualisation de la documentation. Le soumissionnaire s’engage à donner au SPF Finances un droit de regard sur la confection de la documentation durant l'exécution du projet. L’offre décrit comment le soumissionnaire voit cette possibilité.

Le SPF Finances peut copier les manuels pour les besoins de leur diffusion interne.

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

3.Continuité en cas d’arrêt d’un projet ou du programme

Le soumissionnaire doit prouver 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).

4.Continuité du service et pool de connaissances

Dans son offre, le soumissionnaire décrit les moyens et les mesures qu’il compte mettre en place pour assurer la continuité du service. L’on songe en premier lieu aux mesures internes que l’adjudicataire prendra pour installer un centre de compétence afin que les nouveaux membres de l’équipe puissent s’intégrer efficacement et rapidement 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 par ailleurs les connaissances et l’expérience qu’il peut mobiliser à tout moment pour exécuter le marché. 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).

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

6.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 en général à 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.


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

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, les formations, la répartition des tâches et le suivi et l’évaluation des compétences.


1.4.9. Personnel mobilisé par l’adjudicataire

Pour l’exécution des projets, le soumissionnaire doit proposer les profils de base via sa liste de prix (avec un prix par profil). Il précise les compétences de chaque profil. Les compétences décrites en annexe au présent cahier sont à considérer comme un minimum.

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 et mis en relation avec le présent marché, notamment les profils décrits en annexe 3. Une offre dont les CV ne permettraient pas de s’assurer de la complétude par rapport aux profils est susceptible d’être considérée comme irrégulière. L’expérience requise constitue à ce titre un critère absolu.

b) Etant donné le contexte bilingue dans lequel l’équipe de l’adjudicataire sera amenée à évoluer, le bilinguisme (FR/NL) de l’équipe est requis. A cette fin, il est attendu que minimum 80% de l’équipe ait pour langue maternelle le français ou le néerlandais et que ces deux langues nationales soient représentées dans 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.


2. Composante « Développement et Support » (Lots 1 à 4)

2.1. Missions

La mission principale sera de renforcer le département « ICT Development » du service d'encadrement ICT par l’apport d’équipes externes chargées afin d’organiser et d'exécuter d’une part les travaux de maintenance des applications de l’Administration Générale de la Fiscalité et d’autre part leur support opérationnel. Pour rappel, les aspects liés au testing, autres que ceux relevant du travail des développeurs, sont repris sous la responsabilité du lot 4.

Les lots 1 à 4 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 (y compris évidemment les tests unitaires et les tests d’intégration des composants)

� Intégration avec la partie « Testing » prévue au lot 5 (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

� Exécution des tests des composantes (unit tests)

� …


2.2. Mode d’exécution au sein d’un lot

2.2.1. Évaluation des services exécutés

Au moment où les services seront exécutés, une évaluation portera sur leur qualité et leur conformité. A cette fin, le service d’Encadrement ICT a mis en place au sein de son département Qualité un comité en charge (QUAC) de veiller au respect de ces aspects (respect des normes, qualité des livrables (documentation, code, …). Ce comité émettra, sous forme de procès-verbal, un avis lors de toute demande de réception (partielle ou totale) des prestations effectuées. Les services incorrects ou non conformes devront être corrigés préalablement à la soumission d’une nouvelle demande de réception.

2.2.2. Support technique par téléphone – service desk – ITIL

Les projets de maintenance comprendront un support par téléphone en 2ème 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 :

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

2.3. Profils

Rappel : le chapitre « Personnel de l’adjudicataire » détermine l’engagement de la firme quant au nombre minimum de personnes à garantir par profil (voir la table des capacités). 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 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. - le Lead Technical Architect / Methodologist : 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. - l'Analyste Business d’Application / Métier expert : 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. - le Designer / Data Architect expert, également appelé Analyste technique : notamment chargé - conformément à la discipline FUP-D3 ou autre méthodologie assimilée (au choix du SPF Finances) - de réaliser les spécifications des requirements (fonctionnels et non fonctionnels) et les modèles de données essentiellement dans le JEE. - le Développeur senior : 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 senior doit présenter les qualités suivantes : Composants et fonctions

Lecture / Passif Modification / Actif Architecture / Maîtrise sous jacente

Approfondi/Expertise Général/Approfondi Général/Approfondi Concepts/Général Un expert doit présenter les qualités suivantes : Composants et fonctions

Lecture / Passif Modification / Actif

Architecture / Maîtrise sous jacente

Expertise Expertise Expertise Approfondi Avec : Général = utilisation courante (des concepts principaux) Approfondi = utilisation autonome et spontanée (de concepts avancés) Expertise = compréhension naturelle et complète (de tous les concepts) Informations additionnelles sur les compétences et expertise Des compétences et expertises doivent être démontrées par CV. Selon le profil, elles sont classées en deux groupes : le groupe principal (minimum requis) et un éventuel groupe secondaire (atout). Le niveau Senior et une expérience d’au moins 6 mois doivent être couverts par les profils pendant toute la durée du contrat pour l’ensemble des disciplines listées du groupe principal. Les personnes concernées doivent être disponibles immédiatement en début de contrat. Des pénalités sont dues de plein droit en cas de non respect de cette disposition. Le niveau Senior doit être couvert par les profils dès la remise d’une offre impliquant une ou plusieurs des matières du groupe secondaire. Les personnes concernées doivent être disponibles au démarrage du projet. La date de démarrage probable est annoncée 15 jours calendrier à l’avance par une autorité du SPF Finances. Des pénalités sont dues de plein droit en cas de non respect de cette disposition. Dans le cas où la firme ne peut pas remplir ces obligations du point de vue du niveau de séniorité dans les matières nécessaires, une période d’on-boarding de deux mois est autorisée, pendant laquelle la firme s’engage à former (25 à 50% d’un ETP) le nouveau


membre d’équipe, et à le mettre à disposition du SPF Finances (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. Des pénalités sont dues de plein droit en cas de non-respect de cette disposition. Sauf exception dûment justifiée, les personnes dont les CV sont proposés dans l’offre doivent être présentes depuis au moins 6 mois dans l’entreprise. Compétences et expertise pour le profil Task Manager Un CV doit au minimum porter sur les matières suivantes (groupe principal), qui peuvent être détaillées selon la spécialité du profil :

- Java/JEE project management - Maven, Jenkins et autres technologie associées - RUP, UP - Scrum+XP - PRINCE2

Groupe secondaire :

- Redmine ou outil analogue - ITIL

Compétences et expertise pour le profil Lead Technical Architect / Methodologist

Un CV doit au minimum porter sur les matières suivantes (groupe principal), qui peuvent être détaillées selon la spécialité du profil :

- Java/JEE - Data Architecture - Web User Interface Design - Communication inter-applicative - JEE Architecture - Application Architecture - JSF1 et 2, STRUTS 1 et 2 - Maven, Jenkins et autres technologie associées - RUP, UP - UML and Patterns - Scrum+XP

Compétences et expertise pour le profil Analyste Business d’Application / Métier expert Un CV doit au minimum porter sur les matières suivantes (groupe principal), qui peuvent être détaillées selon la spécialité du profil :

- Analyse d’application Java/JEE - Analyse et conception de modèles de données - Analyse des Web User Interface - Analyse de la Communication inter-applicative - RUP, UP - UML - Scrum+XP - Analyse des Use Case


Compétences et expertise pour les profils Designer / Data Architect expert et Développeur senior

Un CV doit au minimum porter sur les matières suivantes (groupe principal), qui peuvent être détaillées selon la spécialité du profil :

- Java/JEE - DB2 developer - JSF1 et 2, STRUTS 1 et 2 - Maven, Jenkins et autres technologie associées - RUP, UP - Scrum+XP - UML + Patterns (développement)

: Groupe secondaire :

- .Net - COGNOS,DATASTAGE - PHP - COBOL,BULL,IBM - Delphi

3. Composante « Testing (Lot 5).

Le lot 5 du présent marché est relatif à des activités de tests spécifiques aux applications fiscales du SPF Finances.

3.1. Missions

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 des applications fiscales développées et maintenues par les équipes de développement au sein du SPF Finances. Il s’agit à travers ce lot 5 (Testing) de séparer les activités de tests des activités de développements des lots 1 à 4.

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 testing:

� 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) � Executer les tests de l’application complète (system test: performance, security,

functionality & user acceptance test) en collaboration étroite avec le service Gestion des Applications (Ag Fisc)

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

� …

3.2. Contexte.

3.2.1. Environnement organisationnel

3.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/


3.2.3. Environnement technique spécifique aux missions

3.2.3.1. Méthodologie 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. 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.

3.2.3.2. Arsenal des outils de test

3.2.3.2.1. HP ALM La version 11.0 de HP ALM (Application life cycle management) constitue le noyau de la gestion des tests. HP ALM peut reprendre aussi bien les requirements (et notamment les requirements modifiés ou les nouveaux requirements), les définitions de release, 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.

3.2.3.2.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 sur les loadtests et d'indiquer quelle est son approche dans ce domaine.

3.2.3.2.3. Compuware Dynatrace en 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 testtools comme HP ALM et HP Performance center.

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

3.2.3.2.5. Environnement de test On ne dispose cependant pas encore d’environnements de test pour certaines applications reprises dans le présent cahier 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. 3.3. Profils.

3.3.1. Profils testeurs et Quality Assurance Coordinator 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é.

3.3.1.1. Compétences communes Tous les profils des testeurs (P1-P4) proposés doivent répondre à 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.

À peine d’exclusion, les Quality Assurance Coordinators (P5) 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.


3.3.1.2. Profils spécifiques

3.3.1.2.1. Testeur (minimum 4 testeurs) 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.

3.3.1.2.2. Coordinateur de test (minimum 2 coordina teurs) Activités D’une part, le coordinateur de test sera responsable de l’exécution des activités primaires de test (préparation des tests, spécifications des tests, exécution des tests, rapportage et suivi des résultats). D’autre part, le coordinateur de test sera responsable de la coordination de l’équipe de test. Cela signifie avant tout que le coordinateur de test devra prendre en charge la planification des activités de test de l’équipe. Ensuite, le coordinateur de test doit également estimer les éventuels risques et, sur la base de son estimation des risques, déterminer la stratégie de


test. Enfin, le coordinateur de test déterminera aussi l’organisation de l’équipe et l’infrastructure de test nécessaire. Le coordinateur de test participera également aux réunions de coordination de projet importantes pour la planification de l’équipe de test. Le coordinateur de test peut faire des propositions concernant l'élaboration d'un master testplan. Le coordinateur de test veillera aussi à régulièrement faire les rapports nécessaires sur l’avancement des tests (“Test Progress Report”). Profil Le coordinateur de test est capable d'identifier les opportunités et d’agir ou de faire des propositions quand ces opportunités se présentent. Ce n’est pas quelqu’un qui attend passivement mais bien quelqu’un qui entreprend lui-même des actions. De plus, le coordinateur de test devra être capable de continuer à fonctionner de manière efficace dans les situations difficiles, sous pression élevée (au niveau du temps) et face à la résistance et aux oppositions. Enfin, le coordinateur devra être capable de fixer les objectifs et les priorités de l’équipe. Cela signifie que le coordinateur devra être capable d’estimer correctement le temps, d'identifier les ressources adéquates et d'organiser les bonnes activités pour atteindre les objectifs fixés. Le coordinateur de test suivra l’avancement du projet et – le cas échéant – prendra des mesures correctives. À côté de cela, le coordinateur déléguera correctement les responsabilités et les tâches aux autres, en tenant compte de leurs possibilités, de leur disponibilité et de leurs intérêts.

3.3.1.2.3. Spécialiste en outils de test (minimum 2 spécialistes en outils de test) 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.


3.3.1.2.4. Spécialiste en méthodologie de test (min imum 2 spécialistes en méthodologie)

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

3.3.1.2.5. Quality Assurance Coordinator (minimum 4 profils de Quality Assurance Coordinator)

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 :

� Documenter le review des deliverables: voir FUP et TMv4; � Contrôler l’utilisation correcte des outils (HP ALM, Continuous Integration, …): voir

FUP et TMv4; � 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-2-3 et les activités de testing du lot 5;

� … 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-2-3-4 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 projet : 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.


4. SLA.

4.1. Introduction L’administration souhaite conclure un Service Level Agreement (SLA) ou contrat de niveau de service pour chaque lot de ce marché. Le SPF Finances accorde une grande importance aux SLA qu’il demande. Les SLA permettent en effet de surveiller les objectifs et les risques pour l’organisation liés aux services demandés. Ces SLA comprennent un tableau avec les délais dans lesquels les SLA respectifs sont valables. Après l’attribution du marché et jusqu’à l’échéance de la période d’exploitation, l’entrepreneur s’engage à respecter les niveaux de service (service levels) et les engagements de résultats fixés par les SLA qui figurent dans ce cahier des charges. 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, éventuellement complétés par des niveaux de service supplémentaires proposés par le soumissionnaire, produiront ensemble le MASTER SLA pour chaque lot de ce cahier des charges. Vu la spécificité du marché, à savoir un plan de maintenance annuel et d’éventuelles missions complémentaires sur la base de projets, l’approche suivante a été choisie :

• le MASTER SLA est valable de manière générale ; • des exigences spécifiques et d’éventuelles modifications convenues, autorisées, par

rapport au MASTER SLA en matière de services pour les nouveaux projets figureront dans un SLA spécifique qui sera joint au MASTER SLA sous la forme d’une annexe distincte.

Le MASTER SLA à proposer 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. Les SLA seront élaborés dans ce cadre. 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. Remarque générale : si le soumissionnaire soumet une offre pour plusieurs lots, il peut formuler une proposition de SLA pour les différents lots de son offre ; en cas de différences pour chaque lot, il devra cependant l’indiquer clairement dans son offre.

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


Documents à introduire obligatoirement avec l’offre :

1. SQP & SIP

2. Concept MASTER SLA (conforme au modèle SLA en an nexe 4)

3. DAP

4. Exemple de rapport

5. Tableau KPI rempli (conformément au tableau des KPI en format A3 en annexe 4 de ce cahier des charges)

a. Pour le tableau KPI, il faut à côté de la versio n papier ou digital, aussi introduire une version électronique en format Excel dans l’offre ;

b. Seule la dernière colonne doit être remplie au c as où des amendes plus élevées sont proposées ;

c. Les (valeurs des) autres colonnes ne peuvent êtr e modifiées ;

4.2.Principe d’élaboration des SLA dans le cadre de ce marché et deliverables correspondants

4.2.1.Concept de MASTER SLA - template SLA SPFFIN En annexe 6 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, 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. Outre les éléments standards du ou des SLA que le soumissionnaire doit présenter, les niveaux de service et les engagements de résultats que le SPF Finances demande dans le cahier des charges doivent y être notamment détaillés. Comme déjà indiqué, le soumissionnaire est libre :

• d’ajouter des points individuels complémentaires, comme des services levels supplémentaires ou des normes de service assortis d’exigences de performances et d’indicateurs de performances correspondants ;

• 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 6).

4.2.2. Projet de « Dossier Accords et Procédures (D AP) » – contenu En complément à un concept MASTER SLA, le soumissionnaire doit é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 incidentielles 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)

� Incident Management ; � Problem Management ; � Change Mangement ; � Release Management ; � Configuration Management ; � Remarque : le service desk en fait également partie.

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


Cette première version du projet de DAP sera obliga toirement jointe à l’offre (voir critères d’évaluation). Elle doit permettre à la commission d’évaluation d’évaluer le projet de DAP proposé. Remarque pratique : Pour éviter le dédoublement du travail, un point peut figurer soit dans le MASTER SLA soit dans le DAP avec une référence claire au paragraphe concerné. Ex. les processus et procédures figurant dans le SLA peuvent renvoyer aux procédures détaillées dans le DAP.


4.2.3.Projet de tableau de KPI avec clauses d’amend e

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 à l a fois les KPI et les indicateurs de performance (IP) et normes de performance correspon dants. Une clause d’amende figure également dans le tableau pour certaines nor mes IP. C’est l’amende qui est infligée par le SPF Finances en cas de non-respect des normes définies dans le tableau. Le soumissionnaire est libre de proposer d es amendes plus élevées (critères d’évaluation). Cette première version de ce projet de tableau de K PI avec clauses d’amende doit obligatoirement être jointe à l’offre (voir critère s d’évaluation). Elle doit permettre à la commission d’évaluation d’évaluer le projet de tabl eau de KPI proposé.

4.2.4.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. Le soumissionnaire joindra une proposition de modèle à son offre.

4.2.5.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 des normes de service. 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é.

4.2.6.Service Improvement Plan (SIP) – Plan d’améli oration 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é.

4.2.7.Service Level Management Le soumissionnaire décrira dans son offre la manière dont il organisera le processus de Service Level Management (SLM). Ce processus garantit la bonne gestion des produits et services à fournir, par la définition, la négociation, le mesurage, le rapportage, la maîtrise et l’amélioration à des coûts justifiés. Il tiendra également compte des aspects qualitatifs, quantitatifs et budgétaires. Ceci dans un contexte d’évolution constante des besoins, exprimée dans les processus opérationnels et compte tenu de l’évolution constante des technologies de support.


L’entrepreneur désignera formellement un Service Level Manager qui soutiendra ce processus pendant toute la durée du projet. Le coût des tâches à exécuter sera compris dans la gestion du projet. Pour de plus amples informations, voir : http://en.wikipedia.org/wiki/ITIL#Service-level_management

4.2.8.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. 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 établir, implémenter, exploiter et rectifier tous les documents nécessaires (MASTER SLA, DAP, tableau des KPI…) ainsi que les procédures et processus correspondants durant toute la durée de ce marché.

4.3.Encadrement SLA

4.3.1.Relation entre SLA et ITIL© V3-2011 – Glossar y 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

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.

4.3.2.Relation entre les SLA et les normes et fonde ments ICT du SPF Finances. Les normes et fondements ICT du SPF Finances sont publiés en ligne sur les sites Web suivants :

• Néerlandais

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. 5 « Copyright © AXELOS Limited 2012. All rights reserved. Material is reproduced with the permission of AXELOS »


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/

4.3.3.Gestion et contrôle des 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.

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. Developement (FUP D4) 4. Testing (FUP D5 + TMv4, voir aussi lot 5)

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

1. Requirements Review: la validation des requirements en concertation avec le business. L’adjudicataire des lots 1, 2, 3 et 4 décrira l’approche qu’il utilisera dans la review afin d’identifier et de valider les 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, 2, 3 et 4 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, 2, 3 et 4 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 5 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 5.

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 deliverables FUP, tools FUP…). Ils devront donc également être intégrés dans les approches des reviews demandées dans ce paragraphe.


4.3.5.Environnements à supporter dans le cadre de c es SLA

Les environnements dans lequel 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 : développement • À : acceptation • T : test • P : production

4.4.Service Levels et engagements de résultats corr espondants 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 5 Testing. Ces 7 SLA et engagements de résultat sont décrits dans les sections suivantes.


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

4.5.1.PI-Project-bid-delivery-period

4.5.2.PI-Bid-Completeness

4.5.2.1.Composition minimale du lot -1-2-3-4-5 Liste non limitative : à préciser après adjudication du marché en concertation avec l’entrepreneur.

• Plan du projet avec phases, milestones • Estimations des ressources, délais • Deliverables à receptioner • Services à receptioner • Proposition financière • Analyse des risques • Analyse d’impact

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

4.5.2.2.Description

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

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 après du SPF FIN

Tous les éléments sont repris. Formule de calcul Nombre d’offres complètes, 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 doivent être complètes sur base trim estrielle.

Sur cette base, le SPF FIN a le droit de refuser l’ offre de l’entrepreneur ou de demander des


4.5.3.PI-Project Plan-Planning

4.6.Niveaux de service phase de développement : co nformité à la méthodologie FUP, aux standards ICT et qualité du c ode L’entrepreneur 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 ;

• l’utilisation correcte des outils prescrits par la méthodologie FUP.

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

6 Architecture Builing Blocks , voir aussi paragraphe Relation entre SLA et standards et fondements ICT du SPF Finances 7 Vu la durée du contrat-cadre, ces principes et critères pourront être adaptés aux nouvelles évolutions et découvertes technologiques.

informations complémentaires.

Objectifs Définition Le respect du planning préétabli pour tous les projets en cours que l'entrepreneur doit exécuter

officiellement. À la fin de chaque mois, l’entrepreneur transmettra le statut du planning dans le rapportage par le biais d’un graphique de Gantt. 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 biais d’un éventuel graphique de Gantt du projet)

Formule de calcul • Date de réception – date de demande Période de calcul • Sur base annuelle, le statut des retards de tous les projets en cours est établi. Par

principe, sur la base du graphique de Gantt du projet qui est revu chaque mois par le chef de projet.

• L’évaluation définitive se fait annuellement. Résultat à atteindre

90% des projets attribués à un entrepreneur durant l’année en cours peuvent avoir un

retard max. de 10 jours ouvrables.


• 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 au 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%.

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

4.6.1.PI-FUP-deliverables

4.6.2.PI-FUP-tools & ICT- standards

Objectifs Définition Les deliverables FUP doivent être livrés complets et dans les délais. La liste exacte des

deliverables FUP à livrer sera fixée au début de chaque marché.

Méthode de mesure La date à laquelle la version finale des deliverables 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 li vraison.

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

Méthode de mesure Contrôle qualité par le SPF FIN ou une partie tierce à la demande 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.


4.6.3.PI-Quality-of-Code

4.6.4.PI-Security-Integrity-Code

4.7.Service levels mise en production 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.

4.7.1.PI-Continuous-Integration-Tool-Chain

Période de calcul Trimestrielle Résultat à atteindre

Les non-conformités constatées doivent être résolue s dans un délai de max. 10 jours

ouvrables.

Objectifs Définition La première version satisfera aux normes fixées pour la qualité du code. Ces normes seront

détaillées au début du marché. L’adjudicataire doit les traiter dans le plan de qualité du code (voir FUP D4).

Méthode de mesure Date de livraison de la version figurant dans Delivery Management Formule de calcul Nombre de versions qui satisfont aux critères/nombre total de versions Période de calcul Trimestrielle Résultat à atteindre

Si une ou plusieurs normes de qualité du plan quali té n’ont pas été respectées après la

livraison d’une version donnée, cela devra être cor rigé 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)

Période de calcul Trimestrielle

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.

Période de calcul Trimestrielle Résultat à atteindre

Aucune version ne peut être livrée sans utilisation correcte de la Continuous Integration

Tool Chain.


4.7.2.PI-Releases-in-production

4.8.Service levels exigences non fonctionnelles

4.8.1.PI–Availibility-7x24x365 et PI-Availibility-5 x12 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 l’environnement pour lequel la disponibilité IP est valable.

4.8.1.1.Périodes d’ouverture du service (service wi ndow) 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.

4.8.1.2.Service Windows par catégorie d’application s Le SPF Finances prévoit actuellement deux catégories d’applications pour lesquelles des indicateurs de performance de disponibilité sont prévus.

Application Service window:

7x24x365 Service window:

5x12 Lot 1 (Développement et support) : Domaine

TVA Intervat x STIR-TVA x

Stiron TVA (sauf VIES) x

Stiron TVA VIES x MOSS (Mini One Stop Shop) X

Lot 2 (Développement et support) : Domaine impôts directs personnes physiques (IPP + INR PP)

Belcotax-on-Web (BOW) x Tax-On-Web (TOW) x

Objectifs Définition La première 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 Période de calcul Trimestrielle Résultat à atteindre

Max. 10%


Taxi x Proposition de Déclaration

Simplifiée (PDS) x

Calculatrix IPP x Lot 3 (Développement et support) : Domaine

impôts directs personnes morales + recherches, précompte et contrôle

Biztax : Module Font-Office (FO) x Biztax: Modules Back-Office (BO) et

Dossier Unique (DU) x

Stir-Contrôle x

Stir-Recherche x

PRM-on-web x Calculatrix ISOC x FINELTS X

Lot 4 (Développement et support) : Domaine transnational

STIRint X FATCA x Aut_DT x

Service window 7x24x365 Les applications sont disponibles 24 heures sur 24, 7 jours sur 7, tous les jours de l’année, à l’exception des week-ends de maintenance trimestriels prévus et des périodes d’intervention convenues à l’avance – et c onfirmées par le SPF Finances. 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. Service window 5x12 Les applications sont disponibles les jours ouvrabl es officiels du SPF Finances, de 07h00 à 19h00, cinq jours sur sept, du lundi au ven dredi, à 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).


4.8.1.3.Normes PI–Availibility-7x24x365 et PI-Avail ibility-5x12

4.8.1.4.Clauses d’amende PI–Availability La disponibilité et les clauses d’amende 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.

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.

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’entrepreneur (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 10min qui contrôle les fonctionnalités précitées.

Période de calcul • La disponibilité est calculée et rapportée tous les 6 mois. Des actions correctrices sont mises en place en fonction de ces chiffres.

• L’évaluation définitive se fait annuellement.

Résultat à atteindre

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

99,50% de disponibilité trimestrielle pour

chaque application (version) en production

de l’adjudicataire.

99,50% de disponibilité trimestrielle pour

chaque application (version) en production

de l’adjudicataire.

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. Si nécessaire, des actions

correctrices sont mises en place en fonction de ces chiffres.


• L’évaluation définitive se fait annuellement. Résultat à atteindre

P. ex. X % < Y secondes

Normes à définir en concertation après exécution des tests de performance individuels requis

après l’attribution du marché.


4.9.Service Levels en matière de traitement d’incid ents, d’interventions correctrices et réactives

Ce SLA aura notamment trait : • à la disponibilité du help desk de 2 e ligne de l’entrepreneur 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 « niv eaux de priorité pour les actions correctrices et réactives »).

La disponibilité du help desk et la réactivité de l’entrepreneur 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. En dehors de ces heures, l’adjudicataire organisera un help desk de deuxième ligne pour la Service window 7x24x365 pour les applications e-Gov.

• À 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).

• Pour chaque incident constaté, quelle qu’en soit la nature, le SPF Finances complétera une fiche d’incident et la remettra à l’entrepreneur. Cette fiche permettra de suivre la résolution de l'incident et sera à la base du contrôle de la qualité des prestations fournies. Cette fiche sera codée dans un système de suivi des incidents qui est à la disposition l’entrepreneur. Sur cette fiche, l’entrepreneur 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.

4.9.1.Priorités des incidents Priorités des incidents pour les interventions corr ectrices 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 – Minor incident ou service request, impact single business user.


Pas d’impact business ou problème fonctionnel minime. Toutes les requests ou les tickets de plainte du business.

Remarque : Les incidents peuvent être notifiés manu ellement via le help desk du SPF Finances ou automatiquement par le système de monitoring du SPF FIN.

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

Urgency Low Average High Critical

Impact

Low Risk 4 4 3 3

Moderate Risk 4 3 3 2

High Risk 3 3 2 2

Very High Risk 3 2 2 1 Définitions d’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’Urgency

• 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


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.

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 Si le SPF Finances constate qu’une solution x proposée ne résout rien dans la pratique, le moment de proposition de la solution x n’est pas considéré lors du calcul de ce KPI.

Objectifs Définition Effectuer un retour sur la base d'un incident notifié par le Help desk avec:

• un (premier) contrôle de l’exhaustivité de l’incident notifié • un (premier) contrôle de l’exactitude du transfert

Méthode de mesure

Via l’outil help desk SPF Finances

Formule de calcul Moment de notification de l’incident par le SPF FIN – moment d’acception du ticket par le groupe de support de l’entrepreneur

Période de calcul trimestrielle Résultat à atteindre

Priorité 1 100 % dans 15min après attribution de l’incident au groupe de support de l’entrepreneur



Priorité 4 100 dans 30min après attribution de l’incident au groupe de support de l’entrepreneur

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

Par l’outil de help desk du SPF Finances et le système de traitement d’incidents de l’entrepreneur

Formule de calcul Moment d’enregistrement “incident resolved”8 dans l’outil de help desk du SPF Finances – 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 de l’entrepreneur


4.10.Service Levels concernant les services du pers onnel mis à disposition par l’entrepreneur

4.10.1.PI-BID-Reactiveness

4.10.2.PI-Staff-Timesheet

Remarque : Dans ses timesheets, l’entrepreneur indi quera clairement les heures réellement prestées avec heure de début et de fin, compte tenu des pauses légales

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

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

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

• Retour des incidents :

o Toutes les 2 heures de travail pour les incidents de priorité 1



• 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 Manuel Formule de calcul Nombre de jours ouvrables entre la réception du bon de commande et la réponse de la société Période de calcul Début du projet Résultat à atteindre Max. 10 jours ouvrables

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’entrepreneur et celui du SPF Finances

Formule de calcul Date de remise – 1er jour ouvrable du mois Période de calcul Trimestrielle Résultat à atteindre

Dans les 10 jours ouvrables à partir du 1 er jour ouvrable du mois, 90% de tous les

timesheets pour tous les projets en cours pour l’en trepreneur.


prévues qui ne peuvent pas être intégrées aux prest ations fournies. Le nom de la personne (et éventuellement son profil) qui a effec tué les prestations sera indiqué, ainsi qu’une brève description des prestations effe ctuées.

Si un pool de prestations prévues est utilisé, les prestations qui restent à effectuer seront mentionnées sur le timesheet.

4.11.Service Levels concernant le lot 5 testing.

4.11.1.Aperçu Les KPI pour le lot 5 « 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-Test execution ratio � PI-Actualized-testing-effort- burn- down-rate (mananagement 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

4.11.2.KPI Test project

4.11.2.1PI-Test-execution-ratio

Objectifs Définition Avancée de la phase d’exécution du test en termes de test cases exécutés.

Méthode de mesure Test case en HP ALM Formule de calcul Nombre de test cases exécutés/Nombre de test cases préparés

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

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


4.11.2.2.PI-Actualized-testing-effort- burn- down-r ate (management KPI)

4.11.3.KPI’s Test Quality

4.11.3.1PI-Test-execution-coverage

4.11.3.2.PI-Test-build-coverage

4.11.3.3.PI-Defect-detection-ratio

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

Objectif s 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) Période de calcul En fonction de la période de test

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

Méthode de mesure Dans HP ALM Formule de calcul Nombre d’exigences (requirements) couvertes / nombre d’exigences (requirements) Période de calcul En fonction de la période de test

Résultat à atteindre Min. 90%

Objectifs Définition Défauts manqués durant l’exécution du test qui passent dans la production. Mesurées 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


4.11.4.KPI testing process performance

4.11.4.1.PI-Test-efficiency

4.11.4.2.PI-Test-case-automation

4.12.Périodes d’application des différents SLA

Service Levels Période de validité

Environnements

1. Service Levels concernant la gestion de projets

Dès l’attribution D-A-T-P

2. Services Levels phase de

développement

De l’attribution à la mise en production

D-A-T-P

3. Service Levels 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

A partir de la mise en production

P

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

A partir de la mise en production

P

6. Service Levels concernant les Dès l’attribution D-A-T-P

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 Période de calcul En fonction de la période de test

Résultat à atteindre Min. 90%

Objectifs Définition

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

Méthode de mesure Dans HP ALM Formule de calcul Nombre de test cases automatisés/ nombre de test cases préparés Période de calcul En fonction de la période de test

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


services du personnel mis à disposition par l’entrepreneur 7. Service Levels concernant le lot 5 testing.

Dès l’attribution T

4.13.Sanctions Le non-respect d’un élément déterminé du SLA est sanctionné d’une amende. 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.

4.13.1.Principe des propositions d’amendes Le SPF Finances impose des amendes standard pour la majorité des service levels. Le soumissionnaire peut proposer des amendes supérieures. Toutes les amendes proposées doivent être reprises dans le tableau de KPI. Ce montant de base pour le calcul des amendes reste d’application durant toute la durée du contrat, sauf si un montant supérieur a été proposé par le soumissionnaire : dans ce dernier cas, le montant supérieur est d'application. Les amendes proposées sont un critère d’évaluation.

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

4.14. SLA monitoring, rapportage et analyse, Concer tation du Service Management

4.14.1.SLA-monitoring

4.14.1.1.Monitoring de base 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

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’entrepreneur pour les traiter dans le rapportage SLA à fournir chaque mois. 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’entrepreneur se déclarera d’accord avec cette méthode de travail pour mesurer la disponibilité. Avec l’équipe de monitoring, l’entrepreneur 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.

4.14.2.Rapportage SLA, Reviews, IP-SLR

4.14.2.1.Rapportage Service Level (SLR) général Ce rapportage service level (SLR) a trait aux activités sous-traitées à l’entrepreneur 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 mois ou trimestre :

L’entrepreneur 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

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


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’entrepreneur é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). Si nécessaire, une réunion SLA mensuelle est organisée « by exception ». 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’o ffre de sorte que la commission d'évaluation puisse l'évaluer (sous-critère). Le rapportage SLR utilisera un maximum de tableaux récapitulatifs et de représentations graphiques.

Le document SLR présenté contiendra au moins les sujets suivants (liste non limitative) : 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. Request For Changes pendant 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.

4.14.2.2.PI-SLR

4.14.2.3.Concertation Service Management Cette concertation a lieu comme indiqué dans la matrice ci-dessous :

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


Nom

Fréquence

Personnes présentes

Sujets

Concertation de direction

1 * par an

• Délégation ICT Management

SPF FIN • Délégation Management

entrepreneur • Quality Management SPF FIN

• Service Management entrepreneur

• Monitoring contrat et collaboration • Développements • Escalade pour la Concertation de

Service Level

Concertation de Service Level

1 * par trimestre

• Quality Management SPF FIN

• Service Management entrepreneur

• 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é entrepreneur

• Intake nouveaux marchés • Priorités

• Plaintes et améliorations • Escalade pour Concertation sur le

fond

Concertation sur le fond (non formalisée)

Ad hoc • Incident management

• Gestion quotidienne • Sur le fond : exécution des flux de

travail • Points noirs, améliorations

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

4.15.Autres Service Levels, obligations de résultat s et conclusion Le soumissionnaire peut également proposer un service level avec engagements de résultats pour d’autres aspects qu’il juge pertinents dans le cadre du présent cahier spécial des charges. Dans son offre, le soumissionnaire doit dès lors déterminer le niveau de service qui doit être atteint, outre les outils et les périodes de mesure, ainsi que la méthode de rapportage.

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.


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


ANNEXES

1. Formulaire d’offre

2. Modèle de référence

3. Curriculum vitae (annexes 3.a. et 3.b.)

4. SLA à compléter

5. Description des applications

6. SLA Template


ANNEXE 1 : FORMULAIRE D’offre SERVICE PUBLIC FEDERAL Finances

Service d’Encadrement Logistique Division Achats

North Galaxy – Tour B4 – bte 961 Boulevard du Roi Albert II, 33

1030 BRUXELLES

CAHIER SPECIAL DES CHARGES N° : S&L/AO/386/2014

La firme:

(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/Madame 9

(nom)

(fonction) domicilié(e) à l’adresse:

(rue)


(pays)

agissant comme soumissionnaire ou fondé de pouvoirs et signant ci-dessous, s’engage à exécuter, conformément aux conditions et dispositions du cahi er spécial des charges n° : S&L/AO/386/2014, les services définis aux prix forfaitaires unitair es mentionnés ci-après, indiqué en lettres et en chiffres, libellés en EURO, hors TVA et TVA compris e, de :

9 Biffer la mention inutile

Appel d’offres ouvert pour la Maintenance des appli cations de L’Administration Générale de la Fiscalité (SPF Finances).


Lot 1

PROFIL

Prix unitaire hors TVA / PAR JOUR-HOMME

en Euro (en chiffres et en lettres)

Prix unitaire TVA comprise- PAR JOUR-

HOMME en Euro

(en chiffres et en lettres) Task Manager

Lead Technical Architect / Methodologist

Analyste Business / Métier expert

Designer / Data architect expert

Développeur senior

Lot 2

PROFIL




HOMME en Euro





Développeur senior


Lot 3

PROFIL




HOMME en Euro





Développeur senior

Lot 4

PROFIL




HOMME en Euro





Développeur senior


Lot 5

PROFIL




HOMME en Euro

(en chiffres et en lettres) Testeur

Coordinateur de test

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 o ffre :

LOTS SOUMISSION (OUI/NON)*

Lot 1 : Développement/support opérationnel des applications de l'Administration Générale de la Fiscalité - Domaine TVA

Lot 2 : Développement/support opérationnel des applications de l'Administration Générale de la Fiscalité - Domaine Impôts des Personnes Physiques

Lot 3 : Développement/support opérationnel des applications de l'Administration Générale de la Fiscalité - Domaine Impôts des Personnes Morales (Impôt des Sociétés, Impôt des Personnes morales et Impôt des Sociétés non résidentes) et domaine transversal

Lot 4 : Développement/support opérationnel des applications Transnationales

Lot 5 : Test des applications de l’administration générale de la fiscalité


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’Etat. En cas d’approbation de la présente offre, le cautionnement sera constitué dans les conditions et délais prescrits dans le cahier spécial des charges. L’information confidentielle et/ou l’information qui se rapporte à des secrets techniques ou commerciaux est clairement indiquée 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

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)


(n° de � et de �)

(adresse e-mail)

Fait: A Le 20….. Le soumissionnaire ou le fondé de pouvoirs :

(nom)

(fonction)

(signature)

APPROUVE,

10 Biffer la mention inutile


POUR MEMOIRE: DOCUMENTS A JOINDRE OBLIGATOIR EMENT A L’OFFR E: - Tous les documents et renseignements demandés dans le cadre de la sélection

qualitative et des critères d’attribution (voir poi nt 5 du volet C. Attribution) ; N’oubliez pas de prévoir une numérotation continue de toutes les pages de votre offre, ses annexes.

L’ordre de préférence des lots est : LOTS Priorité du lot

Indiquer par un chiffre (1, 2, 3, 4 ou 5) votre priorité (un seul chiffre différent par lot).

Lot 1 : Développement/support opérationnel des applications de l'Administration Générale de la Fiscalité - Domaine TVA

Lot 2 : Développement/support opérationnel des applications de l'Administration Générale de la Fiscalité - Domaine Impôts des Personnes Physiques

Lot 3 : Développement/support opérationnel des applications de l'Administration Générale de la Fiscalité - Domaine Impôts des Personnes Morales (Impôt des Sociétés, Impôt des Personnes morales et Impôt des Sociétés non résidentes) et domaine transversal

Lot 4 : Développement/support opérationnel des applications Transnationales

Lot 5 : Test des applications de l’administration générale de la fiscalité


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

1. Nom du projet ……………………………………………………………………. 2. Nom de l’entreprise ……………………………

3. Secteur d'activité

……………………………………………………………………. 4. Nom du contact ……………………………

5. Coordonnées

……………………………………………………………………. 6. Portée du développement ou du projet ……………………………

7. Buts poursuivis

……………………………………………………………………. 8. Date de début (par phase) - …………………………… - ……………………………

9. Date de fin ……………………

10. Budget (EUR) ……………………………

A. Matériel ……………………

B. Logiciels ……………………

C. Services ……………………

11. Résumé et brève description du rôle et de la part des éventuels sous-traitants

A. Nom de la ou des entreprises ……………………

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 respecteront pas les règles ci-dessus et de ne pas les prendre en compte dans l'évaluation de l'offre.

Si les diplômes mentionnés ne correspondent pas à l a réalité, le pouvoir adjudicateur se réserve le droit d'exclure l'offre.

Nom …………………………………………………… Fonction dans le projet : …………………………………………………… …………………………………………………… …………………………………………………… Description de la pertinence du profil pour le marché : Le soumissionnaire explique de la façon la plus détaillée possible pourquoi le profil en question est utile dans le projet. Formations : Humanités ou équivalent :

• Diplôme obtenu le (date) …………………………………………………… Enseignement supérieur non universitaire (répéter si nécessaire) :

• Titre …………………………………………………… • Diplôme obtenu le (date) …………………………………………………… • Institution ……………………………………………………

Enseignement supérieur universitaire (répéter si nécessaire) :

• Titre …………………………………………………… • Diplôme obtenu le (date) …………………………………………………… • Institution ……………………………………………………

Expérience professionnelle : Chez le soumissionnaire :

• Fonction actuelle o Titre …………………………………………………… o Description de fonction …………………………………………………… o Depuis le ……………………………………………………

• Fonction précédente (répéter si nécessaire) o Titre …………………………………………………… o Description de fonction ……………………………………………………

Du ……….…..……… au …………..………. • Participation aux projets suivants visés à l'annexe « modèle de référence » (projet et fonction)

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

• Participation à d'autres projets importants (nom, client et fonction assumée)


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

Dans trois autres entreprises au maximum :

• Fonction (répéter 3 fois maximum) ……………………………………………………

Du ……….…..……… au …………..………. Compétences techniques :

• Matériel (hardware) …………………………………………………… ……………………………………………………

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

Autres compétences :

• En management …………………………………………………… • En consultance …………………………………………………… • Autres (seulement si pertinent) ……………………………………………………

Connaissance des langues : • Français : compréhension - actif - passif (biffer les mentions inutiles)

commentaires …………………………………………………… • Néerlandais : compréhension - actif - passif (biffer les mentions inutiles)

commentaires …………………………………………………… • Anglais : compréhension - actif - passif (biffer les mentions inutiles)

commentaires …………………………………………………… • Autres (seulement si pertinent) ……………………………………………………


ANNEXE 3.B.: Curriculum vitae - SYNTHESE

Le soumissionnaire doit également remettre un tableau de synthèse des CV. Ce tableau de synthèse de tout CV est formaté de la manière suivante : Nom : Matière 1 Niveau d’expertise de la

matière 1 Nombre de mois d’expérience et pratique effectifs dans la matière 1

… …


ANNEXE 4: SLA a completer Le SLA à compléter ce trouve dans le fichier joint sous format XLS. Dans l’offre, ce dernier doit être rempli dans le fichier joint.


ANNEXE 5 –DESCRIPTIF DES APPLICATIONS

Lot 1 (Domaine TVA)

INTERVAT STIR-TVA STIRON-TVA MOSS (Mini One Stop Shop)

I. INTERVAT

a. Description fonctionnelle

Introduction L’application Intervat est le point d’entrée (e-Service) exclusif du SPF Finances pour la plupart des déclarations à la TVA et a été rendue obligatoire – sauf rares exceptions – pour tous les déclarants. Les déposants peuvent ainsi effectuer le dépôt signé et sécurisé de déclarations par voie électronique, soit manuellement, soit à l'aide de fichiers XML, et suivre le cycle de dépôt jusqu’à l’accusé de réception. INTERVAT implémente la législation belge et européenne en matière de TVA. Comme tout e-Service, Intervat est accessible via un portail où sont décrites de nombreuses informations utiles à propos de l’application, et à partir de laquelle il est possible de tester l’application. Le portail spécifique à Intervat se trouve à l’URL suivant : http://www.minfin.fgov.be/portail2/fr/e-services/intervat/index.htm

Acteurs Il y a deux principaux types d’acteurs :

- les utilisateurs externes : ce sont les déposants (susmentionnés). Ils peuvent notamment déposer en leur nom ou pour des tiers (nommés déclarants).

- les utilisateurs internes : ce sont des fonctionnaires. Ils peuvent notamment déposer pour des tiers, ou accéder à la recherche intégrale.

Certains utilisateurs internes ont accès à des parties de l’application qui fournissent des statistiques ou permettent de modifier certaines règles de dépôt.

Composition Intervat est composé des composants ou modules fonctionnels suivants, relatifs chacun à un type de déclaration séparé : Composant Couverture fonctionnelle. TVA Déclarations périodiques à la TVA. LK Listings clients. ICO Relevés intracommunautaires. VR Demandes de remboursement Vatrefund. Prorata Communication du prorata définitif pour une déclaration Vatrefund MTN Relevés de livraisons intracommunautaires des moyens de transport

neufs. 629 Déclaration TVA spéciale 629 (article 53 ter du code TVA) pour les

personnes qui ne déposent pas de déclarations périodiques mais qui sont redevables de la taxe conformément à l’article 51§1, 2° en §2 du code TVA.


MOSS Régime particulier pour les assujettis qui ne sont pas enregistrés dans 1 ou plusieurs Etats membres dans lesquels ils ont effectué certains services pour le compte de non-assujettis. Le module MOSS comprend 2 volets : 1) enregistrement et 2) déclaration.

A cette liste, il faut ajouter les modules « de gestion » suivants qui ne sont accessibles que via la version intranet d’Intervat (appelée Intervatconsult – voir plus loin) : dont l’objet est : Gestion La gestion des règles de déclaration Statistiques la production de Statistiques sur les envois par type de déclaration Administration Fonctionnalité qui permet de joindre une communication pour l’utilisateur

d’Intervat Un dépôt est défini comme l’opération par laquelle l’utilisateur fait le dépôt d’une ou plusieurs déclarations et de leurs annexes. Un envoi est défini comme la réalisation complète d’un dépôt. Dans ce texte, Envoi et dépôt peuvent être considérés comme synonymes dans la plupart des cas. Schéma d’Intervat

Soumission

d’une ou

plusieures

déclarations

Création via l’interface

Web, suivi de l’envoi (1

déclaration)

Ou chargement et

envoi d’un fichier XML

(1 ou plusieurs

déclarations)

Validation

Par rapport au schéma

XSD

Et contrôle du n° TVA

(BTWSigna ou format

pour non BE)

Et règles spécifiques par

type de déclaration

Stockage du

message +

quelques attributs

Envoi STIR

STIR-TVA pour les

déclarations

périodiques, listings

clients, relevés

intracommunautaires

et déclarations 629

STIRINT pour MTN,

VatRefund et Prorata

Réception et

stockage de la

réponse de STIR

Génération

accusé de

réception

Requirement non fonctionnels

Disponibilité Intervat est une application hautement critique, dont la haute disponibilité (7j/7 24h/24) doit être assurée, impliquant une réactivité de la part de la firme à apporter en cas de défaillance système.


Volumes et débits Le volume de transactions suivant a été mesuré (un seul envoi peut contenir plusieurs documents) : Type de déclaration

Nombre d'envois en 2012 Pics de déclaration (envois)

TVA 2.633.647 Pic trimestriel (janvier, avril, juillet, octobre ) de 380.000 - 400.000 envois

LK 540.838 Echéance fin mars : +/- 300.000 envois en mars

ICO 532.779 Pic trimestriel (janvier, avril, juillet, octobre) de 60.000 - 68.000 envois

VR 29.283 Échéance fin septembre : +/- 5.000 envois en septembre

MTN 1.213 Déclaration trimestrielle (janvier, avril, juillet, octobre)

PR 39

Le volume de transaction suivant est une estimation des volumes futurs : Type de déclaration

Nombre de déclarations (envois)

Picsde déclaration (envois)

629 (en production depuis avril 2013)

580 envois en avril 2013 – volume annuel escompté de +/- 6000 déclarations

Pic trimestriel (janvier, avril, juillet, octobre)

MOSS Difficile à estimer – nouveau régime

Tous ces volumes (des deux précédents tableaux) sont à considérer comme un minimum, sachant que le nombre d’utilisateurs augmente d’année en année et que de nouveaux types de déclarations seront encore ajoutés à l’application.

IHM L’Interface Homme-Machine d’Intervat est conforme aux standards de présentation décrit dans la Charte Graphique CCFF. Cette conformité, impliquant l’utilisation des composants visuels de CCFF, est obligatoire.

b. Cycle de vie de l’application 1. Adaptations de l'application aux évolutions technologiques internes (le monde java nécessite un release majeur toutes les 2 années); 2. Adaptations de l'application aux évolutions technologiques externes (OS, navigateur, …); 3. Adaptations de l'application aux modifications législatives.

c. Indications quant à la future maintenance évolutive


Intervat est une application qui évolue continuellement: d’une part, les possibilités d’implémentation de l'application sont de plus en plus nombreuses grâce à l'ajout de nouveaux modules et d’autre part, il faut veiller à ce que l’application continue à répondre aux besoins des utilisateurs. À cet égard, des changements sont régulièrement demandés et effectués dans l’application Intervat. Grandes évolutions possibles : - On pense à l’ajout d’un nouveau module de déclaration électronique des documents 604A, 604B et 604C. Il s’agit de documents que l’assujetti doit en principe introduire respectivement au début, en cas de modification et au moment de la cessation de son activité. Il existe déjà une application qui permet de faire une déclaration électronique via les guichets d’entreprise mais pas directement par l’assujetti même. - Intervat envoie les déclarations périodiques, les listings clients et les relevés intracommunautaires vers l'application back-office STIR-TVA. Ces documents sont d’abord réceptionnés dans Intervat, éventuellement dans un fichier qui contient plusieurs documents. Ces fichiers doivent être scindés en documents uniques. Cette scission a actuellement lieu dans le mux-demux qui se situe entre Intervat et STIR-TVA. Le but est de contourner ce mux-demux et que la scission des documents intervienne directement dans Intervat. L’utilisation de mux-demux rend le processus plus complexe, demande une maintenance et est dépassée sur le plan technique. Ce système n'est utilisé que par Intervat. On ne l’utilise pas dans les autres applications (p. ex. les déclarations IPP). L’abandon de mux-demux entraîne d’importants changements au niveau de la structure de la base de données et du code Intervat.


II. STIR-TVA (+ STIRON NP)


STIR-TVA contient en fait 2 modules, à savoir le volet STIR-TVA à proprement parler et le volet STIRON NP. Volet STIR-TVA : application back-office pour le traitement des déclarations périodiques de TVA, les déclarations intracommunautaires et les listings clients. Ces documents sont envoyés à partir d’INTERVAT et du système de scanning vers STIR-TVA pour y être traités ou peuvent être directement générés dans STIR-TVA. Des annexes sont aussi parfois envoyées avec les documents et peuvent être consultées à partir de l’application STIR-TVA, mais sont conservées dans Filenet. Les documents passent par une série de validations (vérification du contenu des déclarations, recoupages avec d’autres déclarations introduites dans STIR-TVA, vérifications par rapport au régime d’imposition, vérifications de la période), ce qui permet la détection d’anomalies ou de cases "déclarations manquantes". Ces anomalies sont soumises au gestionnaire de dossier sous la forme d’une tâche pour traitement ultérieur. STIR-TVA contient un système de gestion des tâches dans lequel le gestionnaire de dossier se voit attribuer une série de tâches à exécuter dans une liste de tâches élaborée par le chef de service ou dans lequel il peut lui-même prendre des tâches à effectuer. Dans le cadre du traitement des tâches, des lettres peuvent être envoyées (via FEDOPRESS) pour solutionner le problème. Ces lettres sont prédéfinies et contiennent des champs variables (données relatives à l’identité de l’assujetti, à la période, aux anomalies constatées, au cas auquel elles se rapportent). L’utilisateur a également la possibilité de ne pas opter pour une lettre prédéfinie et d'introduire lui-même le contenu souhaité dans un champ texte. STIR-TVA contient aussi un système qui permet le suivi des lettres envoyées ainsi que l’envoi automatique de lettres de rappel lorsqu’aucune solution n’a été enregistrée pour le cas ou l’anomalie ou qu’aucune réponse n’a été reçue à la lettre envoyée. Les notifications entrantes peuvent être enregistrées et génèrent alors une tâche pour l’utilisateur. STIR-TVA permet en outre de consulter les données en provenance de la douane et les listes de fournisseurs établies à partir des listings clients. Volet STIRON NP : application destinée au traitement des déclarations de TVA non périodiques. Il s’agit des déclarations suivantes : 629 déclaration de TVA spéciale 106 bâtiment nouvellement construit Déclaration générique qui permet de faire les déclarations suivantes: Déclaration du curateur 104.1 vente d’un bien immobilier, demande 104.1 vente d’un bien immobilier, déclaration 446 IC acquisition de nouveaux moyens de transport 447 IC fourniture de nouveaux moyens de transport 716 demande de remboursement d’un moyen de transport introduite par un moins valide Demande de régularisation BCAE Foires BCAE Bus (transport rémunéré de personnes) BCAE travaux immobiliers Les déclarations sont soit introduites manuellement par le gestionnaire du dossier, soit reçues par Intervat (629 déclarations de TVA spéciales et à partir de 2014 aussi les déclarations des curateurs). Quand la déclaration est définitivement conservée par le gestionnaire de dossier, un ordre de recouvrement ou un état de remboursement est automatiquement généré.

b. Cycle de vie recurrent


1. Adaptations de l'application aux évolutions technologiques internes (le monde java nécessite un release majeur toutes les 2 années); 2. Adaptations de l'application aux évolutions technologiques externes (OS, navigateur, …); 3. Adaptations de l'application aux modifications législatives.

c. Indications quant à la future maintenance évolutive STIR-TVA Les déclarations périodiques, les listings clients et les relevés intracommunautaires sont envoyés d’Intervat vers l’application back-office STIR-TVA. Ces documents sont d’abord réceptionnés dans Intervat, éventuellement dans un fichier qui contient plusieurs documents. Ces fichiers doivent être scindés en documents uniques. Cette scission a actuellement lieu dans le mux-demux qui se situe entre Intervat et STIR-TVA. Le but est de contourner mux-demux et que la scission des documents ait lieu directement dans Intervat. L’utilisation de mux-demux rend le processus plus complexe, demande une maintenance et est dépassée sur le plan technique. Ce système n'est utilisé que par Intervat. On ne l’utilise pas dans les autres applications (p. ex. les déclarations IPP). L’abandon de mux-demux entraîne d’importants changements du côté de STIR-TVA.


III. STIRON-TVA

a. Description fonctionnelle Stiron TVA (Stiron est le nom générique d'une série d'applications TVA qui remplacent les anciennes applications TVA depuis mars 2013. Ces applications sont connectées entre elles et interagissent mais communiquent aussi avec des applications externes (aussi bien du SPF qu’externes à ce dernier). Le schéma ci-dessous illustre l’application Stiron TVA et ses interactions.

Sur ce schéma, les composantes de l’application Stiron TVA sont :

- Stiron 604 - Entités spécifiques - Compte courant - Recouvrement - Comptes spéciaux - VIES - Datamart - Listes intranet - RPMSIG


Ces composantes communiquent avec ou utilisent d’autres applications du SPF FIN (en passant par les services web): - Sitran - Entités génériques - IAM - Annucomp - Taskmanager - Intervat - StirTVA - Stiron NP et des applications utilisées par des parties externes ou mises à disposition par des tiers : - Intervat - Application E 604 - KBO En gros, Stiron TVA est scindé en plusieurs modules qui ont chacun leurs propres fonctionnalités. Module 1: signalétique Pour comprendre le fonctionnement de ce module, il faut d’abord s’arrêter sur l’application Sitran et l’utilisation des Entités. Sitran SITRAN est directement lié au grand projet du “Dossier unique”. Ce “dossier” rassemble toutes les informations relatives à une même personne (personne physique et/ ou personne morale) dans un seul dossier. Pour pouvoir bien fonctionner, il faut toutefois absolument pouvoir identifier la personne et ainsi avoir accès à une série de données d’identification la concernant. SITRAN est une base de données utilisée par les collaborateurs du SPF Finances. Elle rassemble des informations à partir de différentes bases de données externes, qui sont identifiées comme des sources authentiques. Nous parlons ici du Registre national, de la Banque-Carrefour des Entreprises, de la sécurité sociale, de la centrale des bilans de la Banque nationale, … En regroupant toutes ces informations, SITRAN permet de réaliser un objectif essentiel: faciliter la vie des collaborateurs du SPF Finances au niveau de l’identification des personnes. Grâce au croisement des données disponibles dans ces diverses sources externes, mais aussi grâce à l’apport de sources internes – car l’objectif est aussi que les collaborateurs puissent compléter les données signalétiques - SITRAN constitue un puissant outil d’identification qui nécessite une gestion d’accès qui respecte la législation relative à la protection de la vie privée. Précédemment, cet accès à la base de données était relativement simple (un collaborateur avait ou n’avait pas accès à SITRAN) mais l’accroissement massif des données disponibles a imposé d’adapter ce droit d’accès. En 2011, nous avons profité d'une mise à niveau des matrices de sécurité pour mettre en place un accès mieux paramétrable. De ce fait, les utilisateurs peuvent obtenir un accès spécifiquement adapté à leurs besoins. Sur la base des différentes tâches des services utilisateurs, le Service Privacy a pu déterminer les données auxquelles chacun devait avoir accès. Le développement de SITRAN en 2011 a permis l’implémentation technique des accès définis par le Service Privacy. Cette évolution indispensable garantit à chaque assujetti que le SPF Finances – même s’il possède un aperçu complet de toutes ses données d’identification à caractère personnel –ne viole pas les dispositions légales relatives à la protection de ses données à caractère personnel. Toutes les données à caractère personnel sont reprises dans Sitran (numéro d’entreprise, numéro national, nom, adresses, numéros de compte, statuts juridiques, liens). Cela signifie que l’application Stiron TVA, même si elle affiche ses données à l’écran, ne les possède pas dans ses propres bases


de données. Le traitement de ces données se fait parfois dans Sitran, parfois dans Stiron avec des modifications dans Sitran, en fonction des données traitées. De plus, Sitran signale aussi la modification de certaines données cruciales. Le module 1 de Stiron à proprement parler concerne les données signalétiques de l’assujetti à la TVA. Tout commence par la demande d’un numéro de TVA. Un candidat assujetti à la TVA qui introduit une demande d’identification à la TVA sur papier, ou dans un guichet d’entreprise, via l’application E604. Les formulaires papier 604 doivent être introduits dans l’application E604. À ce moment, l’entité TVA est créée avec un statut en demande. Ce statut de “qualité d’assujetti à la TVA en examen” est aussi chargé dans KBOWI. Le formulaire 604A introduit génère une tâche dans le gestionnaire des tâches qui doit être traitée par le bureau compétent. Le traitement d’un formulaire 604A implique que la qualité d’assujetti à la TVA soit activée dans Stiron TVA , que les activités soient enregistrées, qu’une date de début d’activité soit donnée, qu’un régime de taxation soit attribué, qu’un compte courant soit éventuellement ouvert (lien vers le module 2), qu’un numéro de compte pour les remboursements TVA soit enregistré dans Sitran, qu’un éventuel forfait puisse être attribué, qu’il soit indiqué s’il s’agit d’un assujetti ordinaire, mixte ou exonéré, que des membres puissent être ajoutés à une unité TVA, etc. On retrouve le même flux en cas de modification des données TVA. Ces modifications entrent soit via des signaux en provenance de Sitran, soit via un formulaire 604B (demande de modification de la qualité TVA) sur papier ou via l’application E604. Les formulaires 604 sur papier doivent être enregistrés dans l’application E604. Ces formulaires 604B génèrent un TO DO dans le gestionnaire des tâches qui est parfois informatif, ce qui signifie que les données sont mises à jour de manière automatique ou parfois plus qu’informatif, ce qui signifie que l’utilisateur devra mettre certaines données à jour manuellement dans l'application Stiron, Module Signalétique. Ensuite, il doit clôturer la tâche dans le gestionnaire des tâches. La cessation de la qualité TVA se fait à l’aide d'un formulaire 604C (demande de cessation de qualité d’assujetti à la TVA), soit sur papier, soit via l’application E604. Les formulaires sur papier 604 doivent être enregistrés dans l'application E604. Cet enregistrement génère une tâche purement informative dans le gestionnaire des tâches vu que le système dispose des données nécessaires pour procéder automatiquement à la cessation de la qualité TVA. Chaque semaine, l’ensemble des données d’identification TVA est mis à jour dans un fichier RPMSIG (via Datamart) et ce fichier est utilisé par de nombreuses autres applications (VIES, INTERVAT, fichiers destinés à des tiers …) Vignettes 904 Une autre petite partie du modèle signalétique est l’impression des vignettes 904, mais cette partie est encore pour l'instant en phase d'analyse et sera analysée et développée en interne. Attestation DIV pour l’obtention de plaques marchandes et d’essai. Les garagistes qui satisfont à certaines conditions peuvent demander des plaques marchandes ou d'essai et pour cela, ils doivent demander une attestation TVA qu'ils doivent pouvoir présenter à la DIV. Cette demande se fait via un volet DIV dans le module 1. L’interaction avec la DIV se fait via des services web sécurisés. Module 2: Compte courant TVA

Le Compte courant est alimenté par de nombreuses données parmi lesquelles les déclarations périodiques 625 qui sont traitées dans le programme STIR TVA.


Le module 2 de l’application STIRON TVA permet de gérer le compte courant TVA d’un assujetti. Cela signifie que tous les arguments possibles, tant positifs que négatifs doivent pouvoir y être inscrits et correctement interprétés. Il s’agit principalement des arguments :

• Déclarations TVA : case 71 ou 72 • correction d‘une déclaration TVA • Paiements TVA • Décisions 685B et 686B

À chaque clôture mensuelle, l’application doit pouvoir correctement calculer le solde ou, en d’autres termes, vérifier si le montant versé est suffisant ou si une déclaration TVA a été inscrite pour la période concernée. Le cas échéant, l'application doit être capable de calculer le montant correct des intérêts et/ou des amendes dus. Une clôture mensuelle suppose aussi que certains comptes courants peuvent avoir un argument remboursement ou remise à zéro en tenant compte de la réglementation en vigueur. L’application doit aussi pouvoir simuler une clôture anticipée pour permettre au SPF Finances d’avertir un assujetti qu'il n’est pas en règle et lui donner ainsi l’occasion de respecter ses obligations fiscales. L’application doit aussi permettre aux bureaux de contrôle de la TVA de modifier certains paramètres, notamment le paramètre de demande de remise à zéro, le paramètre de reprise sur la Liste 678, le paramètre d’opposition à un remboursement et le paramètre d’autorisation du remboursement mensuel. En ce qui concerne le Centre de traitement de l’information, l’application doit offrir la possibilité de rectifier les paiements effectués indûment par un transfert entre comptes courants. Le CTI doit aussi offrir la possibilité de retirer de l’argent d’un compte courant pour le transférer à des collègues comptables et/ou un assujetti dans le cadre d’une procédure spéciale de remboursement. STIRON TVA doit pouvoir traiter tous les jours les fichiers CODA de la poste financière et inscrire immédiatement les paiements avec communication structurée dans le compte courant. Les paiements qui ne peuvent pas être traités automatiquement doivent être inscrits dans un registre d’attente. Ce registre d'attente doit permettre au CTI d’attribuer différentes destinations à ces paiements. Voici, ci-dessous, une liste des possibilités:

• Remboursement au donneur d’ordre • Comptabilisation définitive réception • affectation à un compte courant • transfert à un collègue comptable • envoi d’une lettre au donneur d’ordre du paiement pour obtenir de plus amples informations • laisser en attente

L'application doit être capable de générer les statistiques nécessaires concernant les fichiers de paiement entrés, concernant la clôture mensuelle et concernant l'état du registre d'attente. Ces statistiques sont indispensables pour le contrôle de la comptabilité. En ce qui concerne les remboursements de TVA, STIRON TVA doit pouvoir générer toutes les listes imaginables pour permettre le traitement des remboursements. Cela concerne les listes des remboursements directement exécutables, les remboursements via les listes 678, 678bis, 702 et 702bis. Les remboursements frappés d’opposition via le paramètre cité plus avant doivent donner lieu à l’impression d’un document 715. L’application doit pouvoir générer les fichiers d’impression nécessaires pour l’impression et l’envoi des lettres et/ou documents 628, 680, 671, 673, 670, 642 et 642V. Module 3 Recouvrement Bureau de contrôle:


Inscription et modification des montants et d'autres données à partir des ordres de recouvrement (= dettes TVA) dans les fichiers du CTRI-Malines ou du CTRI-Namur. Le débiteur est identifié via SITRAN. Il peut s’agir aussi bien d'une personne physique que d'une personne morale assujettie ou non à la TVA et domiciliée ou non en Belgique. Inscription et modification des décisions au compte courant (recettes TVA Bruxelles) et/ou aux dettes RCIV-CTRI (recettes TVA Malines ou Namur). Une décision est une imputation sans transaction financière sur le compte postal. Les transactions précitées sont conservées dans les comptes. Bureau de recettes Inscription des actions en recouvrement Inscription des frais Bureau de perception (CTI - Bruxelles) (CTRI-Malin es / CTRI-Namur) CTRI-Malines Actualisation des données Les dettes inscrites doivent être périodiquement actualisées par le biais du recalcul des intérêts dus. Paiements reçus Le CTRI reçoit les paiements via inscription sur le compte CCP. Tous les paiements sont transférés via un fichier CODA mis à disposition par notre banquier "la poste financière" au petit matin. Les opérations de la veille sont inscrites dans le fichier du jour. Les fichiers CODA sont lus et inscrits dans le registre d’attente. Pour autant que les données soient connues, le paiement est inscrit dans le registre d'attente ”client” et dans les autres cas, il est inscrit dans le registre d'attente “général”. Les paiements avec communication structurée sont imputés à la dette à laquelle ils se rapportent ; pour les paiements avec communication libre on recherche un numéro de dette et, dans la mesure du possible, ces paiements sont eux aussi imputés de manière automatisée. La recherche se fait au moyen d’une double clé, à savoir le numéro CCP et la communication (structurée). L’imputation à une dette a, entre autres, les conséquences suivantes: 1) Le solde restant dû individuel doit être calculé de manière détaillée, en tenant compte du code de paiement, de la date d’effet et du montant du paiement de sorte à pouvoir déterminer le solde restant dû. En cas d’apurement complet de la dette, le trop perçu éventuel du paiement inscrit est noté dans le registre d’attente. Ce montant devra ensuite être imputé par un collaborateur du CTRI (voir plus loin). 2) Un enregistrement comptable dans le cadre duquel les montants imputés aux frais, aux intérêts, aux amendes et à la TVA sont consignés de manière détaillée. 3) Le bureau de recettes de la TVA local doit être informé des montants imputés. 4) Le débiteur doit recevoir un avis de paiement de sorte à être informé de la destination imputée à son paiement. Les montants stockés dans le registre d’attente qui n'ont pas encore reçu de destination doivent être traités par les collaborateurs du CTRI. La raison précise de l’inscription au registre d’attente est communiquée par Stiron et peut être adaptée par le collaborateur du CTRI ; il en va de même pour la date de prise d’effet et le code de paiement. Le traitement d’un paiement implique les possibilités suivantes : 1) Imputation à une dette ouverte (voir détails plus haut) 2) Inscription comptable en réception définitive. 3) Mise en attente (le paiement reste dans le registre d’attente)


4) Demande d’informations supplémentaires par le biais d’une lettre envoyée à la partie qui a effectué le paiement 5) Demande d’informations supplémentaires sous forme électronique envoyée à un bureau (de TVA) 6) Transfert vers un autre service ou un autre organisme 7) Remboursement à la partie qui a effectué le paiement ou à un tiers. (Les remboursements vers tous les pays SEPA se font par voie électronique (BTM - Bank Transaction Manager) et dès que le CCP est débité des montants remboursés l’opération est enregistrée dans Stiron). Le remboursement des frais Les frais inscrits par les bureaux des recettes locales doivent être payés aux ayants droit concernés et/ou être recouvrés auprès du débiteur. Ces frais concernent souvent des frais d'huissier mais peuvent aussi en concerner d’autres, comme des frais d’avocat, des indemnités de procédure, des indemnités, … etc. Sur la base des codes inscrits par le bureau de recettes local, un aperçu détaillé des divers types de frais est dressé. Le remboursement des frais se fait sur ordre du CTRI via un CCP distinct par les collègues du service liquidations. Comptabilité mensuelle Nonobstant le fait que toutes les transactions précitées sont enregistrées directement et immédiatement par un système de double comptabilité, le comptable du RCIV/CTRI doit, après la fin de chaque mois et avant le 10 du mois suivant, déposer ses états comptables pour justification. Ces états sont basés sur une comptabilité de caisse qui doit être établie à un moment précis (clôture mensuelle). Cet état est aussi conservé au sein de Stiron. Les données qui s’y rapportent sont générées par sélection/rassemblement des comptes établis. Outre les données reprises dans les états mensuels, les données sont aussi générées pour la création de registres et les inscriptions dans ces registres. Ce module comprend aussi de nombreuses lettres qui doivent être envoyées et des listes qui doivent être générées. Module 4 – comptes spéciaux Comme mentionné plus haut, un compte courant est tenu auprès du CTI pour chaque assujetti qui doit introduire une déclaration périodique et pour autant que les assujettis respectent leurs obligations en matière d’introduction des déclarations et de paiement des sommes dues. Si ces obligations ne sont pas respectées pendant une période donnée, la gestion pécuniaire du compte courant n’est plus assurée par le CTI et un compte spécial est créé. Le remplacement du compte courant par le compte spécial se fait par le biais d'une mise à zéro du compte courant et du transfert du solde du compte courant à un moment donné vers un compte spécial. La mise à zéro du compte courant fait partie du module 2, la création du compte spécial se fait dans le cadre du module 4 de Stiron TVA. Le compte spécial est établi par le bureau de taxation. Une attention particulière est accordée à la période du compte spécial (qui doit être étendue dans certains cas), les déclarations et les paiements enregistrés sur le compte courant, ou éventuellement introduits après la mise à zéro, les amendes, certaines régularisations, les intérêts pour paiement tardif … Des arguments peuvent être ajoutés au compte spécial et des arguments peuvent en être enlevés. Il convient également d’être attentif à l’acompte de décembre. Les comptes spéciaux pour non-paiement sont automatiquement soumis à validation et ne demandent aucune intervention manuelle. Le résultat du traitement de la liste des comptes spéciaux d’un bureau, est une liste de validation destinée au chef d’équipe. Une fois validé, le compte spécial est imprimé et envoyé à l'assujetti. Ce compte peut aussi être consulté dans l’application. Parallèlement, un ordre de recouvrement est établi


via le module 3, dans lequel se déroule la suite du traitement de la dette. Si le BRCS débouche sur un crédit, celui-ci doit être imputé, ce qui ne se fait pas encore provisoirement dans l’application Stiron TVA. Dans ce cas, le statut de remboursement n’est pas intégré dans l’application (il pourrait s’agir d’une éventuelle extension). Le module comptes spéciaux prévoit aussi l’envoi d’une série de lettres et la publication d’une série de listes. Module 5: VIES L’application VIES permet de consulter les informations suivantes : 1) les données d’identification des assujettis à la TVA de tous les États membres 2) les détails des données européennes de vente à des assujettis BE. 3) Détails des acquisitions intracommunautaires faites par un assujetti à la TVA d’un autre État membre dont le fournisseur est un assujetti à la TVA BE 4) cours de change utilisés Il s’agit des fonctionnalités d’EUROTP reprises par l’application Vies Client. Vies envoie des requêtes à diverses bases de données d’autres États membres et affiche la réponse à ces requêtes sur divers écrans. Module 6 : BCAE Le BCAE est compétent pour l’identification TVA des assujettis étrangers et les différentes formalités qui précèdent l’octroi d’un numéro d’entreprise. Ces assujettis étrangers sont soit enregistrés en Belgique soit identifiés uniquement dans le cadre d'activités occasionnelles en Belgique. Toutes ces données sont actuellement conservées et enregistrées dans une application interne ACCES. Par le passé, le BCAE avait été obligé d’en arriver à cette solution du fait que les applications existantes au niveau central n’offraient pas la possibilité d’enregistrer les assujettis étrangers. Dans le cadre de la migration technique, le SPF Finances souhaite que les données existantes des assujettis étrangers soient ramenées au niveau central et plus précisément dans le nouvel environnement STIR Entreprises. Il faut aussi tenir compte des éventuelles données existantes dans TPSigna qui fait également l’objet d’une migration technique (cf. Module 1). Module 7 : applications intranet L’administration de la TVA publie de nombreuses listes sur l’intranet. Ces listes sont partiellement cogénérées par Stiron. Il s’agit, entre autres (mais pas uniquement) de:

Module Listes intranet et fichiers M3 Liste 750 M3 GDD

M3

Liste 697 partie ½: Crédits des Contributions Directes, des Douanes et Accises et de l'Enregistrement, éventuellement saisissables par les Receveurs TVA

M3 Liste 697 partie 2/2: Dettes Recouvrements BF M1 Liste 623 (des assujettis radiés dans le fichier central) M2 Liste 694 (Prévention mise à zéro) M1 Liste des petites entreprises sans régime d’exonération


M2 Liste 749/7 Liste des décisions 686 encodées par les offices de contrôle TVA.

M3 Liste 749/1 Liste des diminutions d’O.R. par les services de taxation TVA

M3 Liste 749/3 Liste des radiations d’O.R. par les services de taxation TVA.

M2 Liste 692 (bureau) (remboursements trimestriels) M2 Liste 692 (overview) (remboursements trimestriels) M1 Liste forfaitaire des assujettis M2 Liste 4070 (autorisation remboursement mensuel)

RPM_SIG – BTW Signa Serveur VIES

Module 8 : Lien avec DIM et Filenet Le courrier entrant et sortant doit pouvoir être consulté à partir de l’application STIRON Lot 2. Pour cela, il faudra prévoir une synchronisation avec le projet DIM/Myscan Mise en production : septembre 2013. Module 9 : ET14000, Monitoring et reporting Ce module comprend le remplacement de l’application qui assure la gestion des autorisations ET14000. ET14000 n’entrera en production qu'au cours du troisième trimestre 2013. De plus, le module 9 contient aussi des statistiques et les outils de monitoring et de reporting concernant l’ensemble du Lot STIRON. Pour ces statistiques, un Datamart a été mis au point qui est exploité.

b. Cycle de vie récurrent

1. Adaptations de l'application aux évolutions technologiques internes (le monde java nécessite un release majeur toutes les 2 années);

2. adaptations de l'application aux évolutions technologiques externes (OS, navigateur, 3. adaptations de l'application aux modifications de structure de l'organisation; 4. adaptations de l'application aux modifications législatives.

L’application est utilisée de manière intensive par les bureaux de contrôle de la TVA, les bureaux de recettes, le CTI. Le CTRI, l’ISI, … depuis mi-mars 2013. Ses utilisateurs ont relevé une série de manquements qui ne sont pas des bugs car conformes à l’analyse. Ces manquements ne bloquent pas le fonctionnement de l’application et de l'administration de la TVA mais empêchent parfois d’aboutir à une solution adaptée. Lorsque des problèmes sont signalés concernant certaines fonctionnalités, ces problèmes doivent être étudiés, en partie par le business mais aussi par une équipe technique. Le diagnostic du problème, la recherche de solutions et l’implémentation de ces solutions font tout autant partie du marché.


c. Indications quant à la future maintenance évolutive Un nombre élevé de change requests (CR) ont été répertoriées, parfois liées à des remarques des utilisateurs, parfois liées à des améliorations de l’application opérées à l’occasion d’erreurs d’analyse, de l’extension de certaines fonctionnalités ou de la poursuite de l’automatisation de certains workflows. Actuellement, environ 150 change requests ont été identifiées, qui, dans la mesure du possible, doivent être analysées et implémentées. Au fur et à mesure de son utilisation, l’application évoluera et il faudra s’attendre à de nombreuses nouvelles demandes d’améliorations et d’extensions.


IV. MOSS


Le projet « Mini One Stop Shop » (MOSS) qui a démarré en février 2013 a pour objectif de répondre aux nouvelles exigences européennes en matière de TVA. Plus précisément ce projet vise le développement d'une application électronique assurant la gestion d'un régime TVA particulier offert à compter du premier janvier 2015 aux assujettis non établis dans un ou plusieurs Etats membres de l'UE qui fournissent des services de télécommunication, de radiodiffusion et de télévision ou des services électroniques à des personnes non assujetties dans ces Etats membres. Les spécifications fonctionnelles et techniques ont donc été définies par l’UE pour s’assurer de la cohésion des applications entre les pays mais également par le SPF Finances pour toutes les spécificités propres à son environnement. Ce projet est encadré par des dispositions législatives européennes (une modification de la directive 2006/112 réglant le fonctionnement de la TVA, le Règlement 904/2010 organisant la coopération administrative en matière TVA et des nouveaux Règlements d'application des nouvelles règles en question). Ce guichet unique (M1SS) reprend et inclut l'actuelle application VOES (VAT on e-services) dédiée aux prestataires établis en dehors de l'UE et qui ont demandé leur assujettissement en Belgique. Le projet comporte également la mise en œuvre des dispositions européennes relatives à l'accès aux bases de données et aux échanges automatiques d'informations permettant aux Etats membre d'assurer le contrôle de ce régime particulier. 4 modules ont été identifiés pour la réalisation de ce projet.

1. Module « enregistrement » 2. Module « déclaration » 3. Module « paiement » 4. Module « statistiques & reporting »

Conformément au planning du projet, les 2 premiers modules ont été développés, testés au niveau belge et au niveau européen (tests de conformance). Les tests du module paiement sont en cours. Le module « Statistiques & reporting » est en cours d’analyse et de développement. Ci-dessous une description plus élaborée des aspects fonctionnels et techniques du système MOSS. Pour chacune de ces parties, différentes tâches sont décrites. Ces tâches sont ensuite divisées en sous-tâches en fonction du rôle de la Belgique soit :

- comme Etat membre d’identification : MSid - comme Etat membre de consommation : MSCon - comme Etat membre d’établissement : MSEst - comme autre Etat membre.

1) L’enregistrement Le module enregistrement couvre la gestion des demandes d'enregistrement, des demandes de modifications des données d'enregistrement, des demandes d’exclusions et la gestion des requêtes sur les données d’enregistrement. Demandes d’enregistrement BE= MSid ( Etat membre d’identification) a) Réception de la demande d’enregistrement L’adaptation du portail Intervat n’est pas couverte par ce module du cahier des charges. Par contre, le lien entre Intervat et l’application Mini OSS sera bien à réaliser. Il s’agit donc de réceptionner les demandes selon leur provenance.


b) traitement de la demande : Il faut distinguer un premier traitement de forme de la demande d’un traitement de fond (acceptation ou refus de la demande).

� traitement de forme de manière automatique, directement au moment de l’encodage (Intervat)

� traitement de fond consistant à vérifier que l’assujetti rempli les conditions nécessaires et suffisantes pour utiliser ce régime particulier tout en laissant la décision finale à l’administration.

Le système organise la transmission de la demande d’enregistrement aux services concernés via le Task manager. L’agent chargé de statuer sur la demande dispose de toutes les informations nécessaires à sa décision et notamment des informations contenues dans la base de données MiniOSS. Il est possible de marquer (‘flager’) certains assujettis suspects nécessitant une surveillance.

� Enregistrement des données d’identification dans la base de données belge au sein de l’application (pour le EU scheme et pour le non EU scheme).

� Notification à l’assujetti : acceptation/refus. � Envoi aux autres Etats membres : Les données d’enregistrement doivent être

transmises au plus tard pour le 10e jour du mois qui suit la demande d’enregistrement. Afin d’éviter des enregistrements doubles, la Belgique envoie au fil de l’eau dès l’acceptation plutôt que par Batch.

� Flag spécifique dans la signalétique de l’assujetti (entité TVA) signalant que l’assujetti utilise ce régime spécifique.

BE= MSCon, MSest ou autre MS : - intégration des informations reçues dans une base de données avec, entre

autres, écran de consultation et historiques des informations. - Flag spécifique dans la signalétique de l’assujetti (entité TVA) signalant que

l’assujetti utilise ce régime

Gestion des modifications des données d’enregistrem ent : BE= MSid ( Etat membre d’identification) Système quasi parallèle au processus de gestion des demandes d’enregistrement :

- Réception de la demande de modification : via Intervat ou site Internet - Traitement de la demande : acceptation ou refus - Notification de la décision à l’assujetti - Enregistrement des données dans la base de données Mini OSS (avec

historique) BE= MSCon, MSest ou autre MS Des requêtes adressées aux MSid doivent pouvoir être réalisées : requêtes automatiques pour une mise à jour régulière des informations, et/ou requêtes sur demande. Gestion des exclusions : Deux possibilités de demande d’exclusion : de l’assujetti lui-même ou de l’Etat membre d’identification faisant parfois suite à la demande de l’Etat membre de consommation. Lorsque, pour différentes raisons énumérées dans la Directive, l’assujetti fait une demande d’exclusion (via le portail), cette demande doit être traitée de la même manière qu’une demande d’enregistrement (5 étapes)

- Réception de la demande d’exclusion : via Intervat ou site Internet - Traitement de la demande : information complète ou non - Notification de la décision à l’assujetti - Enregistrement de l’exclusion dans la base de données Mini OSS - Envoi de l’information d’exclusion à tous les EM. avec code d’exclusion.

Comme MSid, l’application devra générer de manière périodique une liste des assujettis ne remplissant plus les conditions pour pouvoir se prévaloir du présent régime particulier (pas de déclaration, pas de paiement, paiement partiel… ). Cette liste sera transmise au(x) service (s) compétent(s) pour traitement et action. En cas de décision d’exclusion :


- Notification de l’exclusion à l’assujetti - Enregistrement de l’exclusion dans la base de données Mini OSS - Envoi de l’information d’exclusion à tous les EM. (codes d’exclusion)

Comme autre Etat membre, la Belgique devra recevoir les notifications d’exclusion venant des Etats membres d’identification et les intégrer (mise à jour) dans la base de données MiniOSS. Gestion des requêtes sur les données d’enregistreme nt : La Belgique doit pouvoir d’une part réaliser des requêtes à l’attention des autres Etats membres (écran de requête) et d’autre part traiter les requêtes reçues des autres Etats membres concernant les assujettis identifiés en BE. Comme c’est le cas pour VIES, il s’agit d’un processus de requête sur les données d’enregistrement dans la base de données des MSid. Ce processus est tout à fait informatisé et donc sans aucune intervention humaine. 2) La déclaration La partie déclaration assure la gestion des déclarations, des déclarations correctives, les transmissions des informations aux Etats membres Gestion des déclarations

BE= MSid ( Etat membre d’identification) a) Enregistrement de la déclaration par le NETP : Les déclarations sont introduites par

les NETP via le portail Intervat. Elles sont ensuite transmises pour traitement à l’application MiniOSS. A nouveau, l’application couvre le lien entre Intervat et le back-office pour la réception des déclarations et des corrections.

b) Vérification de la déclaration initiale reçue => déclaration acceptée ou refusée. c) Assignation d’un numéro de référence unique à la Déclaration d) Enregistrement de la Déclaration dans la base de données e) Envoi d’un accusé de réception au NETP avec le numéro de référence et l’invitation

au paiement f) Division de la déclaration par Etat membre concerné. g) Envoi des déclarations aux EM : envoi groupé suivant les spécifications liées aux

paiements. BE= MSCon (Etat membre de consommation ou MSEst (Etat membre d’établissement)

- Réceptionner, valider et enregistrer les déclarations reçues par assujettis dans la base de données européenne.

- Assurer le traitement des déclarations et le lien avec le paiement reçu - Mettre en place une série de contrôles automatiques - Générer des exports de données nécessaires au contrôle humain.

Gestion des corrections BE= MSid Si une correction est déposée avant le 21e jour du mois qui suit le trimestre, la correction écrase et remplace la déclaration initiale. Si une correction est déposée après le 20e jour du mois qui suit le trimestre, la déclaration corrective est traitée comme la déclaration antérieure qu’elle modifie. Elle garde cependant la même référence, mais reçoit un nouveau ‘timestamp’. Toutes ces versions sont conservées dans la base de données. BE=MScon ou MSEst Toutes les déclarations correctives reçues sont traitées de la même manière que la déclaration initiale. Elles sont intégrées dans la base de données en fonction du trimestre auquel elles se rapportent. Correction suite à un contrôle : suite à un contrôle, une modification pourrait être apportée aux données de la déclaration. Dans ce cas, un écran d’encodage donnant accès à un XML spécifique est à prévoir.


Rappel pour non dépôt de déclaration Conformément au Règlement du Conseil, l’Etat membre d’identification est tenu d’envoyer un rappel aux assujettis n’ayant pas déposé de déclaration. Ce rappel est généré automatiquement et transmis à l’assujetti (+ signal sur Intervat). L’Etat membre est en outre tenu d’informer les autres EM de l’envoi de ce rappel. Une liste des assujettis ayant reçu le rappel est transmis à tous les EM. Gestion des requêtes sur des transactions Le MSid et le MSCon ont tous deux le droit de demander au NETP des informations sur ses transactions. Le Règlement du Conseil a listé précisément les informations que le NETP doit mettre à disposition. Le système prévoit la possibilité de réaliser cette requête auprès des assujettis, de recevoir l’information, de l’enregistrer, de la transmettre si nécessaire, et en donner l’accès. 3) Le paiement BE= MSid Les paiements sont réalisés par les NETP sur un compte spécial pour le MiniOSS. L’assujetti reçoit lors de la notification de l’acceptation de sa déclaration une référence spécifique à utiliser permettant de faire le lien entre la déclaration et le paiement. Le système doit donc croiser les données des déclarations et les montants perçus. Sur ces montants, 30 % les deux premières années et 15 % les deux années suivantes du montant sont conservés par le MSid. Ce prélèvement est donc pour le trésor belge. En fonction du montant reçu, différentes actions sont à prévoir. Si le montant est trop élevé, l’assujetti doit être remboursé (pas de compensation d’un trimestre à l’autre) et notifié de ce remboursement. Si le montant est insuffisant, il faut le diviser de façon proportionnelle à la déclaration entre les EM. Un rappel de paiement est également à transmettre. En cas de non-paiement, un rappel doit également être transmis. Une liste avec le détail du paiement est envoyée à chaque Etat membre reprenant la référence de la déclaration et le montant versé pour chaque assujetti. BE=MSCon Il s’agit de traiter d’une part l’information concernant les paiements reçus d’un EM et le paiement lui-même. Il convient ensuite de vérifier pour les assujettis ayant introduit une déclaration la cohérence entre le montant déclaré et le montant perçu compte tenu du prélèvement par le MSid pendant les 4 premières années. C’est le MSCon qui statue sur la validité (correcte ou non) du paiement. Le paiement peut à nouveau être excessif ou insuffisant. S’il est excessif, le MSCon rembourse directement le NETP, le MSCon lui notifie ce remboursement et le MSCon en informe le MSid qui a son tour reversera durant les 4 premières années le prélèvement qu’il a effectué. Si le paiement est insuffisant ou inexistant, le MSCon transmet également une demande de paiement à l’assujetti. Conformément au règlement du Conseil, toutes les amendes, les intérêts, etc. sont directement réclamés par le MSCon, en dehors du système. 4) Module Statistiques et reporting Ce module fournit les données nécessaires au management et aux cellules d’audit. Différentes statistiques non encore définies seront développées de même que la possibilité d’exporter les données ou de réaliser certains rapports notamment à des fins de contrôles.


• Adaptations de l'application aux évolutions technologiques internes et/ou externes (applications de connexion intra-européennes, évolutions des standards ICT…)

• Adaptations de l'application aux modifications de structure de l'organisation; • Adaptations de l'application aux modifications législatives.


Lors du développement, une série de modifications aux spécifications d’origine (« KEL ») ont déjà été introduites par la Commission Européenne. Certaines modifications viennent d’être approuvées ou sont encore en cours d’approbation (annexes 1 et 2). L’ouverture des échanges entre les Etats-membres début janvier 2015 a mis en lumière d’importantes différences d’interprétation de la législation et des spécifications. Il en résulte un nombre conséquent de rejets de messages intracommunautaires mettant à mal le bon fonctionnement de ce nouveau régime. De nouvelles modifications des spécifications devront donc être renégociées et ensuite implémentées. Une assistance complémentaire est donc indispensable au maintien d’une application fonctionnelle, et doit-nous permettre de respecter les modifications des spécifications fonctionnelles et techniques imposées par la Commission. Il est important de noter que celles-ci sont contraignantes pour les Etats membres.


De futures modifications aux logiciels et aux applications résultant de changements législatifs, d’upgrades apportés aux environnements ainsi que d’éventuelles demandes d’améliorations de la part des utilisateurs finaux sont susceptibles de voir le jour. Compte tenu du fait que l’application MOSS est entrée en production le 1er janvier dernier (2015), aucune indication précise quant à la future maintenance évolutive ne peut être communiquée.


Lot 2 (Domaine Impôts directs Personnes Physiques ( IPP + INR/PP)

Belcotax-On-Web (BOW) Tax-On-Web (TOW) Taxi Proposition de Déclaration Simplifiée (PDS) Calculatrix (Calcul IPP)

I. Belcotax-On-Web (BOW)


L'art. 92 de l'A.R. d'exécution du C.I.R. - 1992 (Moniteur belge du 13.09.1993) stipule qu'à la fin de chaque année, les redevables du précompte professionnel sont tenus de remplir une fiche pour chacun des bénéficiaires des revenus et d'établir un relevé récapitulatif de ces fiches.

Dans le cadre du système Belcotax on web, les employeurs et autres débiteurs de revenus soumis au précompte professionnel doivent satisfaire à cette obligation vis-à-vis de l’Administration de la fiscalité des entreprises et des revenus en fournissant les informations via le web.

L’utilisation de Belcotax on web a été rendue obligatoire pour l’ensemble des débiteurs des fiches 281.10 à 281.30 et 281.50 à partir du 01/01/2009.

De même, l'art. 57 de l'A.R. d'exécution du C.I.R. - 1992 stipule que dans les 2 mois qui suivent chaque année civile de la période pour laquelle l’agrément a été obtenu une copie des attestations délivrées doit être remise à l’administration.

Dans le cadre du système Belcotax on web, les institutions agréées peuvent satisfaire à cette obligation vis-à-vis de l’Administration de la fiscalité des entreprises et des revenus en fournissant les informations via le web.

L’utilisation de Belcotax on web a été rendue obligatoire pour l’ensemble des institutions à partir du 01/01/2012.

L’application a été étendue à d’autres données tel que attestations de titres services, épargne pension, fiches rentes alimentaires ; …etc.

A ce jour, 35 types d’informations différentes sont récoltées annuellement représentant plus de 30.000.000 de fiches ou attestations


Pour accéder aux fonctionnalités de Belcotax on Web l’utilisateur doit disposer d’une signature électronique de type certificat ou posséder une carte d’identité électronique belge.

Chaque année, une nouvelle application doit être créée à partir de celle de l’année précédente, des adaptations sont nécessaires pour prendre en compte les directives relatives à la nouvelle année de revenus (modification de certaines fiches 281, changement d’année, validations…). Toutes ces modifications sont effectuées dans le cadre de la maintenance adaptative.

Les fonctionnalités :

o Transfert de fichiers (Envois) via le web en format XML ou TXT

o Accès via web à un programme de validation avant envoi

o Possibilité d’encodage par les clients externes et par l’administration

o Possibilité d’envois de fichiers de corrections

o Possibilité de consultation et de correction on-line

Il permet une disposition en temps réel des données tant pour les fournisseurs de données eux-mêmes, pour les bénéficiaires de ces revenus (MYMINFIN- TOW) que les agents du SPF Finances

o Enrichissement des données par recherche du numéro national et du

service compétent

o Communication des données via web services ou view des données aux

applications TAXI, TOW, PDS ou MY MINFIN.

o Etablissement de PDF des fiches, relevés et récapitulatifs de données

o Etablissement de fichiers en XM,, txt ou Excel récapitulatifs (Bilan, Output

prp, recherche avancée)

o Ensemble de fonctionnalités à destination des gestionnaires de

l’application (récupération de fichiers, renvoi de feedback, modification de statuts, contournement de validation, etc)

Planning Pour l’année des revenus concernés.

� Date de remise des modifications : novembre/décembre de l’année des revenus � Date de la mise en Production : 1er février qui suit l’année des revenus.



Maintenance annuelle La maintenance récurrente couvre l’annualisation des déclarations Bow. Cette maintenance est nécessaire pour suivre l’évolution des déclarations Belcotax dues aux changements de la législation. Elle est constituée des points suivants : o Création d’une nouvelle version de l’application. o Modification des fiches. Le cœur de l’application étant le traitement des fiches 281.XX, la plupart

des adaptations découlent donc des modifications légales appliquées à ces fiches. Ces modifications sont générées par la modification de la législation elles ne sont connues qu’à la fin du quatrième trimestre de l’année des revenus pour laquelle l’application doit être adaptée

o Ces modifications entraînent plusieurs adaptations :

� adaptation du fichier XSD, � modifications des règles de validation, � changements dans les écrans de saisie et de visualisation des fiches et des relevés � adaptation des PDF, � changement de la structure des bases de données, � adaptation du traitement des envois au niveau back-office, � adaptation des récapitulatifs, � adaptation des web services et view utilisés par les applications Taxi, Tax-on-Web et

PDS (proposition de déclaration simplifiée). � Mise à jour de la documentation technique

Support L’application Belcotax-on-Web est indispensable à l’exécution des missions fiscales du SPF Finances. Tout incident de production peut avoir un impact financier et légal considérable (respect des délais légaux), ainsi qu’en terme d’image auprès du public (application Eservice). Préalablement avant toute intervention, un diagnostic « high level » permet de déterminer l’équipe la plus appropriée pour résoudre l’incident (ICT operations, équipe de développement. Si un incident survient, une équipe doit être rapidement disponible en vue d’en identifier l’origine et de le dispatcher à qui de droit. L’expérience montre que l’équipe de développement doit avoir une connaissance globale suffisante pour accomplir cette mission. Outre ce support de gestion des incidents et autres, il y a lieu de prévoir support complémentaire en vue d’améliorer les fonctionnalités existantes aux niveaux de la convivialité, du traitement de cas particuliers….

c. Indications quant à la future maintenance évolutive 1. Migration vers authentification FedIam L’authentification se réalise actuellement via les services de la sécurité sociale (erranova) elle devrait migrer à terme vers une authentification similaire à celle pour Tax on web 2. nouvelles fiches fiscales à intégrer. La mise en place de la régionalisation devrait entraîner à terme une augmentation des informations récoltées via Belcotax on web. 3. Optimisation de l’enrichissement du Numéro national des attestations de dons en utilisant les résultats de l’enrichissement NP de l’année antérieure.


4. Permettre la consultation modification par un expéditeur de données introduites antérieurement par des sociétés qui ont été ensuite absorbées ou fusionnées avec cet expéditeur.


II. Tax-On-Web (TOW)


Tax-on-web existe depuis 2003. L’application E-gov permet aux contribuables ou le cas échéant à leurs représentants désignés d’introduire par voie électronique et de manière conviviale les déclarations à l'impôt des personnes physiques et des personnes morales ainsi que des personnes physiques non-résidentes. Le principe prééminent du système est celui de l’égalité de traitement de tous les contribuables par l’octroi automatique des droits et/ou des avantages auxquels ils ont droit. La déclaration doit toujours correspondre à la législation en vigueur. Tax-on-web prévoit une interface adaptée pour chaque catégorie d’utilisateurs: Le citoyen (via Taxbox’) Le mandataire (via ‘Taxworkbox’). Taxworkbox est accessible via le système des mandats. Le titulaire d’un mandat peut ainsi remplir les déclarations de ses clients. Une possibilité d’envoyer les déclarations par lot est également prévue. Le fonctionnaire (via Finbox – dans le cadre du service aux citoyens). Les données connues sont déjà préremplies pour tous les contribuables – cela pour faciliter les choses pour l’utilisateur et prévenir les erreurs de saisie des données. Le contribuable a la possibilité de joindre à sa déclaration des documents au format PDF. Lors du remplissage de sa déclaration, le citoyen peut s’arrêter à tout moment et la conserver pour continuer à la remplir ultérieurement. Lors du remplissage de la déclaration, les données sont systématiquement soumises à un contrôle des erreurs. Ce contrôle systématique des erreurs permet de prévenir les fautes évitables dans les déclarations. Ces contrôles sont intégrés dans les règles de validation déterminées par le modèle externe Calculatrix. L’intégration de ces règles de validation (pas leur développement) fait partie du présent marché. Les champs entachés d'erreurs sont marqués au moment du calcul ou de la navigation entre les différents cadres de la déclaration. En cas d'erreur, un message d’erreur s’affiche et le cadre concerné est identifié. L’utilisateur peut aussi faire une simulation de calcul de l'impôt dû. Cette simulation de l’impôt donne à l’utilisateur une indication sur l’estimation du montant de ses impôts. L’écran de résultat se compose de l’estimation du montant des impôts dus et d’un calcul détaillé de cette simulation au format PDF. La simulation fait partie d’une application distincte, Calculatrix. Seule l'intégration de la simulation fait partie du présent marché. Après l’introduction de la déclaration, le citoyen peut, en tout temps, la télécharger et/ou l’imprimer. Il peut aussi encore une fois modifier la déclaration de l’année d’imposition actuelle et la réintroduire. Les déclarations des 6 exercices d’imposition antérieurs restent consultables (si elles ont été introduites dans tax-on-web). Chaque année, plus de 3.400.000 déclarations sont introduites sous forme électronique à l’impôt des personnes physiques et à l’impôt des non-résidents. (Dans la majorité des cas, les déclarations ne doivent plus être envoyées aux contribuables mais uniquement être disponibles sous forme électronique – cf. Art. 308 §3 CIR 92).


Tax-on-web permet aussi de visualiser les plus de 2.000.0000 de propositions de déclaration simplifiée. Cela permet au citoyen de toujours modifier ou compléter sa déclaration. Les déclarations introduites par voie électronique peuvent être traitées immédiatement, ce que les citoyens peuvent remarquer au fait que les premiers avertissements-extraits de rôle sont envoyés dès le mois de juillet (grâce à l’intégration du service ‘Zoomit’, il y a aussi moins d’avertissements-extraits de rôle envoyés sur papier). Un traitement plus rapide et correct des déclarations introduites génère aussi d'importantes économies au niveau des frais de fonctionnement de l'administration. Dans cette optique, le développement de wizards contribue à améliorer la qualité des données entrantes au SPF Finances. De plus, une simulation de calcul anonyme ‘Taxcalc’ est proposée sur le site web du SPF Finances et une application d’entraînement a été mise au point pour les écoles et les organisations intéressées (Taxsimu). Tax-on-web est disponible dans les trois langues officielles, le français, le néerlandais et l’allemand. L’application doit rester utilisable sur tous les systèmes d'exploitation courants et navigateurs courants. La disponibilité (24h/24 et 7j/7) de l’application est une exigence.


a. Contexte

Tax-on-web existe depuis 2003. L’application a atteint à ce jour une maturité tant du point de vue fonctionnel que technique. Cependant, chaque année, la déclaration fiscale étant modifiée, une série d’activités de maintenance doivent être réalisées afin de garantir le bon fonctionnement de l’application.

b. Activités de maintenance adaptative Les tâches principales sont. • Project setup • Modification des cadres de la déclaration Partie I et II • Adaptation des autres cadres (Notes, accusé de réception, Taxworkbox, etc.) • Génération des PDF en fonction du nouveau format de la déclaration • Adaptation des règles de validation • Codes particuliers

� Wizards

� Codes montants négatifs

� Code unique pour plusieurs montants

� Gestion spécifique des revenus étrangers


• Mise-à-jour de l’encodage rapide • Maintenance du catalogue de test (Quick test) • Modification du schéma pour l’envoi en masse (mandataire) • Chargement des différentes DB • Prefilling de certains codes de la declaration • Mise à jour des éléments statiques

Par exemple :

� Templates Finform, pdf mandataires

� Mise-à-jour de l’aide (FAQ, …)

� Mise à disposition du livret explicatif au format HTML • Mise à jour de l’interface avec le calcul et l’optimisation • Suivi technique

Entre autre :

� Préparation et suivi des livraisons

� Support en production •Mise à jour de l’application de correction d’une declaration. •Mise à jour de la fonctionnalité ‘Zoomit’ •Mise à jour de l’application d'entraînement (pour écoles etc.) • Mise à jour de l’application Taxcalc • INR-BNI • Mise à jour de module de statistiques • Mise à jour de l’application suite à des modifications réalisées dans d’autres applications.

1. PROJECT SETUP

Chaque année avant que l’équipe projet puisse commencer l’analyse et le développement de la nouvelle version, une série de tâches basiques doivent être effectuées afin de rendre l’environnement de développement opérationnel. • Kick off avec le SPF • Configuration des outils, • Mise-à-jour des environnements • Backup divers, création des labels,…

2. MODIFICATION DES CADRES DE LA DÉCLARATION PARTI E I ET II Les cadres de l’application seront adaptés en fonction de la nouvelle déclaration IPP.

3. ADAPTATION DES AUTRES CADRES (NOTES, ACCUSÉS DE RÉCEPTION, TAXWORKBOX)

Les autres cadres seront également adaptés pour prendre en compte la nouvelle année fiscale. Il s’agit par exemple des écrans Parallèlement aux cadres de la déclaration, les autres pages de l’application « Notes », les accusés de réception, l’écran de résumé avant soumission,…


4. GÉNÉRATION DES PDF EN FONCTION DU NOUVEAU FORMA T DE LA DÉCLARATION

Les déclarations doivent pouvoir être visualisées au format PDF.

5. ADAPTATION DES RÈGLES DE VALIDATION Les règles de validation ainsi que les messages associés destinés à l’utilisateur seront adaptés à la nouvelle déclaration fiscale. Les règles Business sont quant à elles fournies par le SPF Finances

6. CODES PARTICULIERS Certains codes de la déclaration ont des fonctionnalités particulières. Celles-ci doivent également être mises à jour en fonction de la nouvelle version de la déclaration : • wizards, • codes permettant des montants négatifs, • code unique pour plusieurs montants, • gestion spécifique des revenus étrangers.

7. MISE À JOUR DE L’ENCODAGE RAPIDE L’encodage rapide (et visualisation directe des fiches Belcotax) pour le nouvel exercice d’imposition.

8. TESTING Pour chaque version mise en production i lest nécessaire d’exécuter un nombre de tests unitaires. Des de tests seront également fait en collaboration avec le test center.

9. MODIFICATION DU SCHÉMA POUR L’ENVOI EN MASSE (MA NDATAIRE) L’envoi en masse est une fonctionnalité utilisée par les mandataires qui leur permet d’envoyer via un fichier .tow plusieurs déclarations simultanément dans l’application. Ces fichiers sont créés via les logiciels de comptabilité suite aux spécifications fournies par le SPF finances. Le schéma xml et les spécificités techniques seront adaptés à la nouvelle déclaration. Le SPF quant à lui se chargera, comme pour les années précédentes, de la publication de la documentation technique.

10. CHARGEMENT DES DIFFÉRENTES DB L’ensemble des données nécessaires au fonctionnement de Tax-on-web

11. PRÉFILLING Depuis plusieurs années, le SPF pré-remplit autant que possible la déclaration des citoyens en fonction des données disponibles lors du démarrage de Tax-on-web. Ces données proviennent de différentes origines.


12. MISE À JOUR DES ÉLÉMENTS STATIQUES • Templates Finform, pdf mandataires

• Mise-à-jour de l’aide (FAQ, …)

• Mise à disposition du livret explicatif au format HTML

13. MISE À JOUR DE L’INTERFACE AVEC LE CALCUL ET L’ OPTIMISATION Les interfaces vers la version 2013 du calcul ainsi que vers l’optimisation seront adaptées en conformité avec la nouvelle déclaration

14. SUIVI TECHNIQUE En collaboration avec les autres services ICT. Il s’agit de la preparations et suivi des livraisons et le support en production.

15. MISE À JOUR DE L’APPLICATION (FONCTIONALITE) D E CORRECTION D’UNE DECLARATION.

Depuis 2013 le contribuable a la possibilité de modifier sa declaration déjà soumise.

16. MISE À JOUR DE LA FONCTIONALITE ZOOMIT Zoomit permet de recevoir des documents via le PC banking. Dans Tax-on-web l’utilisateur peut choisir de bénéficier du service Zoomit. Il est nécessaire que le numéro de compte bancaire du contribuable soit lié à Zoomit. Pour cela Tax-on-web utilise les fonctionalitées mises à disposition en interne.

17. MISE À JOUR DE LA FONCTIONALITE DE CORRECTION D ’UNE DECLARATION.

Mise à jour de l’application de correction d’une declaration. Le contribuable a la possibilitée de corriger sa declaration après la première soumission.

18. MISE À JOUR DE L’APPLICATION D’ENTRAÎNEMENT Basée sur l’architecture de Tax-on-web, l’application d’entraînement sera également adaptée à la nouvelle déclaration.

19. MISE À JOUR DE L’APPLICATION TAXCALC Le calcul anonyme (disponible sur le site web du SPF Finances) Il s’agit du calcul de l’année actuelle et des années précédentes.

20. INR-BNI


Activités principales : • Cadres de la déclaration

• Annexes et Notes

• Encodage rapide Parties I et II

• Envoi en masse

• Règles de validation spécifiques

• Traitement des fichiers imprimeurs

• Aide en ligne - livret explicatif et aide générale

• Base de données

• Interaction avec le module de calcul • Gestion des PDF de la déclaration (semi-dynamique)

• Support et mise en production

21. MISE À JOUR DU MODULE DE STATISTIQUES Le module de statistique a été développé en 2011. Il propose certaines statistiques basées sur des requêtes dans la base de données de Tax-on-Web. La mise-à-jour consiste à maintenir ces requêtes (notamment pour mettre à jour l’année) et éventuellement à adapter les données business, si nécessaire.

22. MISE A JOUR DE L’APPLICATION SUITE AUX MODIFICA TIONS REALISEES DANS D’AUTRES APPLICATIONS.

Tax-on-web est en interaction avec d’autres applications. Par exemple : Zoomit, Taxi, FED IAM, IAM etc. Suite à des modifications nécessaires pour le bon fonctionnement des autres applications, Tax-on-web doit s’adapter également.

c. Indications quant à la future maintenance évolutive Evolutions possibles : - Création de nouveaux wizards avec pour but d’aider les utilisateurs au remplissage de leur déclaration. - Mise à jour des déclarations disponibles en (quasi) real time suite à des modifications – p.ex. fusion – scission des dossiers, création de nouveaux dossiers. L'application TOW est toujours susceptible d'être améliorée et son évolution peut se faire à différents degrés et dans des délais encore à déterminer.


III. Taxi


L’application Taxi a été lancée en 2005 dans le cadre de la modernisation des outils de traitements de l’impôt IPP en s’alignant au mieux sur les objectifs du plan Coperfin. Il s’agit une application de back-office pour les agents taxateurs en charge de l’établissement de l’impôt des personnes physiques (IPP) et de l’impôt des non-résidents des personnes physiques (INRpp) et également pour la réalisation d’autres travaux de taxation ou de vérification liés à ces impôts. Tax-On-Web récolte directement les données numérisées des déclarations IPP alors que Scanfin ne numérise que des déclarations IPP papier. En ce qui concerne l’IPP, il existe également le système des propositions de déclaration simplifiée où l’Administration propose aux contribuables IPP les données à enrôler. Ces propositions papier sont traitées au départ de TAXI afin d’en assurer le calcul et l’envoi. Sauf avis contraire du contribuable, cette proposition est assimilée à une déclaration. Toutes ces déclarations (y compris propositions) arrivent dans l’application Taxi pour traitement. Taxi automatise donc le chargement des déclarations « numérisées » et permet dans un bon nombre de cas l’enrôlement automatique de ces déclarations. Certaines de ces déclarations sont par contre bloquées ou arrêtées afin d’être vérifiées par un agent. Le blocage d’une déclaration est la conséquence de l’application d’un ensemble de filtres spécifiques, incorporée dans un module indépendant. Ces filtres peuvent détecter une différence entre les données déclarées et les éléments connus par le SPF (notamment issues de BelcotaxOnWeb), des incohérences dans la déclaration,… . Outre ce travail d’établissement de l’impôt, l’application assiste également l’agent taxateur dans la réalisation de tâches plus ponctuelles comme des procédures de dégrèvement d’office, de la détermination d’un déficit d’indiciaire ou des procédures des sanctions d’infractions à la loi fiscale… Les composantes : portails et process Toute cette gestion est supportée par l’application Taxi qui est composée, d’une part, de quatre portails : « Agent taxateur», « Chef de service », « business » et « backoffice-admin », d’autre part, d’un ensemble de processes batch ou continus, qui concourent ensemble aux traitements backoffice de l’IPP et de l’INR/pp. Le portail « Agent taxateur» permet à l’agent taxateur d’effectuer son travail de taxation et en particulier les tâches qui lui sont attribués via le portail chef de service. Ce travail consiste notamment en:

• le traitement de la mise à l’enrôlement desdits dossiers; • le traitement des amendes administratives; • le traitement des impositions d’office.

Certaines tâches d’enrôlement ou d’amendes sont contrôlées par un système de workflow pour garantir un meilleur contrôle interne de ces processus business. Pour effectuer ces traitements ou tâches, l’utilisateur dispose de diverses fonctionnalités internes ou externes à l’application :

• calcul des cotisations à enrôler ou des quotes-parts • visualisation de documents Filenet (déclaration SCANFIN, annexes scannées,

réponses PDS, archives des courriers créés ci-après…);


• création et archivage de courriers via une application inter-active (déficit indiciaire, absence de déclaration, dégrèvement d’office…) ;

• visualisation des données de BelcotaxOnWeb ; • …

Le portail chef de service permet au dirigeant d’un service de taxation IPP ou INR/pp de répartir la charge de travail entre les différents membres de son équipe suivant des critères basés sur la nature des dossiers ou des tâches à réaliser (par.ex validation des workflow). Divers rapports relatifs à l’enrôlement aux amendes ou à la charge de travail sont disponibles en vue d’assurer un suivi optimal des travaux de taxation des agents et du service dans son ensemble. La partie ‘portail Business’ permet à certaines personnes :

• de suivre globalement l’enrôlement des dossiers et l’injection des déclarations ; • de planifier les enrôlements, c’est-à-dire, de sélectionner un ensemble de dossiers à

enrôler en respectant certains critères (balance globale devant être sous un certain seuil, fonction de l’origine de la déclaration, …) ;

• de gérer le code de la déclaration qui sont calculables et/ou enrôlable • de réinitialiser le traitement d’un lot de dossiers.

Enfin, le portail « backoffice-admin » est destiné à gérer les processes décrits ci-après Les process continus et batchs assurent le fonctionnement intégré de l’application. Les déclarations numérisées sont chargées en continu alors que les déclarations TOW ou PDS font l’objet d’un chargement batch. Vu la grande quantité de déclarations numérisées à traiter après les périodes de souscription (entre 2.000.000 et 3.000.000), leur traitement et leur calcul est effectué par des process continus. Le fonctionnement de TAXI est basé sur un signalitique externe, dénommé EXERCICE et hébergé sur mainframe avec lequel il se synchronise périodiquement via des batchs ou en ligne dans l’utilisation du portail agent taxateur.


Maintenance adaptative La maintenance récurrente annuelle comprend les changements techniques nécessaires pour modifier l’application Taxi du millésime précédent afin qu’elle puisse traiter les déclarations du millésime suivant. Elle a pour objet de mettre à jour les différents composants de l’application (notamment : portails, processes batchs et continus) sur base des modifications législatives, organisationnelles, ou techniques liées à l'IPP et l'INR/pp. Chaque année avant que l’équipe projet puisse commencer l’analyse et le développement de la nouvelle version, une série de tâches doivent être effectuées afin de rendre notamment l’environnement de développement opérationnel. Ci-dessous sont reprises les activités principales liées à cette phase de démarrage.

1. Configuration des outils (Setup code source,…) Taxi comprend une application par année, ce qui permet de réaliser des évolutions techniques, fonctionnelles sans devoir intégrer ces changements pour toutes les versions


millésimées (base de données, …). Dans Starteam, est donc créé un nouveau code base, basé sur la dernière version stable de l’année précédente. Tous les bugs fixés après ce « recopiage » doivent être reportés dans les nouvelles sources. A cette fin un label est créé dans l’année N-1 pour délimiter le point de démarrage de l’année N, ce qui facilite les modifications ultérieures. Dans Starteam est donc créée la structure FUP avec un pré-remplissage des sources de l’année N-1. L’application Taxi repose sur deux bases de données : une qui est indépendante de l’année et qui est partagée entre les différentes applications Taxi, une autre qui est propre à un exercice donné. Pour la nouveau millésime, il faut donc créer la base de données et la charger avec certaines données comme par exemple la récupération des adresses des dossiers, … .

2. Mise à jour des environnements de développement Les environnements de développements sont vérifiés et adaptés afin de pouvoir construire la nouvelle version de l’application. Il s’agit ici d’adapter et/ou vérifier les configurations des serveurs weblogic, apaches,… Afin de faciliter le suivi des requêtes de Delivery Management pour les différentes applications Taxi, un nouveau projet Taxi est créé par année dans l’application DM.

3. Initialisation de la demande de projet Lors de la phase de démarrage, une série d’activités de gestion de projet doivent également être prévues afin de préparer au mieux le nouveau millésime. Il s’agit ici d’organiser par exemple le kick off du projet, de déterminer avec le SPF Finances le premier planning mais également les priorités pour ce millésime.

4. Déclaration du nouveau millésime Les déclarations fiscales changent d’année en année. Ces changements législatifs induisent des modifications dans le code, dans la base de données et dans les fichiers de propriétés de l’application. Ces changements concernent l’ajout/modification/ suppression de codes. Il s’agit donc dans cette partie d’adapter l’application afin de prendre en compte l’ensemble de ces changements législatifs.

5. Adaptation à l’environnement technique L’infrastructure et les différentes briques sur lesquels l’application Taxi repose évoluent. Ces modifications doivent être intégrées dans l’application afin d’être en phase avec l’environnement technique du SPF Finances. Cela comprend des mises à jour pour des versions mineures du framework CCFF, des changements de la version de DB2, …. L’adaptation technique envisagée dans cette offre couvre les modifications mineures liées à l’infrastructure actuelle du SPF Finances. Si des adaptations techniques exceptionnelles non-prévues initialement s’avéraient nécessaires, une estimation de la charge de travail devra être faite séparément par l’équipe projet et sera soumise au SPF Finances pour validation.

6. Fonctions d’importation Scanfin/TOW/PDS L’application Taxi interagit avec les applications PDS, TOW et Scanfin. Les différentes déclarations de ces trois applications sont importées dans l’application Taxi par deux canaux différents, d’une part PDS et TOW et d’autre part SCANFIN.


Pour l’interaction avec Scanfin, le schéma XML de l’interface doit être mis à jour afin de tenir compte des évolutions législatives de la déclaration. Les déclarations arrivent par lot dans un mécanisme de flux. L’interaction avec TOW/PDS se déroule différemment, l’application Taxi vient directement lire dans la base de données de TOW les déclarations. Ces déclarations sont stockées sous format XML. Ce fichier XML est également mis à jour chaque année pour refléter la déclaration. Ces changements doivent être pris en compte par le module qui convertit la déclaration TOW en une déclaration Taxi.

7. Process de Taxi L’application Taxi comprend au moins une quarantaine de processus (batch) pour une année. Certains de ces batchs interagissent avec d’autres applications qui représentent pour Taxi la source officielle de certaines données. L’application Taxi interagit notamment avec les signalétiques AJ/EX, NPP, Sitran, les numéros de compte,… Toutes ces interactions doivent être adaptées afin d’aller sur la bonne source annuelle des données. Les « process » de synchronisation doivent être mis en place et testés.

8. Livraisons et suivi de mise en production – supp ort aux tests d’acceptance

Afin d'optimaliser le processus de livraison en production Taxi, un support sera fourni au SPF Finances pour ce qui est des tests d'acceptance ainsi que de la livraison et du suivi en production (livraison des modules applicatifs et de la documentation d'installation, suivi des requêtes dans Delivery Management).

9. Tests fonctionnels Toute modification, même mineure, peut entraîner l’apparition de bugs. L’application Taxi, de part sa criticité, ne doit pas contenir de bugs impactant le travail des utilisateurs (agents, …). A cette fin, une batterie de tests existe (automatiques et manuels) et est exécutée sur la nouvelle application afin de s’assurer de son bon fonctionnement. Cette batterie de tests doit être maintenue afin de tourner correctement sur la nouvelle application. Les données mêmes des tests doivent être mises à jour (enlever les codes qui ont disparu, ajouter les nouveaux codes,…).

Support opérationnel et gestion des incidents L’application Taxi est indispensable à l’exécution des missions fiscales du SPF Finances. La multitude et la variété des cas traités par TAXI impliquent l’occurrence régulière de problèmes de production qui peuvent avoir un impact financier important. Préalablement avant toute intervention, un diagnostic « high level » permet de déterminer l’équipe la plus appropriée pour résoudre l’incident (ICT operations, équipe de développement, une autre application comme Belcotax, SITRAN, …). Si un incident survient, une équipe doit être rapidement disponible en vue d’en identifier l’origine et de le dispatcher à qui de droit. L’expérience montre que l’équipe de développement a une connaissance globale suffisante pour accomplir cette mission. Ces suivi et gestion concernent les différentes millésimes de Taxi (5 années sont supportées). En particulier, il faut veiller à ce que les 7 millions de dossiers soient effectivement traités, calculés et enrôlés avant le délai de prescription.


Outre ce support de gestion des incidents et autres, il y a lieu de prévoir support complémentaire en vue d’améliorer les fonctionnalités existantes aux niveaux de la convivialité, du traitement de cas particuliers….


a. Evolution fonctionnelle Voici une liste indicative des évolutions fonctionnelles actuellement envisagées pour l’application.

1. Signalétique

A l’avenir, le SPF Finances envisage de remplacer les signalétiques AJ/EX et NPP (mainframe) par un signalétique relationnel « entité fiscale » basé sur Sitran.

2. Utilisation des nouveaux échanges automatisés de s données et exploitation optimale des bases de données

L’objectif est de remplacer les actuels échanges papier. Un exemple est l’échange électronique de données avec la Banque Carrefour Sécurité Sociale en ce qui concerne les données relatives aux revenus d’intégration sociale. Ces échanges automatisés de renseignements permettront de calculer les moyens d’existence nets, notamment en vue de la vérification des personnes à charge. Les échanges automatisés des données permettront de solutionner certains obstacles légaux. Ainsi, une exploitation des bases de données permettra de solutionner la problématique des contribuables sous administration provisoire. Taxi devra permettre l’envoi de la déclaration, de la PDS ou de tout acte de procédure à l’Administrateur provisoire, y compris l’avis d’amende. A titre de dernier exemple, en ce qui concerne les mandataires, TAXI assurera la gestion de leur mandat et de leurs coordonnées. Un échange optimal des données permettra d’augmenter le « préremplissage » des données dans TOW. Un « préremplissage » accru contribuera à la simplification administrative pour les citoyens.

3. Implémentation de la signature électronique dans TAXI L’automatisation accrue des actes de procédure et des autres courriers nécessite une solution à la problématique de la signature électronique. Celle-ci sera légalisée afin d’éviter tout risque de contentieux. TAXI permettra de signer électroniquement tout acte de procédure et tout courrier dont l’envoi est centralisé.

4. Adaptation TBT STIRCO et automatisation des code s statistiques


Actuellement, TAXI fait mensuellement l’objet d’une extraction de données de type statistiques dans le cadre du processus TBT. Quelques modifications seront réalisées en vue de limiter le processus d’extraction TBT aux taxrecords liés à un traitement de type gestion. Les taxrecords liés à un traitement de type « contrôle » seront désormais liés à STIRCO. A l’avenir, l’objectif est d’automatiser les données statistiques sans intervention de l’agent.

5. Gestion des transferts de dossiers entre les Adm inistrations P et PME Sur base d’un processus déterminant un signal de départ, TAXI gèrera et planifiera le transfert des dossiers entre les Administrations P et PME. TAXI fera en sorte d’accompagner ces transferts de la façon la plus automatisée possible.

6. Extension de l’Intégration de TAXI en vue de la constitution d’un dossier unique basé sur l’entité fiscale

Dans un premier temps, TAXI deviendra un outil « multi-exercices ». Ensuite, l’intégration avec les autres applications sera réalisée afin de permettre la constitution du dossier unique de chaque entité fiscale. Est notamment visée l’intégration avec STIRCO, WF Contentieux et le dossier permanent digitalisé DOCTRAN. TAXI permettra ainsi à l’utilisateur d’avoir accès à l’ensemble du dossier unique d’une entité fiscale. Il aura donc accès à l’ensemble du dossier même en cas de changement du bureau compétent. Le nouveau service pourra donc gérer l’ensemble du dossier, y compris l’enrôlement des suppléments d’impôt relatif aux exercices d’imposition pour lesquels il n’était pas compétent. TAXI tiendra donc compte de la nouvelle approche en matière de gestion des compétences. L’INR est bien sûr concerné par cette intégration.

7. Evolution de TAXI vers un instrument collaborati f entre chaque intervenant TAXI deviendra un instrument collaboratif entre chaque intervenant. Ainsi, les Administrations Pet PME sont composées de services de gestion, de contrôle et de contentieux. En tant qu’instrument de communication entre les utilisateurs, TAXI doit permettre l’interactivité entre les agents chargés de la gestion, du contrôle et du contentieux. En d’autres termes, une fois que les tâches attribuées à chaque service sont déterminées dans un processus, TAXI doit devenir un instrument de coordination. TAXI, en tant qu’instrument collaboratif, permettra également le télétravail et un meilleur travail à distance entre les personnes. A cet égard, la digitalisation complète des documents entrants sera un facteur de succès. Le suivi du travail effectué à distance par les agents sera assuré par TAXI.

8. Gestion automatisée des courriers

Une gestion automatisée des actes de procédure et des différents courriers sera implémentée dans TAXI. Par une exploitation optimalisée de l’ensemble des bases de données disponibles au sein du SPF Finances, TAXI sera doté d’une fonctionnalité de rédaction des documents de procédure, notamment les demandes de renseignements, les avis de rectification, etc…


TAXI pourra gérer l’envoi et l’archivage centralisé de ces documents ainsi que le suivi des délais légaux liés aux actes de procédure. TAXI offrira la possibilité à l’utilisateur de joindre un document à tout document envoyé centralement. La gestion automatisée des courriers dépendra également d’une digitalisation optimale des documents entrants.

9. Coperfin 2.0 Le fonctionnement global et actuel de l’application devra également être adapté aux nouveaux processus business en cours d’implémentation ainsi qu’à la future organisation par groupe cible des administrations fiscales (Particuliers, PME et Grandes entreprises)

10. Intégration d’un système de gestion de gestion de rules Ce système de gestion de gestion de rules offrirait la possibilité au business de gérer lui-même la mise en œuvre des filtres (voir description fonctionnelle) tant en terme d’activation de contenu et suivi mais également de pour voir piloter sans intervention du développement le process de workflow (exemple d’outil : Business Rules Management systems ILOG)

Evolution technique

1. Modes dégradés et disponibilité

Les nouvelles intégrations avec les applications extérieures devront d’emblée proposer un mode dégradé pour éviter des pertes de disponibilité.

2. Dépendances structurelles techniques

a) FUP-ITIL (gain de temps) Passer Taxi dans FUP-ITIL nous permettra de gagner du temps pour les intégrations acceptance, diminuant ainsi les temps de latence pendant les périodes de préparation pour les PDS et le lancement des portails.

b) Data and data structure management (gain de temps)

Certaines requêtes telles que des créations de vues ne sont pas toujours indispensables. Il faut analyser ce qui n’est pas indispensable et supprimer ces demandes de delivery management (à remplacer par une meilleure architecture logicielle). Restores acceptance : il s’agirait de créer des subset et/ou des procédures automatiques pour remplir l’acceptance avec des data permettant les tests d’intégration et fonctionnels de taxi. Organisation de la taille DB (gain d’espace) : Il s’agit de faire un cadastre des tables directement utilisées par taxi et d’autres qui doivent absolument rester online pour permettre un archivage annuel et ainsi un contrôle de l’espace occupé.


IV. Proposition de Déclaration Simplifiée (PDS)

a. Description fonctionnelle Pour l’exercice d’imposition 2010, un projet pilote a été mené par le SPF Finances afin d’envoyer une proposition de déclaration simplifiée de manière ciblée à un nombre limité de contribuables soumis à l’impôt des personnes physiques (IPP). Via ce projet pilote, près de 5000 propositions de déclaration simplifiée ont donc été envoyées directement aux citoyens sans que ceux-ci doivent intervenir. Lors de l’exercice 2011, le SPF Finances a étendu ce projet pilote et augmenté de manière conséquente le groupe cible (700.000 déclarations). Outre ces 700.000 déclarations PDS, 450.000 déclarations de type 9A ont été générées. Lors de l’exercice 2012, le groupe cible avait été étendu, et le retour d’expérience de 2011 sur le pré-remplissage intégré. Cela a permis d’envoyer environ 1.500.000 PDS et d’avoir un retour très faible avec un taux de +- 5 %. Les développements entrepris pour la Proposition de Déclaration Simplifiée (PDS) en 2012 ont été réalisés avec le souci de permettre une éventuelle extension. Le cadre applicatif de base est conçu pour supporter un élargissement du groupe cible. Ce cadre technique est un élément important et ne devrait pas restreindre les différentes évolutions puisque la définition d’un nouveau groupe cible peut être facilement intégrée. Pour l’exercice 2013, le groupe cible a été étendu aux contribuables bénéficiant de revenus compris dans des rentes viagères (codes 1158/2158 et 1159/2159) et/ou ayant effectué des libéralités (codes 1393/2393 et 1394) : ces codes sont présents dans BOW, cette extension concerne environ 150.000 pds supplémentaires. Des nouveautés sont apparues : - impression de l'identité des personnes à charge sur la pds - visualisation de l'identité des personnes à charge dans Taxi - visualisation de l'identité des personnes à charge dans TOW - détermination des personnes à charge : exploitation des informations transmises par les cpas pour déterminer les ressources des membres du ménage (codes intégrés dans BOW en 2013, exploitables en 2014) - scannage des pds renvoyées aux services de taxation par les contribuables + archivage dans Taxi et dans myminfin - migration technique de AJ vers l'entité P liée à Sitran - sur base de l’identité fiscale, il est prévu de générer le fichier imprimeur.

b. Cycle de vie recurrent L’application pour les propositions a été réalisée pour fonctionner de manière multi-exercices. Cependant quelques adaptations sont nécessaires pour fonctionner correctement à chaque nouvel exercice d’imposition: • Mettre à jour certaines propriétés • Configurer les différents filtres avec les bonnes valeurs (codes de la déclaration supportées, exclus,...) • Retester l’ensemble de la chaîne


c. Indications quant à la future maintenance évolutive En 2014, le SPF Finances pourrait encore étendre ce projet et augmenter le groupe cible. Cependant l’extension du groupe demande de pré- remplir un nombre croissants de champs. La récupération de ces données demande des modifications des programmes existants. Le présent projet a donc pour but d’augmenter la portée du groupe cible et d’améliorer l’automatisation des processus liés à la proposition de déclaration simplifiée. De manière plus globale, il faut également prendre en compte tous les efforts entrepris pour inciter le citoyen à souscrire une déclaration de manière électronique par ses propres moyens. L’élargissement de la PDS doit idéalement s’intégrer dans les démarches entreprises pour élargir le cadre de TOW en orientant les développements pour qu’ils soient profitables aux deux applications. Cette combinaison pourrait conduire à une réduction importante de la diffusion des déclarations ‘papier’ destinées à être scannées. Parallèlement à l’aspect technique, l’élargissement du groupe sera vraisemblablement influencé par les données qui sont actuellement en notre possession puisqu’elles impactent la couverture éventuelle d’une autre catégorie de contribuables. A priori, il n’est pas aisé d’affirmer que nous disposons de suffisamment d’informations pour diffuser une proposition de qualité à d’autres catégories de contribuables que celle visée initialement, à savoir, ‘les pensionnés’. En effet, l’orientation initiale vers le groupe des pensionnés ne sollicitait qu’un nombre limité d’éléments, on peut facilement imaginer qu’une orientation vers une autre catégorie nécessitera de disposer de plus d’informations. La maintenance évolutive consiste à réaliser des modifications fonctionnelles de l’application existante. Les différentes modifications nécessaires sont basées d’une part sur la volonté d’étendre le groupe cible et sur la pérennisation du processus dans le temps. L’extension du groupe cible peut nécessiter des modifications de l’application : • L’augmentation du nombre de déclarations qui doivent être envoyées sur la même période de temps implique des optimisations des processus afin de pouvoir supporter la cadence. • Certaines extensions du groupe nécessitent des adaptations en termes de pré- remplissage de la déclaration (par exemple les revenus immobiliers). L’extension aux salariés ajouterait +- 1.500.000 propositions de déclarations simplifiées, cela signifie un doublement du volume. Or l’ensemble des déclarations doit être envoyé dans une fenêtre de temps restreinte. Afin d’atteindre un nombre de 3.000.000 de propositions (nombre actuel + les salariés), il faut revoir les processus de la chaîne afin d’accélérer la cadence. Il s’agit des process PDS eux-mêmes mais également des process Taxi qui injectent les déclarations et les calculent.


V. Calculatrix (Calcul IPP)


Deux modes

L’application Calcul IPP est développée en Java. Elle calcule l’Impôt des Personnes Physiques, résidentes et non résidentes, en mode batch et en mode web. En mode web, l’utilisateur souhaite obtenir un calcul d’impôt en fonction des données qu’il introduit. Le mode web est emprunté par Tax-on-web, Tax-calc, Taxi et WebCalculation. L’output est constitué d’une note de calcul, éditée à l’écran et imprimable localement. Cette note de calcul comprend le détail du calcul de l’impôt. Le mode batch s’exécute de manière automatique : toute déclaration d’impôt valide introduite dans Taxi est calculée par le système. Le résultat est stocké dans une base de données DB2. Régulièrement, Taxi sélectionne pour enrôlement un ensemble de déclarations ainsi pré-calculées. L’application Calcul IPP assure alors la majeure partie de l’enrôlement. Dans ce cadre, elle produit deux outputs principaux : le fichier d’édition de l’avertissement-extrait de rôle (AER) et le fichier pour l’ICPC, c’est-à-dire l’Administration Générale de la Perception et du Recouvrement (AGPR). L’AER comprend non seulement la note de calcul précitée, mais également les données d’identification du contribuable (issues de Sitran), des services compétents (issues d’Annucomp) ainsi que les données propres à l’enrôlement (article de rôle, date d’exécutoire, etc…). Cet AER est stocké au format .pdf dans FileNet (accessible via MyMinFin et Taxi). En outre, il est soit imprimé et envoyé au contribuable par FedoPress, soit mis à sa disposition via Zoomit. Le fichier pour l’ICPC contient toutes les données nécessaires à l’AGPR pour procéder au recouvrement de l’impôt ou à son remboursement. Le système ICPC fonctionne en Cobol. Les données issues de l’application Calcul IPP (Java/DB2) sont donc traduites dans ce langage.

Trois modules

L’application Calcul IPP comporte trois modules : la Validation, le Calcul proprement dit et l’Edition. La Validation consiste en un ensemble de règles qui veillent à ce que les données soumises pour calcul ne comportent aucune erreur vis-à-vis des dispositions fiscales existantes.

En mode web, la Validation informe l’utilisateur de son erreur et empêche l’enregistrement des données tant que l’erreur n’est pas corrigée.

En mode bacth, la Validation intervient aussi, principalement lorsqu’il s’agit d’une déclaration scannée. Celle-ci n’a en effet pas bénéficié d’une validation poussée avant son introduction dans Taxi.

Le Calcul proprement dit effectue le calcul de l’impôt sur base des données validées. Aucune erreur technique n’est donc susceptible de se produire.

Enfin, l’Edition édite la note de calcul à l’écran et génère le fichier d’édition pour stockage dans FileNet et son envoi à FedoPress. Elle génère également le fichier pour l’ICPC.



Le business lié au calcul de l’impôt est fondamentalement annuel : la législation fiscale s’applique en effet par année (exercice d’imposition). Il s’ensuit qu’une application Calcul IPP complète doit être livrée chaque année. En outre, cinq applications coexistent en permanence : celle de l’exercice d’imposition en cours et celles des quatre exercices d’imposition précédents. A chaque exercice d’imposition, le gouvernement modifie ou supprime des règles existantes ou en invente des nouvelles. Les analystes business traduisent les textes de loi en analyses. Ces analyses sont enregistrées sur Caliber RM et sur StarTeam. Leur structure en arbre reflète fidèlement la structure du Code des impôts. Chaque analyse est appelée « opération ». Chaque opération est décrite suivant un modèle. Ce modèle comprend, outre la description synthétique en langage naturel du traitement à effectuer, la liste des inputs et des outputs de l’opération, ainsi que son algorithme, dans un langage mathématico-pseudo Java. Si bien que le développeur Java est capable d’implémenter le traitement désiré directement sur base de cette analyse. Chaque analyse fait l’objet d’une quality review par un autre analyste. Il en va de même de l’implémentation.

Chaque modification est testée au moyen de tests unitaires (« white tests ») et de tests complets, qui exécutent des calculs du début à la fin (« grey tests »).

Ces batteries de tests sont exécutées de manière automatique avec les outils HP ALM et Quick Test Pro, fortement customisés pour les besoin de l’application.



Au niveau business

A partir de l’exercice d’imposition 2015, la régionalisation de l’impôt des personnes physiques se développe considérablement. L’application Calcul IPP en est fortement impactée. Non seulement pour l’exercice d’imposition 2015 mais également pour les exercices d’imposition suivants. Le SPF Finances reçoit déjà actuellement des demandes d’avis des régions sur la faisabilité technique de mesures qu’elles envisagent de prendre à partir de l’exercice d’imposition 2016. Cela va inévitablement augmenter la charge de travail puisque, désormais, quatre pouvoirs sont susceptibles d’adopter des mesures impactant le calcul de l’impôt : le fédéral et les trois régions. Et cette charge de travail supplémentaire va être engendrée non seulement par l’augmentation du nombre de mesures mais également par la complexité croissante qu’elles vont induire dans le programme de calcul.

Au niveau ICT

L’application calcul IPP est dépendante de Java, DB2, Weblogic, Annucomp, Sitran, Caliber, HP ALM, Quick Test, Jenkins, etc… Chacune de ces applications et composantes est susceptible d’évoluer, de faire l’objet de mises à jour. A chaque fois, il convient d’adapter l’application calcul IPP pour qu’elle continue à fonctionner. Ces adaptations doit être répercutées plusieurs fois : sur l’application liée à chaque exercice d’imposition ainsi que sur celles relatives aux exercices d’impositions précédents.


Lot 3 (Domaine impôts directs personnes morales + t ransversales Ag Fisc)

Biztax (Stiron lot 1) : Module Font-Office (FO) Biztax (Stiron lot 1) : Modules Back-Office (BO) et Dossier Unique (DU) CalcIsoc Stir-Contrôle Stir-Recherche PRM-on-web

I. Biztax Front-Office (Biztax FO)


1. Généralités L’application BIZTAX frontoffice a été lancée en mai 2011. Cette application offre aux utilisateurs externes – entreprises, asbl et leurs mandataires – la possibilité d’introduire leur déclaration à l’impôt des sociétés, des non-résidents, et des personnes morales par voie électronique. Il est même envisagé de rendre la déclaration électronique obligatoire. L’utilisateur peut remplir en ligne aussi bien le formulaire de déclaration que tous les formulaires annexes (relevés et déclarations). Les données relatives à ces formulaires sont reprises dans une taxonomie XBRL modifiée chaque année. Les éléments et la structure déterminés dans cette taxonomie XBRL sont traduits par l’application en écrans à remplir. Sur ces écrans, l’utilisateur peut introduire non seulement des données structurées mais aussi ajouter des PDF pour les annexes pour lesquelles aucun modèle n’a été élaboré. Les données remplies sont conservées de manière centralisée de sorte que l’utilisateur peut revenir plus tard sur sa déclaration pour la modifier ou continuer à la remplir. Il est possible d’effectuer un contrôle des erreurs à n’importe quel moment. Le calcul de l’impôt dû ou à rembourser est également possible. Le module de simulation ne fait pas partie du présent marché. Les déclarations générées par un logiciel externe peuvent être facilement téléchargées dans BIZTAX, par maximum 25 à la fois, via un fichier "biztax". Ici aussi, il doit être satisfait à une série de contrôles techniques et de contenu. Après introduction de la déclaration, l'utilisateur peut consulter l’accusé de réception, la preuve de la signature des déclarations chargées, les fichiers PDF de la déclaration (y compris tous les formulaires) et chaque annexe PDF jointe séparément à la déclaration. Les adaptations fiscales annuelles à ces déclarations pour les personnes morales ont un impact sur ces applications. Chaque année, une nouvelle version doit être élaborée qui soutient le nouvel exercice d’imposition. Le BIZTAX frontoffice est une application externe dont le service ne peut pas être interrompu.


Pour l’exercice d’imposition 2011, plus de 315.000 déclarations à l’impôt des sociétés ont été introduites via BIZTAX. Depuis l’exercice d’imposition 2012, les déclarations peuvent être introduites via BIZTAX, non seulement à l’impôt des sociétés (ISoc) mais également à l’impôt des non-résidents/sociétés (INR/soc) et à l’impôt des personnes morales (IPM). Pour l'exercice d'imposition 2012, plus de 370.000 déclarations ont été introduites via BIZTAX. Le nombre total de déclarations à introduire est d’environ :

• Impôt des sociétés :450.000 • Impôt des personnes morales : 100.000 • Impôt des non-résidents/sociétés : 12.000.

Chaque année, ce nombre augmente de 3% en moyenne. L’application interne BIZTAX backoffice light permet aux agents contrôleurs et taxateurs internes de consulter les déclarations introduites via BIZTAX. Ils peuvent non seulement consulter la déclaration et ses annexes, mais aussi l'accusé de réception reçu par l'utilisateur. BIZTAX backoffice light n’est plus utilisé que pour les exercices d’imposition 2011 à 2013 compris. Les déclarations et les annexes introduites dans ces trois types d’impôt doivent être traitées par le backoffice. Les déclarations introduites par voie électronique sont transférées, jusqu’à l’exercice d’imposition 2013 compris, vers le backoffice actuel – CVVEN – pour traitement ultérieur des déclarations. À cette fin, les données sont extraites des déclarations déposées, puis converties et envoyées au mainframe Bull. Là, elles sont traitées en batch par le backoffice. Le fichier personnes morales (PM) interne est également actualisé. Le transfert des déclarations vers le backoffice de BIZTAX ne fait pas partie du présent marché. L’application est intégralement disponible dans les trois langues nationales, le français, le néerlandais et l’allemand. L’application doit être compatible avec les systèmes d’exploitation et les navigateurs courants. BIZTAX frontoffice est accessible via le portail du SPF Finances. Une disponibilité (24h/24 et 7j/7) de l’application est exigée.

2. Accès à l’application Avant d’avoir accès à l’application BIZTAX, chaque utilisateur doit s’authentifier. Cette authentification se fait à l’aide d’un certificat numérique. Ce certificat est intégré dans la carte d’identité électronique belge (eID). L'utilisateur peut aussi utiliser des certificats émanant d’une des autorités de certification suivantes: GlobalSign et Isabel. Toutes les déclarations générées et complétées restent modifiables tant que l’utilisateur utilise la même eID ou le même certificat. L’utilisateur peut consulter sa déclaration, son accusé de réception et les fichiers PDF de sa déclaration (y compris tous les formulaires) et toutes ses annexes. Ce qui précède n’est cependant pas possible en cas d’utilisation du système de gestion des accès et des mandats FedIAM. Dans ce cas, les dossiers sont accessibles aux utilisateurs considérés comme des représentants légaux, des mandataires ou des représentants d’un mandataire.

3. Remplissage en ligne des déclarations

3.1. Recherche Des critères de recherche peuvent être introduits sur l'écran de recherche pour rechercher une déclaration précise. En cas d’introduction de valeurs incorrectes dans un champ, une icône d’erreur s’affiche au-dessus du champ concerné et si des erreurs ont été faites au niveau de plusieurs champs, l’icône d’erreur s'affiche en haut de l'écran après avoir cliqué sur le bouton "Chercher déclarations". Pour que l’action de recherche puisse s’exécuter, il faut que les champs soient correctement remplis.


Après le lancement d’une recherche, l’utilisateur voit s’afficher à l’écran une liste des déclarations trouvées. Si la liste est trop longue, elle est scindée et s’affiche sur plusieurs pages. La liste peut être triée sur chaque colonne en cliquant sur le titre de la colonne. Si une action de recherche ne donne aucun résultat, un message indiquant qu’aucune déclaration n’a pu être trouvée s’affiche à l’écran. Si l’utilisateur souhaite ouvrir une déclaration précise, il lui suffit de la sélectionner dans le tableau des résultats et d’ensuite cliquer sur le bouton ”Ouvrir déclaration”. En utilisant le bouton "Download XLS", l’utilisateur peut télécharger la liste des résultats affichée à l'écran sous la forme d'un fichier Excel. Si l’utilisateur n’a pas trouvé la déclaration qu’il cherchait, il peut créer une nouvelle déclaration en cliquant sur le bouton ”Créer autre déclaration”. En cliquant sur ce bouton, l’utilisateur est redirigé vers l’écran "Créer autre déclaration". Ce bouton n’est visible pour l’utilisateur qu’après une action de recherche. Si une des valeurs complétées lors de la création de la déclaration n’est pas correcte, par exemple la date de début de la période imposable, la déclaration peut être supprimée. Par la suite, une nouvelle déclaration peut être créée avec des données correctes. Ce qui précède est adapté lorsqu’il est fait usage du système de gestion des accès et des mandats FedIAM. Dans ce cas, les dossiers seront accessibles aux utilisateurs considérés comme des représentants légaux, des mandataires ou des représentants d’un mandataire. Un moteur de recherche adapté offre les deux possibilités de sélection en tenant compte des informations disponibles à partir du système des mandats. Les autres fonctionnalités restent inchangées.

3.2. Remplissage La déclaration peut être remplie par étape, en utilisant les différents onglets qui abritent les données signalétiques, la déclaration et les annexes. Les données signalétiques et certaines données fiscales liées au numéro d’entreprise sont déjà disponibles et sont préremplies dans la déclaration. Les données remplies sont sauvegardées centralement, de sorte à permettre à l’utilisateur de modifier ou finaliser sa déclaration. L’écran de remplissage de la déclaration comprend, outre un menu déroulant, quatre parties distinctes: les informations contextuelles de l’entreprise, la barre de navigation des onglets, les boutons correspondants à des fonctionnalités spécifiques et les champs à remplir du formulaire de déclaration et des formulaires annexes scindés en onglets. Chaque bouton est lié à une fonctionnalité distincte. Le bouton "Enregistrer" permet d’enregistrer temporairement une déclaration (partiellement) remplie. Quand on passe d’un onglet ou d’un menu à un autre, la déclaration est automatiquement temporairement enregistrée. Le bouton "Liste des erreurs" redirige l’utilisateur vers la liste des erreurs de la déclaration en cours et l’endroit à partir duquel il peut lancer le contrôle des erreurs. Lorsque l’utilisateur clique sur le bouton "Vider", après une demande de confirmation, tous les champs de la déclaration sont entièrement vidés (les données de l’entreprise dans l’onglet Id seront à nouveau remplis comme en cas de création d’une nouvelle déclaration). Le bouton "Ouvrir le document PDF" permet d’ouvrir une déclaration déjà (partiellement) remplie dans un document en format PDF. Ce document PDF est généré dans la langue utilisée à ce moment dans l’application. Les champs à remplir du formulaire de déclaration et des formulaires annexes regroupés sous différents onglets et dans lesquels l’utilisateur peut saisir des chiffres et du texte et qui servent également à joindre des annexes en format PDF. Dans certains champs, l’utilisateur doit introduire des montants. Sous peine de générer l’apparition de messages d’erreur à l'écran, ces montants doivent toujours satisfaire à certaines règles. Le montants sont, par exemple, limités à 14 chiffres et deux décimales. Les totaux des champs (entourés en orange) sont calculés et remplis automatiquement. Dans certains tableaux, on trouve un bouton "Ajouter une ligne". Il sert à ajouter une ligne dans le tableau, qui doit être remplie avec les données correctes. Un tableau n’est donc pas limité à un nombre fixe de lignes. Un nombre limité d'annexes non standardisées pouvant être jointes à la déclaration a également été prévu pour lesquelles un fichier PDF peut être chargé en cliquant sur le bouton "Ajouter". Quand l'utilisateur clique sur ce bouton, un écran pop-up apparaît dans lequel l’utilisateur peut sélectionner


l’annexe qu’il souhaite ajouter à sa déclaration. Une fois l’annexe ajoutée, l’utilisateur peut l’ouvrir en utilisant le bouton "Ouvrir" ou la supprimer de la déclaration en utilisant le bouton "Effacer”. Quand une annexe est ajoutée, le bouton "Ajouter” devient indisponible; quand aucune annexe n’est ajoutée, les boutons "Effacer" et "Ouvrir" sont indisponibles.

3.3. Valider Un contrôle des erreurs peut être effectué à n'importe quel moment. Le contrôle des erreurs comprend une série de contrôles techniques et une série de règles de validation de contenu intégrées dans la taxonomie XBRL et de contrôles contenus dans le module externe Calculatrix. L’intégration de ce module externe Calculatrix fait partie du présent marché, ce qui n’est pas le cas de son développement. Un ordre chronologique fixe d’exécution des règles de validation a été défini. Certaines règles donnent lieu à l’envoi d’un statut "bloqué". Lorsque c'est le cas, l'utilisateur ne peut plus rien corriger et la déclaration est automatiquement vidée. Lorsque c’est possible, un lien est établi entre le message d’erreur de la liste des erreurs et le champ concerné par l'erreur. Les champs entachés d’une erreur sont marqués et une fenêtre contenant le message d’erreur s’affiche sur les écrans de remplissage.

3.4. Simuler Quand la déclaration se voit attribuer le statut "Sans erreurs" ou "Souscrite" l’utilisateur peut demander une simulation d’impôt. Cette simulation d’impôt lui fournit une indication sur le montant estimé de l’impôt. L’écran de résultat comprend le montant d’impôt estimé correspondant à la déclaration effectuée et une icône PDF qui permet de visualiser le calcul détaillé de cette simulation en format PDF. La simulation fait partie de l’application distincte Calculatrix. Seule l’intégration de la simulation fait partie du présent marché.

3.5. Signer Quand la déclaration obtient le statut "Sans erreurs", elle peut être signée via le sous-menu "Souscrire". Après avoir été signée, la déclaration est introduite et il n'est plus possible de la modifier dans BIZTAX. Pour cette souscription, le système utilise une signature PDF basée sur la technologie Adobe LiveCycle. Après avoir été signée, la déclaration reçoit le statut "Souscrite" et elle ne peut plus être modifiée dans BIZTAX. Dès que la nouvelle application interne de traitement des déclarations sera mise en production, il sera possible d'introduire des déclarations rectificatives.

3.6. Consulter Après la signature de la déclaration, plusieurs documents peuvent être consultés en utilisant le sous-menu "Documents de la déclaration". Plusieurs documents peuvent être consultés: toutes les annexes chargées pendant l’introduction de la déclaration en tant que documents PDF, l’accusé de réception sous forme de PDF avec la signature numérique du SPF Finances comme preuve de l'introduction de la déclaration, la déclaration complète (formulaire de déclaration et annexes) sous la forme d’un document PDF avec la signature de l'utilisateur sur la déclaration remplie en ligne, le document XBRL de la déclaration et pour les déclarations chargées, la preuve PDF de l’introduction de la déclaration avec la signature numérique de l'utilisateur. L'utilisateur peut sélectionner le document qu’il veut consulter. Par défaut, le système sélectionne le premier document de la liste. Si l'utilisateur clique ensuite sur le bouton ”Ouvrir”, un écran pop-up apparaît à partir duquel l'utilisateur peut choisir d’ouvrir le document ou de le sauvegarder localement.


4. Charger les déclarations

Outre la création et le remplissage en ligne de sa déclaration, l'utilisateur peut aussi charger directement dans l’application un fichier qui contient une ou plusieurs déclarations. Ce fichier est enregistré localement avec l’extension ".biztax" et peut contenir une ou plusieurs déclarations concernant différents exercices d’imposition ou différents types d’impôts.

4.1. Exigences Ces fichiers doivent satisfaire à une série d’exigences techniques :

• Exigences : structure, format XML, UTF-8, etc. • Maximum 25 déclarations par fichier • Maximum 6 annexes PDF par déclaration • Taille maximum de chaque déclaration de 15 MB

Après son chargement, le fichier "biztax" subit une première validation sous la forme de contrôles techniques. C’est ainsi, entre autres, que le système vérifie si le fichier chargé est techniquement correct et si chacune des entreprises pour lesquelles une déclaration a été chargée est en droit d’introduire une déclaration. Si une des déclarations du fichier chargé est considérée comme non correcte après ces contrôles techniques, l’ensemble des fichiers chargés est considéré comme non valide et toutes les déclarations contenues dans le fichier sont rejetées.

4.2. Contrôles spécifiques Un fichier ayant passé avec succès cette première validation peut être signé par l’utilisateur. L'utilisateur reçoit un PDF qui reprend les numéros d’entreprise, les exercices d’imposition et les dates de fin de la période imposable des déclarations chargées qu’il doit signer et envoyer. Avant de signer définitivement les déclarations du fichier, un premier contrôle de contenu est effectué pour chaque déclaration afin de vérifier si les données qu’elle contient sont correctes. Chaque déclaration doit passer par plusieurs étapes et les contrôles peuvent se faire de manière totalement ou partiellement asynchrone. Aperçu schématisé des contrôles :

Si aucune erreur n’est constatée, la déclaration est signée. Si des erreurs sont trouvées dans une des déclarations du fichier chargé, un message d'erreur s'affiche dans l'aperçu des déclarations chargées.


Les différents statuts pouvant être attribués à un fichier "biztax" chargé sont :

• En traitement : les déclarations sont contrôlées au niveau des erreurs de contenu. • Annulé : le fichier "BIZTAX" contient une erreur qui entraîne le rejet de l’ensemble du fichier et

aucune déclaration n’est souscrite. • Traité : ce chargement a bien été accepté, les déclarations sans erreurs sont souscrites et les

déclarations qui contiennent encore des erreurs de contenu ne sont pas souscrites.

4.3. Souscription La souscription se fait par le biais de la signature d'un fichier PDF en utilisant la technologie Adobe LiveCycle. En l’absence d’erreurs, la déclaration peut être souscrite. Si des erreurs ont été trouvées dans une des déclarations du fichier chargé, un message d’erreur apparaît dans l’aperçu des déclarations chargées. L'utilisateur peut rechercher la déclaration non signée via "Chercher déclarations", ouvrir les déclarations concernées en utilisant « Ouvrir » et retrouver l’erreur en naviguant dans la "Liste des erreurs".

4.4. Consulter les fichiers chargés Une fois la déclaration signée, l'utilisateur peut aussi consulter les documents de déclaration de sa déclaration et demander une simulation d’impôt. Le remplissage en ligne peut aussi toujours être ouvert, mais l’utilisateur ne peut plus rien modifier. Pour chaque paquet chargé, aussi bien avec succès qu’avec des erreurs, l'utilisateur peut consulter un écran récapitulatif a posteriori. Cet écran récapitulatif est le dernier écran que l'utilisateur a vu lors du chargement de ses déclarations. Pour cela, il doit sélectionner le chargement qu’il souhaite consulter sur l’écran de chargement et cliquer sur le bouton "Détails". Les différents statuts qui peuvent être attribués à un fichier biztax" chargé sont les suivants:

• En traitement: les déclarations sont contrôlées par rapport aux erreurs de contenu. • Annulé : le fichier "BIZTAX" contient une erreur qui entraîne le rejet de l’ensemble du fichier et

aucune déclaration n’est souscrite. • Traité : ce chargement a bien été accepté, les déclarations sans erreurs sont souscrites et les

déclarations qui contiennent encore des erreurs de contenu ne sont pas souscrites. Une déclaration chargée qui contient encore des erreurs de contenu, rechargée par la suite, ne peut plus être reprise dans la liste des déclarations chargées dans le fichier « biztax » précédent. Les déclarations ne sont reprises que dans le fichier dans lequel elles ont été chargées pour la dernière fois.

b. Cycle de vie récurrent Pour la version adaptée au nouvel exercice d’imposition, il est fait appel à une aide externe pour un accompagnement au niveau de la gestion des environnements et du roll-out; des tâches dont l’exécution sera de plus en plus confiée à l’équipe ICT du SPF Finances. Il est demandé au partenaire externe de proposer des activités de support et de coaching à cet effet. Des développements complémentaires pourront être réalisés s’ils s’avèrent nécessaires à la mise en production de la nouvelle version de l’application. Un aide externe est également demandée pendant la période de production au cas où des problèmes concernant le fonctionnement de l’application ou des pannes se produiraient. Des développements pourront être confiés au consultant externe s’ils s’avèrent indispensables pour assurer le bon fonctionnement et le fonctionnement correct de l’application. Voici un aperçu des tâches annuelles récurrentes.


1. Adaptations liées à l’exercice d’imposition Chaque année, des changements au niveau de la fiscalité et la mise en place d’un nouvel exercice d’imposition imposent des modifications. Pour chaque exercice d’imposition, il existe des déclarations adaptées y compris leurs annexes. BIZTAX utilise la technologie XBRL (eXtensible Business Reporting Language). Les changements fiscaux annuels sont traduits dans une taxonomie XBRL unique, spécifique à chaque exercice d’imposition qui contient les trois déclarations et toutes leurs annexes. Une taxonomie XBRL reste active pendant minimum trois ans. La taxonomie XBRL est développée par le SPF Finances. Aperçu schématisé de l’architecture de la taxonomie XBRL:

Les précédentes versions de la taxonomie XBRL, y compris la documentation s’y rapportant sont consultables sur le site www.biztax.be à la page « publications techniques » (http://www.minfin.fgov.be/portail2/nl/e-services/biztax/publications.htm#BC). La majorité des fonctionnalités de l’application sont directement adaptées au moment du chargement d’une nouvelle taxonomie XBRL mais certaines exigent toutefois une adaptation des codes. Il faut, au minimum, adapter les fonctionnalités suivantes de l’application :

• Écrans de recherche • Chargement des déclarations • Création des déclarations • Écrans de saisie • Validation des déclarations • Visualisation des messages d’erreur • Lien vers Calculatrix pour l’exécution de certains contrôles et pour une simulation


Les écrans sur lesquels l'utilisateur peut remplir manuellement sa déclaration sont générés à partir de cette taxonomie XBRL et le nouvel exercice d’imposition est automatiquement intégré dans les nouveaux écrans de recherche. Pour cela, on utilise toutes les composantes existantes de la taxonomie XBRL: presentation linkbases, definition linkbases (y compris presentation hypercubes), label linkbases et les formula linkbases pour les totaux. À côté de cela, on utilise aussi un fichier XML contenant des paramètres, un ‘table analyser’, un ‘Xpath generator’ et un ‘XForms generator’. Le lien avec les messages d’erreur et leur affichage sont également liés à ce point. Présentation schématique de la génération des écrans :

Présentation schématique de l’utilisation des formula linkbases pour les totaux dans les écrans de saisie :

4.4.1. Mise à jour de la taxonomie XBRL La taxonomie XBRL est développée et adaptée par le SPF Finances. Dans le but de pouvoir conserver certaines fonctionnalités existantes, les adaptations à la taxonomie XBRL peuvent toutefois exiger de devoir faire appel à une aide. Les modifications architecturales ne sont pas prévues, mais une adaptation majeure de la déclaration ou de ses annexes liée à un exercice d’imposition peut entraîner l’ajout d’un nouveau schéma ou d’un nouvel aspect technique qui requièrent des adaptations de l’application. Dans ce cas, pour pouvoir conserver les fonctionnalités existantes et intégrer le nouveau schéma ou le nouvel aspect technique, des adaptations de l’application peuvent également exiger de faire appel à une aide.

2. Gestion des environnements et déploiement (roll- out) L’application doit fonctionner dans différents environnements y compris la mise en production dans l'environnement de production. Plusieurs installations dans l’environnement d’acceptation pourront être exigées avant que l’application ne soit mise en production. L’installation de l’application se fera via l’application standard du SPF Finances et conformément à FUP-ITIL.


3. Corrections techniques et fonctionnelles nécessa ires qui ont un effet sur le fonctionnement de l’application après l’exéc ution des tests

BIZTAX est une application externe utilisée par environ 20.000 utilisateurs. Chaque année des adaptations doivent y être apportées pour en garantir le bon fonctionnement en tenant compte des changements intervenus sur le marché (OS, navigateurs, javascripts, etc.).

4. Adaptations nécessaires en raison de modificatio ns des standards ICT BIZTAX doit toujours être conforme aux standards ICT. Pour pouvoir le garantir, chaque année, des adaptations doivent être effectuées.

5. Suivi du fonctionnement de l’application et aide , y compris au niveau du diagnostic et de l’implémentation des correction s à l’application, en cas de problèmes après sa mise en production.

BIZTAX frontoffice est une application externe dont le service ne peut pas être interrompu. La non-disponibilité de ces applications dans la version exercice d’imposition 2013 peut mettre en péril le bon fonctionnement du SPF Finances – et plus particulièrement de l’AG de la Fiscalité – et qui plus est considérablement nuire à son image. L'aide externe demandée doit garantir non seulement le suivi du fonctionnement de l’application, mais aussi le support en cas de constatation ultérieure de manquements qui mettent en péril le bon fonctionnement de l’application.

6. Services à fournir Pour chacun des aspects mentionnés plus haut, les services suivants doivent être fournis:

• Analyse fonctionnelle : adaptation des documents d’analyse fonctionnelle et surtout aide fonctionnelle aux développeurs dans le cadre des développements à exécuter

• Architecture, analyse technique, développement et déploiement : un architecte technique adapte les analyses techniques le cas échéant et soutient les développeurs dans l’implémentation de ces adaptations. Les adaptations annuelles n’exigent, en principe, aucune modification de l’architecture. Il faut prévoir la gestion des environnements et le déploiement avant la mise en production de l’application dans les différents environnements (développement, acceptation et production).

• Documentation et transfert de connaissances: la documentation technique doit être actualisée et un transfert de connaissances doit avoir lieu à destination des collaborateurs concernés du SPF Finances. La documentation fonctionnelle (manuel utilisateur, FAQ, vidéos d’instructions et présentations) ne fait pas partie du présent marché.

• Gestion de projet: quatre groupes de pilotage maximum seront organisés par an pour assurer le suivi du projet. Le groupe de pilotage suit l’avancement des services à fournir et surveille la coordination avec les autres applications et composantes utilisées par BIZTAX. Du début des analyses à la mise en production comprise, des réunions de suivi doivent être organisées toutes les semaines ou toutes les deux semaines pour suivre l'avancement et pouvoir faire des corrections ou informer le groupe de pilotage des problèmes et des nouveaux risques dans le cadre de la procédure d'escalade prévue.

• Méthodologie: Le SPF Finances utilise Prince2 et FUP-ITIL. Les produits existants doivent être adaptés dans leur forme actuelle.



Si des évolutions fonctionnelles s’avèrent nécessaires, elles seront identifiées d’une part sur la base du feedback des utilisateurs de ces applications et des questions fréquemment posées au Contact Center et aux business experts de deuxième ligne qui représentent une charge importante de travail, et d’autre part en fonction des facteurs environnementaux en mutation auxquels l’application doit être adaptée. Des évolutions techniques peuvent s’avérer nécessaires si des adaptations sont apportées aux standards ICT. Une provision pour les nouveaux travaux est demandée. La priorisation et la nécessité de nouveaux travaux seront validées au cas par cas par le chef de projet et le groupe de pilotage. Voici quelques évolutions attendues :

• Améliorations dans chacune des fonctionnalités existantes en cas de demande suffisante de la part de l'utilisateur. Cela peut aller de l’ajout de boutons à l'extension effective de la fonctionnalité existante.

• Rendre possible la consultation des données du dossier fiscal de BIZTAX BO (avertissement-extrait de rôle, correspondance, statut du dossier, …) par les utilisateurs dans l’attente d’une intégration dans MyMinfinPro pour les entreprises

• Intégration des demandes d’attestations fiscales qui ressortissent à la compétence des services de taxation ISoc, INR/soc et IPM.


II. Biztax Back-Office et Dossier unique (Biztax BO )

d. Description fonctionnelle BizTax Backoffice permet aux services de taxation de gérer les déclarations à l’impôt des sociétés, l’impôt des personnes physiques et l’impôt des non-résidents/sociétés. Sur la base du planning actuel, le nouveau backoffice sera opérationnel le 1er mars 2014 et pourra traiter les déclarations à partir de l'exercice d’imposition 2014. Les déclarations à l’impôt des sociétés, l’impôt des personnes physiques et l’impôt des non-résidents/sociétés sont introduites par voie électronique par les contribuables ou leurs mandataires via l’application BizTax Frontoffice. Seul un nombre limité de déclarations sont encore déposées sur papier. Les déclarations introduites électroniquement sont ensuite transférées vers le backoffice actuel, CVVen11 pour finalement déboucher sur l’envoi de l’avertissement-extrait de rôle au contribuable. Le projet BizTax Backoffice a pour objectif de renouveler complètement le backoffice existant et de l’élargir. Son renouvellement s’imposait du fait que le backoffice existant est technologiquement dépassé et que de nouvelles fonctionnalités s’avèrent nécessaires.

1. Fonctionnalités BizTax Backoffice comprend les fonctionnalités suivantes:

1. Les déclarations introduites via BizTax Frontoffice sont automatiquement transférées vers BizTax Backoffice.

2. Les déclarations introduites sur papier peuvent être introduites par le gestionnaire de dossier

via BizTax Backoffice; pour les annexes sur papier, un formulaire scan peut être créé pour que les annexes puissent être jointes au formulaire de déclaration sous forme électronique.

3. Les déclarations, introduites par voie électronique par le contribuable ou par le gestionnaire

de dossier, sont vérifiées par rapport à une série de règles de validation. Ces règles de validation se trouvent d’une part dans la taxonomie XBRL (cf. infra), et d’autre part dans l'application externe Calculatrix.

Exemples de validations possibles:

- La déclaration est tardive; - La déclaration comporte un tarif spécifique ou des éléments qui rendent le calcul

automatique de l’impôt impossible; - plusieurs déclarations ont la même date de bilan; - la déclaration a été introduite à une date de bilan inconnue dans le Dossier unique; - la langue de la déclaration ne correspond pas à la langue reprise dans le Dossier unique; - les chiffres de la déclaration dépassent les montants limites ou s’écartent des tarifs

fiscaux des exercices d’imposition antérieurs; - la déclaration contient des erreurs (p. ex. le montant des versements anticipés ne

correspond pas aux chiffres figurant dans le fichier de l'exercice d’imposition).

4. Envoi de tâches vers l'application TaskManager. Si une déclaration présente des anomalies, suite au processus de validation lié à la taxonomie ou à Calculatrix, une tâche est créée dans

11 CVVen = Centrale Validatie Vennootschappen


l’application TaskManager. Cette tâche doit être traitée par le gestionnaire de dossier avant que la déclaration ne puisse être enrôlée. Chaque tâche créée se voit attribuer une série de caractéristiques (p. ex. SLA, description, date d’échéance, etc. selon les modalités définies dans l’application TaskManager).

5. Lettres standards. La résolution des anomalies peut exiger l’envoi de courriers. L’application

BizTax Backoffice devra disposer d’une bibliothèque de lettres standards qui seront envoyées aux contribuables ou à des tiers. Certaines données contenues dans ces lettres seront déjà préremplies avec des valeurs par défaut (p. ex. le numéro d’entreprise, l’adresse, etc.). Une copie des courriers sortants sera conservée électroniquement et jointe aux déclarations et/ou au dossier permanent (voir plus loin).

Le courrier entrant donne lieu à la création d’un formulaire scan également joint à la déclaration et/ou au dossier permanent sous forme électronique. La conception technicofiscale des modèles (templates) et des règles de validation s’y rapportant est analysée par l’administration et mise à disposition pour implémentation. Exemples de courriers standards :

- 279: Avis de rectification - 279 E1 : Avis de taxation d’office - 279 E2 : Avis de taxation d’office (avis 8 jours) - 279 E2V : Avis de taxation d’office en matière de précompte - 279F1 : Amende administrative - 279F2 : Notification d’une amende administrative - 279T : Communication de la position définitive de l'administration - 279V-279Pr : Avis de modification en matière de précomptes - 332: Demande de renseignements - 332ter : Demande de renseignements à des tiers - 332C : Renvoi de la déclaration pour défaut de forme - 440B : Invitation à se présenter au bureau - 440BI : Annonce d’une visite sur place - Déclaration d’accord ISoc – IMP – INR/Soc. - Demande de renseignements informelle - Lettre contenant seulement l’en-tête et les coordonnées personnelles du gestionnaire de

dossier - Déclaration d’accord impôt des sociétés

6. Dossier permanent. Un dossier permanent électronique est conservé pour chaque contribuable. Un dossier permanent contient notamment une série de tableaux qui découlent de la taxonomie XBRL. Après validation des déclarations, ces tableaux sont actualisés sur la base des déclarations introduites ou des corrections ultérieures effectuées par le gestionnaire de dossier. Le dossier permanent peut aussi contenir de la correspondance concernant le contribuable qui n’est pas liée à un exercice d’imposition spécifique.

Exemples de tableaux :

- 276D : aperçu des augmentations d’impôt et amendes administratives appliquées - 328D : tableau d’origine du capital - 328R : tableau des réserves taxées - 328S : tableau des réserves exonérées - suivi des plus-values soumises à taxation étalée 276K1

7. Enrôlement. Après validation, si la déclaration ne contient plus d'erreurs, elle est déclarée prête à être enrôlée. Le calcul de l’impôt dû, la création et l’envoi de l’avertissement-extrait de rôle sont assurés par une application distincte, à savoir Calculatrix. Ce processus ne fait donc pas partie du scope de l’application BizTax Backoffice, mais il faut prévoir les interactions nécessaires. L’ensemble du processus d’enrôlement prend plusieurs semaines. Dans certains


cas, les services de taxation doivent toutefois procéder à un enrôlement urgent. Un modèle a été spécialement conçu à cet effet.

8. Module d’octroi. Le chef de service des services de taxation dispose d’un module spécifique

qui lui permet de distribuer les tâches entre ses différents collaborateurs. Ce module lui permet aussi de connaître le pourcentage de tâches dont est responsable chacun d’eux.

9. Listes. Des listes peuvent être générées pour chaque service de taxation qui donnent un

aperçu de l’avancement des activités du service et permettent dès lors de procéder à des ajustements le cas échéant. De plus, diverses listes peuvent aussi être générées au niveau des déclarations (introduite dans les délais prescrits, tardive, pas introduite, prescrite, etc.). Actuellement, huit listes sont définies qui rassemblent des données à partir de diverses bases de données (Sitran, Entités, BizTax Backoffice). Les données de ces listes sont actualisées tous les jours.

Exemples de listes :

- Listes basées sur les données enregistrées dans l’Entité (3 listes) - Listes basées sur les données enregistrées dans l’Exercice d’imposition (5 listes)

10. Pour le service central, un module spécifique permet de gérer l’enrôlement au niveau national.

Ce module permet d’exécuter l’enrôlement en fonction de différents paramètres (p. ex. moment de l’enrôlement, montant minimum ou maximum, etc.).

11. Liste imprimeur. Au niveau central, le backoffice doit générer un fichier qui permet à

l’imprimeur d’envoyer les déclarations sur papier aux contribuables (nom, adresse, date limite, données de l’expéditeur, etc.).

12. Base de données relationnelle. Les données des déclarations et le dossier permanent,

conservés dans le format XBRL doivent être mis à la disposition d’autres applications par le biais d’une base de données relationnelle pour leur permettre de les utiliser dans le cadre de leur traitement ultérieur.

2. Gestion via les Entités et l’Exercice d’impositi on Outre plusieurs modules spécifiques, BizTax Backoffice devra permettre de conserver, suivre et traiter différentes données aussi bien au niveau des entités qu’au niveau de l’exercice d’imposition. L’“Entité” est le lien indispensable entre les données signalétiques personnelles et les droits et les obligations fiscales et non fiscales qui en découlent. L’entité est le point de liaison entre le volet données signalétiques personnelles et les autres volets du Dossier unique et notamment les données fiscales parmi lesquelles les données des déclarations, les données de contrôle et les données de perception et de recouvrement, les données patrimoniales et les données douanières. L’“entité” représente l’ensemble des droits et des obligations liés à un impôt, une taxe ou un droit acquis du SPF Finances. Il s’agit d’une ou de plusieurs “Unités Personnes”.


L’Entité générique est complétée d'une série de données spécifiques à BizTax. L’Entité contient une série de données qui s’appliquent à des contribuables spécifiques sur plusieurs exercices d’imposition (p. ex. date de bilan, langue, etc.) tandis que le volet Exercice d’imposition contient des données spécifiques à l’exercice d’imposition concerné (date de réception de la déclaration, date limite de déclaration, etc.). Sur la base des données enregistrées dans l’Entité, un Exercice d’imposition est ‘initialisé’ chaque année. En d’autres termes, un dossier est créé pour chaque déclaration devant être introduite pour l'exercice d'imposition spécifique qui contient déjà une série de métadonnées (date de bilan, date limite, service compétent, langue, etc.). Aussi bien les données de l’Entité que celles de l’Exercice d’imposition doivent pouvoir être conservées, actualisées et consultées sur la base d'une série de règles de validation.

3. Liens avec les autres applications BizTax Backoffice possède de nombreux liens avec d’autres applications. 3.1. Sitran Sitran est la seule application au sein du SPF Finances qui rassemble toutes les données signalétiques des contribuables et les met à la disposition de divers utilisateurs et applications, parmi lesquels BizTax Backoffice. Elle est alimentée par une série de sources authentiques parmi lesquelles la Banque-Carrefour des entreprises. L’alimentation des diverses applications se fait sur la base de signaux développés pour les différents champs de données de Sitran et que les applications utilisent pour adapter leurs champs de données, lancer certaines transactions ou créer des tâches. BizTax Backoffice utilise actuellement 9 signaux :

- Statut juridique - Forme juridique - Adresse - Fusions et scissions - Code d’activité - PersIDF et UPersIDF


- Qualité - Grande entreprise /PME - Date du bilan

Ces signaux lancent une série de tâches ou actualisent une série de champs dans l’application BizTax Backoffice.

3.2. AnnuComp AnnuComp est l’application au sein du SPF Finances qui rassemble les données signalétiques de tous les services, ainsi que leurs compétences. BizTax utilise AnnuComp chaque fois qu’un service compétent doit être déterminé, p. ex., en cas de changement d’adresse d’un contribuable, en cas de création d’un avertissement-extrait de rôle sur lequel doit figurer le service compétent, etc. 3.3. Calculatrix Calculatrix contient d’une part une série de règles de validation concernant les déclarations pour autant que celles-ci ne soient pas reprises dans la taxonomie XBRL. D’autre part, c’est aussi au sein de l'application Calculatrix que l’impôt dû est calculé, que des simulations sont faites et qu’est repris l'ensemble de la chaîne d'enrôlement. 3.4. TaskManager Les tâches créées au sein de chaque application sont centralisées dans le TaskManager et donnent à l'utilisateur un aperçu de toutes les tâches qui lui ont été attribuées. Au sein de TaskManager, les tâches peuvent être classées en fonction de leur degré de priorité, de l'application qui les a générées, etc. 3.5. Identity & Access Management (IAM) C’est au sein d’IAM que sont stockés les droits d’accès de chaque utilisateur aux diverses applications.

4. eXtended Business Reporting Language (XBRL) L’application BizTax Backoffice repose en partie sur une taxonomie XBRL qui génère les écrans des déclarations et du dossier permanent. Les écrans des déclarations sont générés par une taxonomie qui constitue une extension de la taxonomie aussi utilisée dans le cadre de BizTax Frontoffice; une taxinomie distincte a été développée pour le dossier permanent. L’application doit tenir compte du fait qu'on n'utilisera pas uniquement la taxonomie relative aux déclarations concernées et au dossier permanent, mais que d’autres taxonomies et/ou une extension de la taxonomie à d’autres concepts et d’autres données propres à l'environnement backoffice pourraient également s’avérer nécessaires. Plusieurs versions de la taxonomie ISoc, INR/Soc et IPM sont également possibles. Dans la mesure du possible, il faudra que leur gestion et leur actualisation soient centralisées (taxonomy repository). La validation s'applique aussi bien aux conditions techniques (prescriptions XML et XBRL, aux données structurelles, etc.) qu’aux contrôles de contenu (e.a. contrôles mathématiques et logiques, validations technicofiscales). 1.5. Aperçu du nombre potentiel d'utilisateurs


Nombre d’utilisateurs Backoffice

Services de taxation classiques ISoc: 1.050 répartis sur 160 bureaux

Read & Write

Centres de contrôle : 1.850 répartis sur 48 centres

Read & Write

Services de taxation IPM: 149 répartis sur 13 bureaux

Read & Write

Services de taxation INR/soc: 100 répartis sur 6 bureaux

Read & Write

Recherches : 450 Read

IPP: 3.000 Read

TVA : 1.900 Read

Fraude : 650 Read & Write

En dehors de ces utilisateurs directs actifs, de nombreux autres services du SPF Finances souhaiteront aussi, à l’avenir, pouvoir consulter les données contenues dans les déclarations et leurs annexes.

b. Cycle de vie récurrent Étant donné l’évolution constante de la législation fiscale et les changements qui interviennent au niveau des directives administratives, le backoffice doit nécessairement pouvoir s'adapter à ces changements et être modifié. Les changements se situent principalement sur les plans suivants:

- Les déclarations et le dossier permanent sont générés dans le Backoffice par le biais d‘une taxonomie. Quand la législation ou les développements techniques évoluent, il faut pouvoir adapter la taxonomie le cas échéant. Cette adaptation de la taxonomie peut mener à la création de nouveaux écrans relatifs à la déclaration ou au dossier permanent (tableaux supplémentaires). Sur le plan des règles de validation contenues dans la taxonomie aussi, des changements peuvent s’avérer nécessaires. Une aide à la création et à la gestion de la taxonomie XBRL ainsi qu’à l’intégration et à l’adaptation de la génération des écrans sur la base de la Taxonomie XBRL adaptée sera nécessaire chaque année;

- Des modifications des règles de validation gérées par Calculatrix peuvent s’avérer

nécessaires;

- Adaptation des lettres standards ou création de nouvelles lettres;

- Adaptation ou création de nouvelles listes;


- Aussi bien au niveau des Entités que de l’Exercice d’imposition , des champs

supplémentaires peuvent s'avérer nécessaires; sur ce plan, l'application devra alors être adaptée, ce qui peut aussi impliquer la création de règles de validation supplémentaires;

- L’Exercice d’imposition est initialisé automatiquement chaque année; des modifications

de ce module peuvent donc s’avérer nécessaires à la suite de modifications de la législation ou des directives;

- Les interactions avec les diverses applications peuvent exiger des modifications au

niveau de l’application BizTax Backoffice;

- Si on utilise de nouveaux signaux supplémentaires en provenance de Sitran, il faudra développer les transactions et les tâches nécessaires, liées à ces signaux supplémentaires dans BizTax Backoffice;

- Les données enregistrées dans le fichier Liste Imprimeur peuvent être modifiées et/ou

étendues.

c. Indications quant à la future maintenance évolutive Les évolutions futures de BizTax Backoffice peuvent se situer sur les plans suivants :

2. Lettres de rappel Les contribuables qui n’ont pas introduit leur déclaration sont invités à s’acquitter spontanément de leur obligation dans une lettre de rappel avant de se voir infliger une amende. À l’avenir, la détection des contribuables qui n’ont pas introduit leur déclaration et l’envoi d’une lettre de rappel doivent se faire entièrement automatiquement.

3. Amendes administratives Les contribuables qui ne respectent pas la législation fiscale peuvent se voir infliger des amendes administratives. Ils sont avertis de ces amendes par lettre recommandée (lettre standard). Ils disposent d’un délai d’un mois pour formuler leurs remarques et le cas échéant une amende dont le montant dépend des amendes déjà encourues est enrôlée. Les contribuables reçoivent un avertissement-extrait de rôle leur demandant de s’acquitter de ce montant dans le délai légal imparti. L’historique de ces amendes est tenu dans un tableau du dossier permanent. L’ensemble de ce processus, qui se fait encore pour l’instant en grande partie sur papier, doit être automatisé :

- Envoi d’une lettre standard au contribuable en infraction; - Réception de sa réaction; - Établissement et envoi de l’avertissement-extrait de rôle avec consultation obligatoire de

l’historique; - Actualisation du tableau du dossier permanent après l’enrôlement; - Transfert automatique des montants enrôlés à l’Administration du recouvrement en vue de

la perception ou du recouvrement du montant dû

4. MyMinFin À l’avenir, certains modules du backoffice pourront être mis à la disposition du contribuable et/ou de son mandataire pour consultation.


Cette consultation se fera probablement via MyMinFin. L’intégration nécessaire à cet effet doit être prévue.

5. Intégration avec d'autres applications De nombreuses applications utilisées par les services de taxation ont parfois été développées indépendamment les unes des autres et à des moments différents. Ces applications ont souvent été développées dans le cadre du programme ‘Traitement intégré’, un des principes stratégiques de la réforme Coperfin au sein du SPF Finances. Dans les prochaines années, il y aura sans doute lieu d’améliorer l’intégration entre les différentes applications, notamment en raison des réformes organisationnelles annoncées au sein du SPF Finances. Les principales interfaces de BizTax Backoffice sont celles avec l’application Stirco (module de support des activités de contrôle). Les agents taxateurs, chargés des activités de contrôle, utiliseront aussi beaucoup BizTax Backoffice. Stirco et BizTax Backoffice qui sont actuellement deux applications distinctes devront de plus en plus être intégrées.

6. Nouvelles fonctionnalités L’application BizTax Backoffice sera mise en production au plus tôt à partir de l'exercice d’imposition 2014. Après sa première mise en production, les utilisateurs constateront probablement une série de manquements au niveau des fonctionnalités de l’application qui demanderont des développements supplémentaires.


III. CalcIsoc

d. Description fonctionnelle

Introduction Calcisoc est responsable d’une série de programmes de calcul et d’enrôlement des impôts sur les revenus suivants : impôt des sociétés, impôt des personnes physiques et impôt des non-résidents/sociétés. Cela concerne les nombres de personnes morales suivantes :

• 510.000 pour l’impôt des sociétés • 100.000 pour l’impôt des personnes physiques • 11.000 pour l’impôt des non-résidents/sociétés

L’objectif de Calcisoc est de réaliser une imposition correcte en temps utile pour tous les contribuables et la mise à disposition en temps utile d’un module de calcul qui leur permet de calculer eux-mêmes leur impôt pour ainsi encourager la compliance. Calcisoc interagit avec les applications suivantes: Biztax front-office, Biztax back-office, versements anticipés, Sitran, Entités, Annucomp, ICPC, Fedopress.

Description Toutes les interventions d’acteurs humains se font par le biais de l’application Biztax (front-office ou back-office). Calcisoc calcule l’impôt en mode simulation lorsque la fonctionnalité est appelée par Biztax front-office. Dans ce cas, aucune donnée n’est sauvegardée. Calisoc calcule l’impôt en mode calcul définitif lorsque la fonctionnalité est appelée par Biztax back-office. Les données résultant du traitement sont envoyées à Biztax back-office où elles sont stockées pour permettre l’enrôlement après sélection par un agent. À intervalle régulier, Calcisoc consulte, au moyen d’une vue, la base de données Biztax pour déterminer si un (ou des) paquet(s) est(sont) prêt(s) pour l’enrôlement. Les déclarations correspondantes et le résultat du calcul définitif associé sont extraits de Biztax et intégrés à Calcisoc. Le processus d’enrôlement continue par la création de rôles, l’attribution de numéros de rôle et de numéros d’articles, l’envoi des fichiers d’enrôlement au système de recouvrement, l’édition d’AER et l’apurement des versements anticipés. À la fin du processsus d’enrôlement, un feedback est transmis à Biztax back-office.


Modèle d’architecture fonctionnelle

Diagramme des packages.

Enrichissement Fonctionnalités permettant de compléter les données du bordereau avec des données externes au système ou des données provenant de déclarations précédentes

Validation Fonctionnalités permettant de valider les données du bordereau et d’émettre des warnings ou erreurs quand une (des) règle(s) de validation ne sont pas rencontrées


Calcul Fonctionnalités permettant de calculer l’impôt des sociétés

Édition Fonctionnalités permettant de construire une note de calcul au format PDF ou un avertissement-extrait de rôle

Enrôlement Fonctionnalités permettant d’introduire les données nécessaires au recouvrement dans le système général de recouvrement du SPF Finances

Apurement VA Fonctionnalités permettant la synchronisation avec la base de données VA et l’apurement des VA

b. Cycle de vie récurrent Les adaptations fiscales annuelles aux trois déclarations destinées aux personnes morales ont un impact sur Calcisoc. Chaque année, il faut prévoir une nouvelle version qui supporte le nouvel exercice d’imposition. Une nouvelle législation fiscale, une nouvelle jurisprudence et de nouvelles dispositions administratives entraînent nécessairement des changements au niveau de l’application. Les adaptations aux applications avec lesquelles Calcisoc interagit et les évolutions techniques des standards ICT nécessitent une maintenance continue de l’application. Enfin, de nouveaux développements sont également nécessaires pour continuer à garantir le fonctionnement correct et performant de l'application.

c. Indications quant à la future maintenance évolutive L’application Calcisoc n’est en production que depuis septembre 2014 pour les enrôlements de l’exercice d’imposition 2014. Une série de manquements au niveau des fonctionnalités de l’application seront sans aucun doute constatés qui exigeront des développements supplémentaires. Parmi les fonctionnalités déjà identifiées comme manquantes et donc à développer, on note :

• Enrôlement plus rapide • Intégration de l’enrôlement manuel • GUI pour bloquer les codes • Statistiques des enrôlements • Plateforme de test efficace


IV. Stir-Controle (STIR-CO)

a. Description fonctionnelle Release 1 Description générale STIR-CO(ntrole) a pour objet le développement d'un module de contrôle pour tous les services de contrôle des impôts sur le revenu et la TVA au sein de l'AG de la Fiscalité. Au sein du programme STIR, la gestion du plan de travail dans le contexte de la surveillance fiscale a d’ailleurs déjà été réalisée. Ce projet de suivi comprend l’affinage des fonctionnalités du plan de travail de STIR-CO(ntrole), ainsi que le développement de fonctionnalités au niveau de la gestion de la documentation et de la correspondance. Ces fonctionnalités contiennent le cœur de la réalisation de la surveillance fiscale et des missions de contrôle proposées via les applications de gestion des risques. Ces missions de contrôle sont en outre subdivisées en une série de volets concentrés sur l’étude d’une matière fiscale spécifique. Objectifs du projet Optimiser, uniformiser et accroître la transparence de la gestion du plan de travail de toutes les missions de contrôle effectuées au sein des CC de l’AFER. La numérisation du dossier de contrôle qui le rend consultable par tous les fonctionnaires du SFP Fin y autorisés. Ampleur (scope): Le projet en soi ne concerne que la gestion et l’exécution des missions de contrôle au sein des CC de l’AFER. À partir du 01/01/2012, le scope de ce projet a été étendu à tous les services de contrôle classiques de l’AG de la Fiscalité. L’aspect analyse des risques ne fait pas partie du projet Stirco. Produits finaux: Une application qui supporte la gestion du plan de travail de toutes les missions de contrôle exécutées au sein des CC de l’AFER et qui permet à l’agent contrôleur individuel de gérer son dossier de contrôle électronique. Au sein de l’application, des rapports standards sont aussi disponibles pour la communication des informations de management nécessaires. Release 2 Cette phase du projet STIR-CO comporte l’affinage des fonctionnalités du plan de travail, comme des développements en matière de la gestion des documents et de la correspondance. Les missions de contrôle proposées par l’application de gestion des risques seront fractionnées en un nombre de volets.


Vue synthétique du module 1: Contrôle.

SITRAN

IAM

CCFF

LDAP

WS Sitran

Contrôle

WS Stiron Documents

FileNet Cognos STIR_CORE

CCFF

Webservices SOAP

Contexte inter-applicatif

Upload queue


b. Cycle de vie récurrent 1. Adaptations de l'application aux évolutions technologiques internes (le monde java nécessite un release majeur toutes les 2 années); 2. Adaptations de l'application aux évolutions technologiques externes (OS, navigateur, …); 3. Adaptations de l'application aux modifications de structure de l'organisation; 4. Adaptations de l'application aux modifications législatives; 5. Amélioration de la qualité des applications existantes.

c. Indications quant à la future maintenance évolutive 1. Implémenter des rapports et des suivis aussi bien pour une utilisation interne que pour une utilisation externe (COGNOS et BAM); 2. Étendre l’accès à STIR-CO aux services de gestion des services classiques et par le contextual services; 3. Étendre la fonctionnalité de base et les templates des documents structurés; 4. Introduire, au sein de STIR-CO, un système de mailing qui informe le gestionnaire du plan de travail des nouvelles actions chargées, des modifications importantes, des transferts des missions … 5. Reprise des dénominations des services dans le menu déroulant des codes crestra; 6. Intégration de STIR-CO avec Stiron Lot 1 Biztax, Taxi et Lot 2 TVA pour le préremplissage de la fiche de résultats sur la base des données introduites pour l’enrôlement ou sur la base de l’ordre d'enrôlement afin d'éviter les incohérences et les redondances; 7. Exportation des missions vers Excel (existe déjà) mais avec l’ajout des volets sous-jacents, liés à chacune des missions exportées (statut volet, exécutant, …); 8. Prévoir un menu déroulant exécutant pour les recherches de volets par le chef de service; 9. Visualisation de la date de clôture d’une mission sur la liste des missions.


V. Stir-Recherche

d. Description fonctionnelle Release 1 Au sein du système pour la gestion intégrée de l’Administration des Impôts et du Recouvrement (STIR), le développement du module STIR-RE doit offrir un soutien en matière d'une part de la gestion de plan de travail pour la Recherche d'autre part la gestion des documents et des tâches des agents de la Recherche. Le projet STIR-RE se rapporte à l'exécution des actions de recherche au sein des secteurs d'activités. Un nombre fonctionnalités seront développées en matière de gestion du plan de travail et des instructions de travail qui seront complétées dans le cadre d'un prochain release. Release 2 Un nombre de nouveaux éléments sont introduits dans l’application comme la gestion des documents structurés et non structurés, l’intégration avec le ‘Dossier unique’, la notion de charge de travail y compris le fonctionnement avec une équipe d'action, la notion vaste de constatation y compris le processus de validation et les constatationsnon programmées…. Vue synthétique du module 2: Recherche.

e. Cycle de vie récurrent

1. Adaptations de l'application aux évolutions technologiques internes (le monde java nécessite un release majeur toutes les 2 années); 2. Adaptations de l'application aux évolutions technologiques externes (OS, navigateur, …); 3. Adaptations de l'application aux modifications de la structure de l'organisation; 4. Adaptations de l'application aux modifications législatives;

SITRAN

IAM

CCFF

LDAP

WS Sitran

Recherche

WS Stiron Documents

FileNet STIR_CORE

CCFF

Webservices SOAP

Contexte inter-applicatif

Upload


5. Amélioration de la qualité des applications existantes.

f. Indications quant à la future maintenance évolutive Les évolutions de STIR_Recherches peuvent être divisées en 2 volets : · Une composante technique · Une composante organisationnelle /réglementaire 1. La composante technique de STIR_Recherches concerne l‘adaptation de l’application

aux modifications relatives à la technologie utilisée . …

a. Au sein du projet NCO, plusieurs modules d’introduction (MySQL et PHP) ont été développés par le passé qui offraient la possibilité aux personnes concernées de fournir des données pour l'exécution des SLA. Ces modules ne répondent toutefois pas aux standards ICT actuellement en vigueur et doivent donc être remplacés par des modules d’introduction flexibles qui satisfont aux standards ICT actuels et futurs.

2. À partir de 2014/2015, l’application STIR_Recherches doit être adaptée à une série de modifications organisationnelles /réglementaires. Sans ces adaptations, l’application ne pourra plus être utilisée. Les points d'attention importants sont les suivants:

a. Introduction d'une nouvelle structure organisationnelle dans laquelle les 2 directions DRL et DRNI sont remplacées par 1 Centre National de Recherche (CNR) et les 22 inspections existantes sont remplacées par 2 services comprenant plusieurs équipes (inexistants dans la structure actuelle). La nouvelle structure doit être implémentée dans l’application. Cela implique que des modifications mineures ou majeures doivent être effectuées au niveau de la structure des tableaux sous-jacents; redéfinition et adaptation des règles de validation actuelles; réévaluation des business rules à l’occasion de l’implémentation d’une approche orientée processus des Activités de recherche (P111); réétudier et adapter la matrice Consultation pour les personnes concernées, étant donné qu'on les retrouve aussi dans les toutes nouvelles structures organisationnelles et de concertation, …

b. En redessinant les ressorts dans la nouvelle structure, l’upload central de l’application doit être appliqué in extenso. Cette adaptation est aussi l’occasion rêvée d’améliorer l’harmonisation des fonctionnalités de cet upload avec les besoins et les attentes aussi bien des personnes concernées que des utilisateurs internes.

c. Afin de pouvoir anticiper les futures modifications organiques et procédurales, il est souhaitable de développer un module administrateur de sorte que les adaptations nécessaires à l’application puissent être effectuées facilement et de manière à pouvoir garantir la continuité de l’application. Un module administrateur offre aussi la possibilité de diminuer la dépendance d'un partenaire externe.

d. L’introduction obligatoire (par le COC de l’AG de la Fiscalité) du processus P111; son suivi via les KPI (à partir de 2014), ainsi que la poursuite du développement du mode de fonctionnement via des SLA avec divers stakeholders, invite le CNR


à faire développer un module de suivi. Sans ce module les activités du CNR ne pourront pas être suivies de manière sérieuse et professionnelle et le CNR ne peut procurer qu’une aide faite d’informations fragmentaires. Le suivi au niveau individuel du collaborateur doit se faire via le Business Activity Monitoring (BAM). Pour le suivi au niveau du service et du centre, on peut éventuellement opter pour une autre solution. L'utilisateur externe (stakeholder) doit pouvoir suivre l’exécution des tâches confiées au CNR.


VI. PRM-On-Web (ou Prm-on-web)

a. Description fonctionnelle � Qu’est-ce que le précompte mobilier ?

Le précompte mobilier est une imposition due sur les revenus des capitaux et des biens mobiliers (notamment les intérêts et les dividendes), ainsi que sur les revenus divers à caractère mobilier. De manière générale, le précompte mobilier est retenu à la source et doit être versé spontanément au SPF Finances par ceux qui attribuent les revenus imposables (définis comme les débiteurs par opposition à ceux qui reçoivent les revenus), ou par certains intermédiaires financiers. Le précompte est d’ailleurs aussi dû, dans certains cas particuliers, par le bénéficiaire des revenus. Ce précompte doit être payé dans les quinze jours qui suivent l'attribution ou la mise en paiement des revenus imposables.

� Prm-on-web

Grâce à l’application internet Précompte Mobilier (Prm-on-web) du SPF Finances, depuis 2012, tous les contribuables peuvent introduire leurs déclarations de précompte mobilier directement par voie électronique. Prm-on-web est une manière rapide, conviviale et sûre de faire une déclaration de précompte mobilier. Prm-on-web accepte 2 moyens d’identification :

◦ la carte d’identité électronique; ◦ou un certificat de classe III délivré par:

◦ Global Sign ◦ ISABEL ◦ Certipost

Prm-on-web doit être disponible 24 heures sur 24 de manière à permettre d’introduire une déclaration à n’importe quel moment. Le précompte mobilier doit être déclaré et payé dans les 15 jours après la date d'attribution ou de mise en paiement des revenus imposables, c.-à-d. la date à laquelle le bénéficiaire peut réellement disposer de ses revenus. Le système fournit aux contribuables une communication structurée qu’ils doivent utiliser pour le paiement.


b. Cycle de vie récurrent

L’application Prm-on-web fait partie du projet Stimer. Bien que le projet Stimer ressortisse à la compétence de l’AG PR, la partie Stimer Prm (c’est ainsi que l’application Prm-on-web est définie dans Stimer) est attribuée à l’AG de la Fiscalité. Cette partie contient d’ailleurs l’enregistrement des déclarations Prm, qui fait partie des compétences de l’AG de la Fiscalité.

Le projet Stimer a été remplacé par le projet First. Il existe un contrat de maintenance avec la société Centran pour assurer la maintenance de Stimer/First.

Étant donné que le projet Stimer a fait de nombreuses maladies d’enfance, Prm-on-web n’a pas non plus été épargnée par celles-ci. Au cours de ces dernières années, de nombreux bugs ont dû être réparés dans cette application. Ces bugs et ces maladies d’enfance sont aujourd’hui largement résolus. De ce fait, quasi aucune, voire aucune, maintenance n’a été nécessaire. En 2014, plusieurs adaptations fonctionnelles ont dû être effectuées au niveau des écrans de saisie et de la base de données.

Prm-on-web ne nécessite pas de cycle de maintenance annuel. Les adaptations à cette application ne sont pratiquement dues qu’en raison des modifications de la législation ou des directives administratives.

c. Indications quant à la future maintenance évolutive Pour l'année 2015, le modèle de déclaration du Prm change fondamentalement. Cela

demandera une adaptation des écrans de saisie et de la base de données. Dans ce cadre, le développement d’un modèle d’information statistique s’avérera également nécessaire. De plus, la direction responsable de la législation relative au Prm réfléchit actuellement à une déclaration complémentaire pour ce qu’on appelle les “prêts-citoyens”. Aucune décision n’a toutefois encore été prise à ce sujet, ni sur le plan administratif, ni sur le plan politique.


VII. Fin ELTS

d. Description fonctionnelle

FinELTS est une application pour introduire les : – Déclarations pour la taxe d’épargne à long terme

– Déclarations pour la taxe sur les primes (nouveauté)

par les institutions financières et les compagnies d’assurance

• L’application permet d’introduire les données via :

– Écran

– Fichiers

• L’accès à l’application est possible via :

– La carte d’identité électronique

– Un certificat de classe 3 délivré par Global Sign, Isabel ou Certipost

• L’utilisateur doit, de plus, être enregistré dans le système

• Quel que soit le mode d’accès (Eid, classe3), lors de la première connexion l’utilisateur doit posséder les droits d’administrateur sur la machine.

• Pour un accès via Eid, les informations suivantes doivent se trouver dans l’email :

– Numéro de l’entreprise (no BCE)

– Nom de la personne mandatée qui accède au site

– Numéro national de la personne mandatée qui accède au site

– Adresse email de la personne mandatée

• Pour un accès via certificat de classe 3, les informations suivantes doivent se trouver dans l’email :

– Numéro de l’entreprise (no BCE)

– Adresse email de la personne mandatée

– L’objet du certificat classe 3 (identifiant + nom) : dans le premier écran de l'application FINELTS, cliquer sur le bouton

e. Cycle de vie récurrent Il n’y a aucune modification qui soit récurrente lors de chaque cycle annuel. Les modifications dépendent des décisions budgétaires.

f. Indications quant à la future maintenance évolutive


• En vertu de l'article 8 de la directive 2011/16/EU européenne concernant l'assistance administrative pour les impôts directs, la Belgique est obligée d'échanger pour la période d'imposition débutant le 1er janvier 2014, d'une façon automatique, tous renseignements disponibles dont elle dispose vis-à-vis des résidents des autres États membres en matière de revenus.

Pour fournir les renseignements relatifs aux assurances-vie des non-résidents automatiquement et de manière structurée à STIRint, il faut modifier les inputs de FinELTS (encodage et fichiers XML) utilisés par les membres d'Assuralia pour disposer des codes pays, codes postaux et si possible des NN et par conséquent modifier la base de données pour recevoir ces informations et créer un flux XML pour recevoir les demandes en provenant de STIRint et renvoyer les réponses.

• Donner accès à l’application aux autres services tels que Grande Entreprise, au recouvrement, au Datawerahouse, au TACM, au Service de Gestion de données…


Lot 4 (Domaine Transnational)

STIRint/FATCA/Auto_DT 1. Description générale 1.1. Introduction. STIRint est un programme qui regroupe plusieurs applications utilisées dans le cadre de la collaboration administrative internationale. Une des principales tâches du programme est d’exécuter et de gérer chaque type d’échange international d’informations, aussi bien dans le domaine des impôts directs que dans celui de la TVA et du recouvrement. En raison des différentes bases légales impliquées, l’exécution et la gestion de l’échange international d’informations se font dans des applications distinctes. Même au sein d’une même matière, il est souvent nécessaire de développer plusieurs applications pour satisfaire aux différentes obligations internationales. STIRint est une plateforme communautaire, composée de différents modules au sein de différentes administrations :

• AG Fisc (Impôts directs et TVA) • AG PR (Perception & Recouvrement) • AG DP (Documentation Patrimoniale) • ISI (Inspection Spéciale des Impôts)

Le service de Recouvrement non seulement échange des informations au niveau international mais utilise également un système de notification des documents et plus spécialement des demandes de prise de mesures conservatoires et d’exécution du recouvrement. Au cours de la réunion de direction du SPF Finances du 23/01/2015 il a été décidé de confier la gestion générale du programme STIRint à l’Administration Générale de la Fiscalité. 1.2. Les applications triées par domaine . Vous trouverez ci-après un aperçu des applications au sein du programme STIRint triées par domaine. Cette liste n’est pas exhaustive et peut être complétée d’autres applications au sein du programme STIRint. Les applications pour la TVA

• Coopération internationale

Cette application est utilisée pour le suivi et la gestion de chaque dossier et de chaque type d’échange d’informations en matière de TVA. Cette application contient de nombreuses fonctionnalités qui permettent de satisfaire à toutes nos obligations internationales: entre autres, la gestion des autorités compétentes belges et étrangères, le suivi des délais d’exécution, la collecte des informations statistiques,


la gestion des mandats octroyés dans le cadre des contrôles multilatéraux, etc.

• VAT Refund.

À terme, cette application sera transférée à l’Administration Générale de la Perception et du Recouvrement. Ce module garantit la gestion des demandes de remboursement de la TVA (8e et 13e directives). Le module envoie les demandes des assujettis belges vers les autres États membres via Intervat et garantit la réception et le traitement des demandes de remboursement de la TVA des contribuables établis dans les autres États membres (8e directive) et dans des pays hors Union européenne (13e directive).

• VAT on-e-services (VOES)

Ce module fait partie de l’application MOSS depuis le 01/01/2015. Ce module doit néanmoins rester actif jusqu’au 31/12/2017 afin de permettre aux assujettis non européens de rectifier leurs déclarations ‘Voes’ antérieures à 2015. La description de ce module est reprise dans la description du module MOSS. Il s’agit, en fait, du même régime que MOSS, à la seule différence qu’il s’applique aux assujettis non européens depuis 2003. Les applications pour les impôts directs.

• Coopération internationale Cette application est utilisée pour le suivi et la gestion de chaque dossier et de chaque type d’échange en matière d’impôts directs. Cette application contient de nombreuses fonctionnalités qui permettent de satisfaire à toutes nos obligations internationales : entre autres, la gestion des autorités compétentes belges et étrangères, le suivi des délais d’exécution, la collecte des informations statistiques, la gestion des mandats octroyés dans le cadre des contrôles multilatéraux, la consultation des informations par les services de taxation compétents, etc.

• Directive sur la fiscalité de l’épargne & OCDE Cette application nous permet de respecter les obligations imposées par la Directive européenne sur la fiscalité de l'épargne en ce qui concerne l'envoi d’informations. L’application permet aussi le traitement technique des informations concernant les revenus de l'épargne que nous recevons des autres États membres de l'UE, des territoires dépendants ou associés ainsi que d’une série de pays tiers. Avant d’être envoyées, les informations collectées auprès des institutions financières belges sont soumises à un traitement. L’application assure aussi le traitement technique et la mise à disposition des informations relatives aux revenus de l’épargne que nous recevons des autres États membres de l’UE, des territoires dépendants ou associés et d'une série d'autres pays tiers.


Cette application traite (envoie et réceptionne) aussi l’échange automatique d’informations dans les formats développés par l’OCDE.

• Auto_DT

Cette application a été développée dans le cadre de l’article 8 (échange automatique d’informations) de la Directive européenne 2011/16/UE. Cette application permettra à la Belgique de respecter son obligation au niveau de l’envoi des informations disponibles à partir de l’année de revenus 2014 (les premiers échanges auront lieu en 2015) vers les autres États membres de l'UE concernant les catégories de revenus suivantes :

� IE (Income from Employment): Revenus professionnels

� DF (Director’s Fees): jetons de présence

� LIP (Life Insurance Products): produits d’assurance sur la vie

� � PEN (Pensions): pensions

� ROY (Royalties)

� IP (Immovable Property) Propriété et revenus de biens immobiliers

• FATCA

Cette application assurera le traitement des renseignements échangés dans le cadre de l’accord inter-gouvernemental conclu entre la Belgique et les États-Unis (U.S.) le 23/04/2014. Avant d’envoyer les informations aux États-Unis, les informations collectées auprès des institutions financières belges sont soumises à un traitement. Il s’agit ici d’un échange mutuel automatique annuel d’informations entre les institutions financières belges et américaines. Les premières informations seront échangées en septembre 2015.

• Les applications de MyMinfinPro qui sont liées à STIRint:

Il s’agit de l’application JMonnet et de l’application FATCA au sein de MyMinfinPro. Cette dernière ne doit pas être confondue avec l’application FATCA au sein de STIRint. Les applications pour la Perception et le Recouvrem ent.

• Coopération internationale. Le module IINV gère : 1) en ce qui concerne les créances dont le recouvrement est confié au SPF Finances, l’ensemble du workflow de l’assistance internationale aux fins du recouvrement sur la base de la Directive 2010/24/UE et des traités internationaux et bilatéraux.


L’assistance proposée comprend la communication d’informations, la notification de documents administratifs et judiciaires, la prise de mesures conservatoires et le recouvrement des dettes. Le principal utilisateur de ce module est le Service de recouvrement transversal (précédemment : CLO Recouvrement), qui fait partie du Centre Spécial de Recouvrement. Les différents bureaux de recettes ont accès (consultation) aux dossiers qui les intéressent. 2) En ce qui concerne les créances dont le recouvrement relève de la responsabilité des régions et des pouvoirs subordonnés, l’envoi des requêtes et de la correspondance s’y rapportant entre les bureaux de liaison régionaux et les administrations étrangères pour toutes les formes d’assistance prévues sous 1). Les applications pour l’Inspection Spéciale des Imp ôts

• Recherche transversale dans les applications “Coopération /recouvrement internationaux” des Impôts directs, de la TVA et de la Perception et du Recouvrement.

Remarque : l’ISI traite ses dossiers d’échange d’informations dans les applications “Coopération Internationale ID” et “Coopération Internationale TVA” 1.3. Aperçu des types d’applications . Chacune des applications de STIRint permet de réaliser des échanges internationaux de type individuel, en batch et transactionnel. Pour les échanges internationaux individuels les applications présentent les caractéristiques suivantes :

� Disponibles pour plusieurs services du SPF Finances, avec droits d’accès contrôlés et spécifiques;

� Larges possibilités de recherche avec plusieurs critères de recherche au travers de tous les dossiers présents dans l’application;

� Mise à disposition des données sans devoir copier et envoyer des documents (“Paperless”);

� Mise à disposition d’une interface en vue de la création et de la gestion des échanges;

� Enregistrement de tous les types d’échanges et octroi d’un numéro de dossier unique par l’application;

� Gestion du flux des échanges et de leur traitement;

� Création et gestion de statistiques;

� Définition flexible des droits des utilisateurs;


� Liaison entre les échanges et les dossiers uniques des personnes;

� Suivi des échanges (rappels);

� Conformité aux normes choisies par le SPF Finances.

Font partie de ces applications : la coopération internationale dans le domaine de la TVA, des Impôts directs et du Recouvrement. Pour les échanges internationaux automatiques (en batch) , les applications présentent les caractéristiques suivantes :

� Gestion de la réception des fichiers en provenance de l'étranger (soit automatiquement par email, soit manuellement via un support mémoire);

� Introduction du fichier dans le système et envoi vers les différentes applications et/ou personnes;

� Possibilité de rectification du contenu reçu;

� Exportation des données à partir de différentes sources vers des États partenaires;

� Mise des données à la disposition des applications demandeuses;

� Création et gestion des statistiques;

� Recherche et consultation des fichiers envoyés et reçus;

� Recherche et consultation du contenu des fichiers envoyés et reçus (au niveau du dossier);

� Gestion et suivi des identifications manuelles.

Font partie de ces applications : savings directive/OCDE, JMonnet, Auto_DT, FATCA, FATCA (MyMinfin) pour les Impôts directs, Enregistrement dans un autre État membre et MTN pour la TVA. Pour les échanges internationaux transactionnels, l’application VATRefund présente les caractéristiques suivantes:

� Gestion des demandes, des corrections et des données de signalement;

� Prise de décisions au niveau des montants à rembourser;

� Gestion des paiements;

� Gestion technique des échanges;

� Création et gestion des statistiques.

1.4. Description des applications existantes . STIR international regroupe toutes les applications qui échangent des informations entre la Belgique et les autres pays.


Voici un schéma du projet STIRint en plus de ses connexions et interactions avec d’autres applications du SPF Finances.


Bevoegde ambtenaren

STIRint platform

FOD Land X FOD Land YFOD Regio R Land Z

FOD Tijdelijk bevoegde ambtenaar

Land N

Applications

DLO centraal permanent bevoegd tijdeliijk bevoegd

BOWSITRAN

(STIR-DU)INTERVAT

Data Warehouse

STIR-BTW

Controle

CCFF

CCFF

SD en OESO

(Jmonet)

VAT on e-

services

DLOInt. Invord.

BBICLOVAT refund

Generiek Dossiers

Stimer(ICPC)

STIRint

MailPost

Fax

...

...

IAM

DIM

CLO

BBI centraalOCS

CLO Tijdelijk bevoegde SNRI Grenszone BTW

Internationale invordering

TBT

European Commission

BelconetTAXI

PortaalVAT refundVAT eservice

CCN/CSI

CCN Mail

Dorothée/Saintex

PLO

Generiek bulk

Stipad

Patri-monium Bulk

Belgische Regios

Financiële Instellingen

Pensi-oenen

DividendDirectors Fees

ArbeidLevensVerz.

Ander inkomen

Meer waarden

SD en JMonet: momenteel nog apart

Huidige Modeules StirInt

2015

2017


1.5. Les types d’échange . Les types d’échanges dans les modules précédents. 1) Échange automatique

L’ensemble minimum des blocs de base nécessaires et indispensables:

1. Upload automatique de nouveaux fichiers et/ou fichiers pour l’amélioration, la réception par mail ou via le réseau du CCN, ou upload manuel de fichiers ou de données, reçus sur cd, papier, etc. ou via les écrans de l’application. Les fichiers sont structurés et généralement de type XML

2. Back-up des fichiers et des sources originales

3. Validation aussi bien syntaxique (well-formdness & xsd-schema) que sémantique

(business rules et autres règles) 4. Enrichissement des données incomplètes ou partiellement valides (recherche &

consultation--> accès à d’autres DB et à d’autres applications, contrôles et validations business)

5. Intégration dans la propre DB de l’application et/ou dans la DB centrale (mécanisme

Push, Publish/ Subscribe, webservice, etc.) 6. Corrections manuelles (accès en R, R&W pour la propre DB et d’autres DB et

d’autres applications, écrans de recherche, consultation, adaptation, back-up, intégration, etc.) et corrections automatiques (via Upload n° 1)

7. Extraction à partir de la DB centrale et/ou d’autres DB des informations à envoyer

(accès, validation n° 3, compilation par pays ou pa r destinataire) 8. Envoi des fichiers structurés vers d’autres partenaires par mail ou via d’autres

canaux

9. Statistiques et rapports (création, exportation vers d’autres formats que les formats standards, consultation des statistiques et des rapports, recherche, impression, stockage, etc.)

10. Gestion des droits d’accès avec IAM (création de la matrice, consultation,

modification, ajout et suppression d’utilisateurs et de droits, gestion des autorités compétentes et des SPOC)

11. Gestion de la propre DB de l’application (consultation & recherche, modification,

ajout et suppression, etc.) 12. Gestion de l’assistance (aide en ligne, documentation, glossaire)

2) Les fonctionnalités minimum des échanges des rec herches/échanges spontanés / notifications / feedback ( = échanges individuels) 1. Réception d’un échange 1.1 Gestion des mails /Office Doc 1.1.1 Recherche et classement des mails


1.1.2 Consultation des mails 1.1.3 Scanning, ajout et stockage des échanges reçus sur papier 1.2 Enregistrement de l’échange (avec ses éventuelles annexes) 1.3 Validation de l’échange (technique: syntaxique - xsd / business rules) 1.4 Envoi d’un rapport d’erreurs vers les services externes ou vers d’autres pays 1.5 Distillation des données à partir du formulaire XML 1.6 Introduction par scanning d’un échange reçu sur papier 2. Traitement de l’échange. 2.1 Enrichissement et complétion de l’échange (accès aux applications et à la DB via les webservices ou d’autres mécanismes tels que Push, Publish & subscribe, etc.) comme: Sitran-Stipad-Huurcelen- E_succ- BOW, ICPC) pour contrôler, valider et compléter les données reçues 2.2 Envoi par mail ou via le TaskManager des échanges vers les services compétents (au SPF directement, aux régions de BXL,VL, WL, etc.) 2.3 Gestion des mots de passe pour faciliter et améliorer les analyses 2.3.1 Extraction de mots clés des fichiers reçus 2.3.2 Stockage des mots clés 2.3.3 Gestion des tables avec mots clés 2.4 Consultation de la propre DB et d’autres DB 2.5 Forward ou attribution de l’échange à une autre personne via le Taskmanager (application SPF pour la gestion des tâches) et attribution de l’échange à un autre gestionnaire de dossier pour que cette personne puisse recevoir les tâches via le Taskmanager. 2.6 Gestion des rappels aux services externes et vers les autres pays 2.6.1 créer un avis de rappel 2.6.2 compléter et envoyer un avis de rappel 2.6.3 recevoir et forwarder un avis de rappel 2.7 Gestion des notifications (et réception des notifications) 2.7.1 Envoi des notifications vers d’autres pays 2.7.2 Forward des notifications vers les services de contrôle 2.7.3 Réception des demandes de notification 2.7.4 Stockage des notifications reçues ou envoyées 2.7.5 Recherche et consultation d’une notification

2.8 Gestion des accusés de réception 2.8.1 Création et envoi d’AR vers d’autres États partenaires 2.8.2 Réception et classement des AR dans les dossiers ad hoc 2.9. Gestion des statusupdates 2.9.1. Création et envoi de statusupdates vers d’autres États partenaires 2.9.2. Réception et classement des statusupdates dans les dossiers ad hoc


3. Gestion d’un dossier lié à une requête 3.1 Création d’un dossier 3.2 Recherche sur la base de plusieurs critères de recherche et consultation d’un dossier 3.3 Consultation de la liste des dossiers 3.4 Suppression d’un dossier 3.5 Modification et complétion d’un dossier 4. Gestion des autorités belges et étrangères responsa bles des échanges 4.1 Création d’une autorité 4.2 Suppression d’une autorité 4.3 Modification d’une autorité 5. Gestion des statistiques 5.1 Création de statistiques 5.2 Exportation de statistiques vers certains formats 5.3 Génération d’indicateurs de prestation, entre autres, pour le TBT 6. Gestion des droits d’accès à l’aide de l’IAM du SPF 6.1 Création d’une matrice avec les droits d’accès des utilisateurs 6.2 Modification d’une matrice avec les droits d’accès des utilisateurs 7. Gestion de la propre DB

7.1 Consultation et recherche 7.2 Modification

7.3 Ajout

7.4 Suppression

8. Gestion des annexes 8.1 Scannage des documents sur papier via MyScan (application du SPF) et/ou récupération des documents électroniques

8.2 Stockage dans Filenet (ou d’autres DB) des documents et des annexes électroniques

8.3 Recherche et consultation des annexes

8.4 Liaison d’une annexe à une communication dans un dossier

9. Gestion de l’aide (aide en ligne, documentation, glossaire) 10. Gestion des réponses 10.1 Ajout de la réponse au dossier correspondant


10.2 Validation d’une réponse reçue 10.3 Envoi /forward d’une réponse 2. Cycle de vie. 2.1. L’Administration générale de la perception et du recouvrement. Poursuite des adaptations du module IINV :

• Aux nouvelles compétences de l’Administration générale de la perception et du recouvrement suite à l’intégration de l’administration de la perception non fiscale et d’éventuelles futures modifications à la structure de l’organisation;

• Aux éventuelles modifications des eForms (prévues en 2015) et de l’eForms central application;

• Aux éventuelles modifications de la législation européenne et nationale;

• À toutes les nouvelles plateformes d’échange;

• Après rapport de manquements par les utilisateurs. Lorsque des problèmes sont signalés concernant certaines fonctionnalités, ces problèmes doivent être étudiés, en partie par le business mais aussi par une équipe technique. Le diagnostic du problème, la recherche de solutions et l’implémentation de ces solutions font tous partie de la mission.

2.2. L’Administration générale de la Fiscalité. Au niveau des Impôts directs, on constate une augmentation annuelle du nombre des informations échangées. Les dernières années ont montré que l’échange d’informations constitue un moyen très efficace de lutter contre la fraude fiscale. Outre des effets immédiats, l’échange d’informations a aussi des effets indirects positifs. Du fait que les contribuables sont informés de l’échange d’informations au niveau international, ils déclarent plus facilement spontanément leurs revenus à l’étranger. Des adaptations supplémentaires sont possibles:

• Aux éventuelles modifications aux eForms (prévues en 2015) et à l’eForms central application;


• Aux nouvelles plateformes d’échange;

• Après rapport de manquements par les utilisateurs. Lorsque des problèmes sont signalés concernant certaines fonctionnalités, ces problèmes doivent être étudiés, en partie par le business mais aussi par une équipe technique. Le diagnostic du problème, la recherche de solutions et l’implémentation


de ces solutions font tous partie de la mission.

Nouvelle adaptation du module TVA:

• Aux éventuelles futures modifications dans la structure de l’organisation;

• Aux éventuelles modifications aux eForms (prévues en 2015) et à l’eForms central application;


• Aux nouvelles plateformes d’échange;

• Après rapport de manquements par les utilisateurs. 3. Indicateurs de la future maintenance. 3.1. L’Administration générale de perception et du rec ouvrement. En ce qui concerne le module IINV:

• Élargissement des compétences de l’Administration générale de la perception et du recouvrement. Avec l’intégration de l’administration Perception non fiscale, l’Administration générale de la perception et du recouvrement est désormais aussi compétente en matière d’aide internationale au recouvrement des dettes non fiscales et notamment des amendes pénales et des avances sur pension alimentaire (DAVO). Ces dossiers seront introduits dans STIRint (un canal est déjà prévu). Si nécessaire, un workflow devra être développé. Avant de pouvoir développer ce workflow, il faut mettre en place une concertation avec tous les acteurs concernés, parmi lesquels le SPFJustice.

• eForms. En 2015, des modifications sont apportées aux eForms existants. Parallèlement, la commission poursuit ses activités au niveau de la central eForms application. Cette dernière évolution entraînera une modification plus fondamentale dans la manière de créer et de lire les eForms.

• Modification de la législation et nouvelles plateformes d’échange La Commission européenne étudie actuellement la possibilité d’utiliser le réseau EUCARIS à des fins fiscales, et notamment à des fins de perception. Si cela devait s’avérer possible, après adaptation du Règlement d’exécution 1189/2011, le module IINV devra y être adapté. De plus, la commission étudie aussi le caractère souhaitable et la faisabilité d’adapter la Directive 2010/24/UE.

3.2. L’Administration générale de la Fiscalité


À l’avenir, STIRint devra accueillir de nouveaux projets dans le cadre des décisions de l’OCDE et des nouvelles directives européennes. Pour l’OCDE, les nouvelles applications devraient pouvoir être mises en production en 2018 ou plus tard:

• Real Estate: échange d’informations sur les biens immobiliers; • TRACE: automatisation des échanges d’informations sur les dividendes étrangers; • Élargissement de l’application OCDE aux pays hors OCDE; • Élargissement de l’application Auto_DT aux pays non-UE.

Conformément à la Directive 2011/16/UE, la nouvelle application suivante doit être développée:

• FISCO: automatisation des échanges d’informations sur les dividendes étrangers (2018).

Conformément à la Directive 2011/107/UE, la nouvelle application suivante doit être développée:

• CRS: l’échange de données financières entre les pays européens. La Commission européenne prépare actuellement de nouvelles directives pour renforcer encore la coopération administrative. Adaptation future du module TVA. Comme pour la perception, en 2015, des modifications seront aussi apportées aux eForms existants. Parallèlement, la commission poursuit ses activités au niveau de la central eForms application. Cette dernière évolution entraînera une modification plus fondamentale dans la manière de créer et de lire les eForms. Cette plateforme entraînera des modifications dans les modules de coopération internationale en matière de TVA, d’Impôts directs et de Perception. De la même manière, la connexion au réseau EUCARIS aura des conséquences sur le domaine de la TVA et des adaptations seront nécessaires au niveau du module Coopération internationale en matière de TVA.


ANNEXE 6 : SLA TEMPLATE Le texte en format « italiques » est une précision complémentaire quant à la possibilité d’incidence du point en question du SLA .

1. Gestion de ce document SLA

a. Document historique – Gestion de la version (éventuellement en mentionnant Requests for Change)

b. Liste de distribution pour la distribution du document c. Références aux documents liés

2. Définitions, notions, 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 consignes de mesure; • périodes de début et de fin sur la base de paramètres mesurables. 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 du SLA

a. Description de l’évaluation périodique du SLA

b. Description de la procédure de 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 de modification du/des service(s) fourni(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. La durée du contrat (date de début et de fin) b. Les règles et la procédure relative au renouvellement et à la clôture

prématuré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 vers le 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 vers l’adjudicataire

9. Committment et conditions préalables

a. Commitment de l’adjudicataire en matière de scope b. Conditions préalables (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 ; • …

Formulé autrement : 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 :

• Incident Management • Problem Management • Release Management • Change Management


• Capacity Management • …

Par processus, au moins les points suivants doivent être traités dans le DAP :

• Définition • But • Accords • Procédures • …

12. KPI et Rapports

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, … ;

• Les 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 pour le traitement des plaintes • Du SPF Finances vers l’entrepreneur • De l’entrepreneur vers le SPF Finances

b. Concertation c. Procédure d’escalation – voie à suivre


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 d’application)

18. Vérification 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. Dispositions finales 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 7 : CYCLE DE MAINTENANCE

Le cycle global de maintenance peut globalement être découpé comme suit :

1. Phase d’initiation

• Identification et validation du/des besoin(s) (fonctionnel(s) et/ou technique(s)) • Première évaluation par l’équipe projet quant à la faisabilité et au budget

nécessaire à la réalisation. • Go/NoGo du Comité de Pilotage quant à 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 pleine connaissance par le Comité de Pilotage. Les besoins seront 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 mis à 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 et 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 afin d’obtenir la proposition la plus équilibrée quant à la rencontre 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 engageante est demandée au

fournisseur, 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éthode d’élaboration des critères de réussite, définition des contraintes techniques et de planning, etc.


Des évaluations en « Jour/Homme » obtenues lors 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 projet et du Comité de Pilotage et ne préjuge en rien des étapes préalables (par ex. avis du Conseil des Ministres) et/ou suivantes (ex. 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étaires 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

L’étude fonctionnelle met l’accent sur l’architecture théorique des données et des opérations. Elle précise éventuellement les objectifs, divise le système 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 : o Description des procédures : o Conception de la structure de stockage, avec priorité à la sécurité ; o Mesures de sécurité ; o Structure des packages o …

d) Décision du comité de pilotage du projet

�GO/NOGO


e) Réalisation – Développement & Testing

Pour rappel, la réalisation comprend notamment les activités suivantes : o Détail des spécifications ; o Développement du code; o Tests unitaires ; o Tests d’intégration; o Rédaction de la documentation; o Support aux équipes en charge du testing.

Pour rappel, la phase de test comprend notamment les activités suivantes:

o Elaboration d’un plan de test détaillé ; o Préparation des données de test o Test d’ensembles logiques (tests système et d’intégration) o Test de l’application complète (performance, robustesse, fonctionnalités,

…) o Création et automatisation des tests de non régression o Test de l’infrastructure et des configurations utilisées o 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

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

f) Décision du comité de pilotage du projet �GO/NOGO quant à la mise en production.

g) Exploitation / mise en œuvre

Conversion/migration éventuelle des données et introduction dans le système : o Mise au point d’un plan de conversion et d’introduction, y compris les

instructions détaillées; o Conversion/migration des données ; o Support au déploiement du nouveau système ; o Formation/information ; o Support o …

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.