Cahier spécial des charges - SPF Finances · 2013 en ayant livré que partiellement les produits demandés. Il s’en est suivi un contrat de bugfixing en 2013 et un autre de maintenance

Cahier des charges S&L/AO/437/2015 1/149

Cahier spécial des charges : Appel d’offres ouvert pour « FIRST 2015 »

Publication au niveau européen

Cahier spécial des charges n° S&L/AO/437/2015 Ouverture des offres : 06/10/2015 à 10h00

Errata : Page 8,12, 14, 22, 27,34, 44, 99, 101, 107, 108 à 127, 133, 134


TABLE DES MATIERES A. DEROGATIONS GENERALES ............................. ........................................................... 5

B. DISPOSITIONS GENERALES ......................... ................................................................ 5

1. Description du marché. .................................................................................................................................... 5

1.1. CADRE GENERAL................................................................................................................. 5

1.2. CADRE SPECIFIQUE ............................................................................................................ 6

2. Objet ................................................................................................................................................................ 7

3. Durée du contrat. ............................................................................................................................................. 8

4. Pouvoir adjudicateur – Informations complémentaires. ................................................................................... 8

5. Documents régissant le marché ....................................................................................................................... 9

5.1. LEGISLATION ........................................................................................................................ 9

5.2. DOCUMENTS DU MARCHE ................................................................................................. 9

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

6.1. INCOMPATIBILITES .............................................................................................................. 9

6.2. CONFLITS D’INTERETS ....................................................................................................... 9

7. Session d’information. .................................................................................................................................... 10

C. ATTRIBUTION .................................... ............................................................................11

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

1.1. DROIT ET MODE D’INTRODUCTION DES OFFRES ........................................................ 11

1.1.1. OFFRES INTRODUITES PAR DES MOYENS ELECTRONIQUES ............................ 11

1.1.2. OFFRES NON INTRODUITES PAR DES MOYENS ELECTRONIQUES................... 12

1.1.3. MODIFICATION OU RETRAIT D’UNE OFFRE DEJA INTRODUITE ......................... 13

1.2. OUVERTURE DES OFFRES ............................................................................................... 14

2. Offres ............................................................................................................................................................. 14

2.1. DONNEES A MENTIONNER DANS L’OFFRE .................................................................... 14

2.2. STRUCTURE DE L’OFFRE ................................................................................................. 15

2.3. DUREE DE VALIDITE DE L’OFFRE.................................................................................... 16

2.4. DOCUMENTS ET ATTESTATIONS A JOINDRE A L’OFFRE ............................................ 16

3. Prix. ................................................................................................................................................................ 16

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

4.1. DROIT D’ACCES ET SELECTION QUALITATIVE ......................................................... 16

4.1.1. DROIT D’ACCES ......................................................................................................... 16

4.1.2. SELECTION QUALITATIVE ........................................................................................ 20

4.2. REGULARITE DES OFFRES .......................................................................................... 21

4.3. CRITERES D’ATTRIBUTION ............................................................................................... 21

4.3.1. LISTE DES CRITERES D’ATTRIBUTION ........................................................................ 21

D. EXECUTION ....................................................................................................................25

1. Fonctionnaire dirigeant................................................................................................................................... 25

2. Révision de prix. ............................................................................................................................................ 25

3. Responsabilité du prestataire de services...................................................................................................... 26

4. Garantie ......................................................................................................................................................... 26

5. Réception des services prestés. .................................................................................................................... 27

5.1. RECEPTIONS PROVISOIRES PARTIELLES ..................................................................... 27

5.2. RECEPTION DEFINITIVE ................................................................................................... 27

6. Cautionnement ............................................................................................................................................... 27

6.1. CONSTITUTION DU CAUTIONNEMENT ........................................................................... 27

6.2. LIBERATION DU CAUTIONNEMENT ................................................................................. 29

7. Exécution des services. ................................................................................................................................. 29

7.1. LIEU OU LES SERVICES DOIVENT ETRE EXECUTES.................................................... 29

7.2. CONDITIONS DE L’EXECUTION. ....................................................................................... 29

7.3. SUIVI DE LA BONNE EXECUTION DES LIVRAISONS ET DES SERVICES .................... 31

7.4. CLAUSE D’EVOLUTION TECHNOLOGIQUE ..................................................................... 32

7.5. MATERIEL ET EQUIPEMENT DE L’ADMINISTRATION .................................................... 32

7.6. DELAIS D’EXECUTION ....................................................................................................... 34

7.7. CONTROLE DES PRESENCES ET PRESTATIONS ......................................................... 34

7.8. CONTROLE ET ENCADREMENT DU MARCHE ................................................................ 35

7.8.1. DECISION GO/NO GO ..................................................................................................... 36

7.8.2. ASPECTS PERSONNELS ................................................................................................ 36

7.9. ACCES AUX LOCAUX ET SECURITE ................................................................................ 36

7.10. NORMES ET STANDARDS A RESPECTER .................................................................... 37

7.11. GESTION DES CHANGEMENTS (« CHANGE MANAGEMENT ») .................................. 38

7.12. CLAUSE D’EXECUTION ................................................................................................... 38


8. Propriété des softs développés ...................................................................................................................... 39

9. Facturation et paiement des services. ........................................................................................................... 41

10. Engagements particuliers pour le prestataire de services. ........................................................................... 42

11. Clause du client le plus avantagé ................................................................................................................ 44

12. Litiges........................................................................................................................................................... 44

13. Amendes et Pénalités. ................................................................................................................................. 44

13.1. PENALITES ........................................................................................................................ 44

13.2. AMENDES .......................................................................................................................... 44

13.3. IMPUTATION DES AMENDES ET PENALITES ............................................................... 45

E. PRESCRIPTIONS TECHNIQUES ....................................................................................46

1. Introduction .................................................................................................................................................... 46

2. Remarques concernant la structure du volet technique du cahier des charges ............................................. 46

2.1 DEFINITIONS UTILISEES, ABREVIATIONS ET ACRONYMES. ........................................ 46

3. Contexte de la mission ................................................................................................................................... 47

3.1 CONTEXTE GENERAL ........................................................................................................ 47

3.2 CONTEXTE TECHNIQUE .................................................................................................... 53

3.3 CONTEXTE ORGANISATIONNEL. ...................................................................................... 54

4 Description de la mission. ............................................................................................................................... 58

4.1 DESCRIPTION GENERALE DE LA MISSION ..................................................................... 58

4.2 METHODE DE DEVELOPPEMENT ..................................................................................... 58

4.3 INTEGRATION ET DEPLOIEMENT DANS L’ENVIRONNEMENT DU SPF FINANCES ..... 58

4.4 POSTES A REALISER ......................................................................................................... 60

4.4.1 TRANCHE 1 : « INTAKE GENERIQUE » .......................................................................... 60

4.4.2 TRANCHE 2 « AMELIORATION ACCOUNTING + INTERFACE GL AVEC FEDCOM » . 77

5 Encadrement de la mission ........................................................................................................................... 104

5.1 PHASAGE ........................................................................................................................... 104

5.2 ASPECTS LIES AU PERSONNEL ..................................................................................... 104

5.3 DOCUMENTATION A PRODUIRE. .................................................................................... 104

6 Services à fournir .......................................................................................................................................... 105

6.1 TRANSFERT DE CONNAISSANCE ................................................................................... 105

6.2 ASSISTANCE COMPLEMENTAIRE ................................................................................... 106

6.3 TRANSFERABILITE............................................................................................................ 106

6.4 MAINTENANCE ET SUPPORT .......................................................................................... 107

7. SLA .......................................................................................................................................................... 108

7.1. INTRODUCTION ................................................................................................................ 108

7.2. PRINCIPE D’ELABORATION DES SLA DANS LE CADRE DE CE MARCHE ET DELIVERABLES CORRESPONDANTS ................................................................................... 110

7.2.1. SLA - modèle SPFFIN (= SPF Finances) .............................................................................................. 110

7.2.2. Concept de « Dossier Accords et Procédures (DAP) » – contenu ......................................................... 110

7.2.3. Tableau des KPI avec clauses de pénalité ............................................................................................ 112

7.2.4. Service Level Reporting (SLR) - rapportage niveau de service ............................................................. 112

7.2.5. Service Quality Plan (SQP) – plan de qualité de service ....................................................................... 112

7.2.6. Service Improvement Plan (SIP) – Plan d’amélioration.......................................................................... 112

7.2.7. Service Level Management .................................................................................................................... 112

7.2.8. Délai d’élaboration et moyens mis à disposition pour l’élaboration du DAP après l’attribution du marché ......................................................................................................................................................................... 113

7.3. ENCADREMENT DES SLA ............................................................................................... 113

7.3.1. Relation entre SLA et ITIL© V3-2011 – Glossary ................................................................................... 113

7.3.2. Relations entre SLA et normes et fondements ICT du SPF Finances. .................................................. 113

7.3.3. Principe des Quality Gates dans les cycles de développement ............................................................. 114

7.3.4. Environnements à supporter dans le cadre de ces SLA ........................................................................ 115

7.4. SERVICE LEVELS ET ENGAGEMENTS DE RESULTATS Y AFFERENTS .................... 115

7.5. SERVICE LEVELS CONCERNANT LA GESTION DE PROJETS : DELAI, EXHAUSTIVITE ET PLANIFICATION .................................................................................................................. 116

7.5.1. PI-Project Plan-Planning ........................................................................................................................ 116

7.6. NIVEAUX DE SERVICE PHASE DE DEVELOPPEMENT : CONFORMITE A LA METHODOLOGIE FUP, AUX STANDARDS ICT ET QUALITE DU CODE ............................. 116

7.6.1. PI-FUP-deliverables ............................................................................................................................... 117

7.6.2. PI-FUP-tools & ICT- standards .............................................................................................................. 117

7.6.3. PI-Quality-of-Code ................................................................................................................................. 118

7.6.4. PI-Security-Integrity-Code ...................................................................................................................... 118

7.7. SERVICE LEVELS MISE EN PRODUCTION .................................................................... 118

7.7.1. PI-Continuous-Integration-Tool-Chain ................................................................................................... 118

7.7.2. PI-Releases-in-production ...................................................................................................................... 119


7.8. SERVICE LEVELS EXIGENCES NON FONCTIONNELLES ............................................ 119

7.8.1. PI–Availibility-7x12x365 ......................................................................................................................... 119

7.8.1.1. PÉRIODES D’OUVERTURE D’UN SERVICE (SERVICE WINDOW) ET PÉRIODES DE MAINTENANCE ........................................................................................................................ 119

7.8.1.2. PI–AVAILABILITY-7X12X365-FIRST NORMES DES SERVICE WINDOWS ............. 119

7.8.1.3. CLAUSE DE PÉNALITÉ PI–AVAIL(ABILITY) .............................................................. 120

7.8.2. PI-Performance ...................................................................................................................................... 120

7.9. SERVICE LEVELS EN MATIERE DE TRAITEMENT D’INCIDENTS, D’INTERVENTIONS CORRECTRICES ET REACTIVES .......................................................................................... 120

7.9.1. Priorités des incidents ............................................................................................................................ 121

7.9.2. Matrice des priorités ............................................................................................................................... 121

7.9.3. PI-Incident-Response-Time ................................................................................................................... 122

7.9.4. PI-Incident-Resolution-Time ................................................................................................................... 123

7.10. SERVICE LEVELS CONCERNANT LES SERVICES DU PERSONNEL MIS A DISPOSITION PAR L’ENTREPRENEUR ................................................................................. 123

7.10.1. PI-Staff-Timesheet ............................................................................................................................... 123

7.11. SERVICE LEVELS RELATIFS AU RAPPORTAGE PERIODIQUE SUR LES SLA ........ 124

7.11.1. Rapportage Service Level (SLR) général ............................................................................................. 124

7.11.2. PI-SLR ................................................................................................................................................. 125

7.12. PERIODES D’APPLICATION DES DIFFERENTS SLA .................................................. 125

7.13. SANCTIONS .................................................................................................................... 125

7.13.1. Principe des propositions d’amendes................................................................................................... 126

7.14. SLA MONITORING ET CONCERTATION DE SERVICE MANAGEMENT..................... 126

7.14.1. SLA-monitoring .................................................................................................................................... 126

7.14.1.1. MONITORING DE BASE AU SEIN DU SPF FINANCES .......................................... 126

7.14.1.2. ASSISTANCE DANS LE CADRE DU MONITORING PAR L’ADJUDICATAIRE ...... 126

7.14.1.3. CONCERTATION DE SERVICE MANAGEMENT..................................................... 127

7.15. AUTRES SERVICE LEVELS, ENGAGEMENTS DE RESULTATS ET REMARQUE FINALE ...................................................................................................................................... 127

F. ANNEXES ...................................................................................................................... 129

ANNEXE 1 : FORMULAIRE D’OFFRE ..................... ......................................................... 130

ANNEXE 2 : INVENTAIRE ............................. .................................................................... 133

ANNEXE 3 STANDARDS ICT DU SPF FINANCES – DIRECTIVES TECHNIQUES (INFORMATIQUES) ...................................................................................................... 135

ANNEXE 4 : CURRICULUM VITAE ....................... ............................................................ 145

ANNEXE 5 : MODELE DE REFERENCE PROJETS SIMILAIRES . ................................... 148


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/437/2015 APPEL D’OFFRES OUVERT POUR « FIRST 2015 ».

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 et pénalités; - 25 de l’arrêté royal du 14 janvier 2013 relatif au cautionnement; - 33 de l’arrêté royal du 14 janvier 2013 relatif à la libération du cautionnement.

B. DISPOSITIONS GENERALES

1. Description du marché.

1.1. Cadre général Depuis une décennie, le SPF Finances a entrepris une large modernisation et un remodelage de son organisation, de ses méthodes de travail et de ses solutions informatiques en vue d’augmenter la qualité de ses services au public, d’améliorer l’environnement de travail des fonctionnaires et de rationaliser leurs tâches. Au travers de la réforme Copernic, appelée de manière spécifique « Coperfin » pour le SPF Finances, et des derniers arrêtés royaux fixant l’organisation du SPF. Dans le cadre de cette réforme, un des objectifs prioritaires reste l’harmonisation et l’amélioration des procédures existantes de gestion et de traitement Business/ICT des anciennes administrations en intégrant un nombre maximum d’applications et de données pour créer des interfaces et de nouveaux systèmes applicatifs uniformisés qui faciliteront la communication des informations, le travail des utilisateurs et la visibilité des citoyens.


Les bases de réflexion pour cette nouvelle structure de traitements intégrés trouvent leur origine dans les conclusions des études et des BPR réalisés dans le cadre de Coperfin. Cette réforme a débouché sur un plan ICT de réalisations. Afin d’opérationnaliser la nouvelle structure du SPF Finances qui supportera les nouveaux processus de travail implémentés au travers de la mise en œuvre des Systèmes Intégrés, le projet OPERA a démarré courant 2005 et est toujours en cours. Ce projet définit le cadre opérationnel dans lequel se déploieront les futurs systèmes intégrés en cours de construction au sein des différentes Entités de notre SPF. Depuis 2004 le SPF Finances a lancé plusieurs grands projets d’implémentation des Systèmes intégrés. Les projets transversaux tels que SITRAN (Signalétique Transversale), IAM (Identity Access Management), Annucomp (Annuaire des compétences), DIM (Data Input Management) sont déjà en production. Le projet FIRST pour la Perception et le Recouvrement est également partiellement en production. En parallèle, le SPF Finances poursuit la mise en œuvre de ses fondements ICT. L’ensemble des descriptions relatives à ces Fondements est accessible sur le site du SPF Finances aux adresses ci-dessous : Numéro Description

[1] La documentation sur les normes et bases ICT et le Finance Unified Process (FUP) (en néerlandais) http://financien.belgium.be/nl/over_de_fod/geschiedenis_modernisering/ict/ict_fundamenten/

[2] La documentation sur les normes et bases ICT et le Finance Unified Process (FUP) (en français) http://finances.belgium.be/fr/sur_le_spf/historique_modernisation/ict/ict_fundamenten/

1.2. Cadre spécifique First est un projet qui vise à développer la suite du système de traitement intégré multi-entités recouvrement (STIMER) dont le contrat initial avec l’adjudicataire a pris fin en janvier 2013 en ayant livré que partiellement les produits demandés. Il s’en est suivi un contrat de bugfixing en 2013 et un autre de maintenance évolutive en 2014. Les deux avaient pour objectif de stabiliser techniquement les modules en production. L’objectif de l’actuel marché est de faire évoluer l’outil existant en lui apportant des améliorations et des fonctionnalités supplémentaires. Elles consistent à développer trois produits repris chacun dans une tranche, à savoir :

• Tranche 1 : un intake générique ;

• Tranche 2 : une amélioration du module de perception-comptabilité ;

• Tranche 3 : un module générique d’actions de recouvrement pour tous les produits que l’AGPR est ou serait appelée à traiter au niveau perception et recouvrement avec l’outil First.

Concrètement, ce projet a pour objet de permettre à l’Administration Générale de Perception et de Recouvrement de :


• prendre en charge toute demande interne ou externe, nationale ou internationale de

perception et/ou de recouvrement de dette ainsi que le remboursement aux tiers via un module générique « Intake générique » qui représente la Tranche 1 de ce marché.

• Améliorer le module Accounting pour y ajouter d’autres fonctionnalités, notamment,

implémentation de l’interfaces G/L avec le programme Fedcom et la fonctionnalité de remboursement aux ayants droits. Ce livrable représente la Tranche 2 de ce marché.

• permettre d’initier des actions de recouvrement à partir d’un module générique se

basant sur des paramètres tels que la signalétique du débiteur, informations concernant la dette à recouvrer et des informations liées au paiement à recevoir. Cette fonctionnalité doit être orientée vers des applications et/ou organismes internes et/ou externes au SPF Finances. Elle doit permettre l’interaction avec ces applications et/ou organismes (modification, clôture, coûts et actes) dans les deux sens. Ce livrable représente la Tranche 3 de ce marché.

2. Objet Le présent marché a pour objet les trois tranches reprisent ci-dessus. Il s’agit de trois (3) tranches fermes. Le SPF Finances entend obtenir une offre unique pour l’ensemble de ces trois tranches. Elles sont décrites dans la partie « Prescriptions techniques » et devront être réalisées sur les plateformes mises à disposition par le SPF Finances et selon les standards de technologie et de développement définis par le SPF. L’ensemble de ces tranches devra être réalisé en parfaite collaboration avec le SPF Finances qui entend obtenir les connaissances nécessaires au terme de chacune des tranches pour assurer la maintenance du système de manière autonome. Cet aspect de collaboration et de transfert de know how fera partie des livrables des projets et fera l’objet d’une évaluation systématique. Le SPF Finances met en œuvre des méthodes de travail (suivi de procédure de travail, framework de développement, procédure de mise en production…) et de gestion de projet pour lesquelles nous attendons de l’adjudicataire un parfait respect et une description de la manière dont il se conformera aux exigences du SPF tout en y apportant son expertise. Par ailleurs, le SPF Finances juge indispensable que certains rôles soient prévus de manière explicite et maintenus tout au long de la réalisation du projet. Notamment, le SPF Finances entend obtenir des responsables distincts (architectes) qui veilleront et coordonneront les activités pour garantir l’intégrité et la réalisation des aspects business, applicatifs et technique en parfaite collaboration avec le personnel du SPF. Par ailleurs, l’intégration de ces différentes activités sera sous la responsabilité du fournisseur. Chaque tranche sera développée en respectant la découpe prévue dans la méthodologie de développent standard du SPF (Finance Unified Process). La procédure choisie est celle de l’appel d’offres ouvert avec publicité européenne. Il s’agit d’un marché mixte (A.R. 15 juillet 2011, art. 2, 7°). Les variantes et les options ne sont pas autorisées.


Ce marché comporte un seul lot. Le pouvoir adjudicateur se réserve le droit de ne pas attribuer ce marché et de décider que ce dernier fera l’objet d’un ou plusieurs nouveaux marchés, au besoin suivant un autre mode de procédure. Une offre incomplète entraîne l’exclusion de l’offre.

3. Durée du contrat. Le pouvoir adjudicateur renseigne, la date de début d’exécution du contrat dans le courrier de notification d’attribution du marché. Le contrat est conclu pour une durée de sept (7) ans. Ce contrat comprend aussi bien le développement que la maintenance pour l’ensemble des tranches ainsi que le système existant en production. En ce qui concerne la tranche 1, chaque partie peut mettre fin au contrat à la fin de la deuxième année, de la troisième année, la quatrième année, cinquième année, sixième année à condition que la notification à l’autre partie soit faite par lettre recommandée:

- au moins (6) six mois avant la fin de l’année d’exécution en cours si le pouvoir

adjudicateur met fin au contrat,

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

En ce qui concerne les tranches 2 et 3, chaque partie peut mettre fin au contrat à la fin de la troisième année, la quatrième année, cinquième année, sixième année à condition que la notification à l’autre partie soit faite par lettre recommandée:

- au moins (6) six mois avant la fin de l’année d’exécution en cours si le pouvoir

adjudicateur met fin au contrat,

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

Le pouvoir adjudicateur se réserve par ailleurs le droit, moyennant un préavis de 30 jours de calendrier à signifier par lettre recommandée, de mettre fin au contrat, en tout temps, de plein droit et sans indemnité pour le prestataire, si le projet FIRST devait être abandonné par les services du SPF FINANCES avant l’échéance du contrat. Dans ces deux cas (résiliation annuelle ou pour cause d’abandon de l’application), la partie qui subit la résiliation du contrat ne peut réclamer de dommages et intérêts.

4. 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 des charges ou pour toute remarque, le soumissionnaire peut prendre contact avec les gestionnaires du projet à l’adresse e-mail : [email protected]


5. Documents régissant le marché

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

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

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

- Toutes les modifications à la loi et aux arrêtés précités, en vigueur au jour ultime

prévu dans le présent cahier spécial des charges pour le dépôt des offres.

5.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/437/2015. - L’offre approuvée de l’adjudicataire.

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

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

6.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 ou de ses clients, dans les deux ans qui suivent son/leur démission, départ à la retraite ou tout autre type de départ du SPF Finances ou de ses clients, 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é.

7. Session d’information. Vu la complexité du marché, le pouvoir adjudicateur a décidé d’organiser une séance d’information unique à l’intention des candidats-soumissionnaires. La séance se tiendra entre le moment de la publication du marché au Bulletin des Adjudications et au Journal des Publications de l’Union Européenne et le jour de l’ouverture des offres. Après cette séance d’information, il ne sera plus r épondu à aucune question, afin que tous les candidats-soumissionnaires soient traités sur le même pied. La séance d’information se tiendra le 28/08/2015 à 10 heures , à l’adresse suivante : Boulevard du Roi Albert II 33, 1030 Bruxelles. Il sera exclusivement répondu aux questions écrites qui seront soumises au plus tard le 18/08/2015. Ces questions peuvent exclusivement être adressées par courrier électronique à l’adresse : [email protected] Toutes les questions doivent obligatoirement mentionner les références au cahier des charges pour faciliter une réponse rapide (p.ex. Partie 1, point 1.1, paragraphe 1, page 1). Veuillez aussi préciser la langue du cahier des charges que vous utilisez (les numéros de page peuvent varier avec la langue). Au cours de la séance d’information, l’objet du marché sera brièvement exposé. Les réponses aux questions posées à temps seront données oralement durant la séance d’information, puis publiées sur le site Internet du SPF Finances. Les entreprises intéressées sont invitées à se faire connaître à l’avance en envoyant un courriel à l’adresse [email protected] , avec le nom et la fonction de la ou des personnes qui assisteront à la séance d’information. Pour des raisons d’organisation, chaque entreprise peut dépêcher au maximum deux personnes. Si les entreprises intéressées constatent des lacunes ou des imprécisions dans le cahier des charges, elles sont invitées à en faire état par écrit avant la séance d’information, suivant les mêmes modalités que pour l’envoi des questions. Le SPF Finances attache une grande importance à l’égalité de traitement entre les soumissionnaires. Les spécifications de ses cahiers des charges sont rédigées à la lumière de cette volonté. Si une firme intéressée estime néanmoins que sa candidature est exclue ou que ses chances sont diminuées par certaines spécifications de ce cahier des charges, elle est invitée à le faire savoir par écrit, au plus tard lors de la séance d’information. Au besoin, le SPF adaptera le cahier des charges, s’il le juge nécessaire, pour en tenir compte.


C. ATTRIBUTION

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

1.1. Droit et mode d’introduction des offres Sans préjudice des variantes éventuelles, chacun des soumissionnaires ne peut remettre qu'une offre par marché. En application de l’article 52, § 2, de l’arrêté royal du 15 juillet 2011, le pouvoir adjudicateur accepte l’utilisation de moyens électroniques pour l’introduction des offres. Par conséquent, les offres peuvent être introduites comme suit: 1) ou bien électroniquement via l’application e-tendering (voir ci-dessous pour plus

d’informations) 2) ou bien par lettre (une lettre recommandée est conseillée) envoyée au pouvoir

adjudicateur 3) ou bien personnellement déposées auprès du pouvoir adjudicateur. 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 juillet 2011). Les offres qui sont introduites par des moyens électroniques, peuvent ê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 dès les joindre à l’offre. Certains documents à joindre qui ne peuvent pas être produits ou qui peuvent être difficilement produits par des moyens électroniques, peuvent être délivrés sur papier avant la date limite de réception. En introduisant son offre entièrement ou partiellement via des moyens électroniques, le soumissionnaire accepte que les données qui résultent du fonctionnement du système de réception de son offre, soient enregistrées. Plus d'informations peuvent être obtenues sur le site: HTTP://WWW.PUBLICPROCUREMENT.BE ou via le numéro de téléphone du helpdesk du service e-procurement: +32 (0)2 790 52 00. IMPORTANT 1. Il est recommandé au soumissionnaire de s’enregistrer au plus tard la veille de

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


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

1.1.2. Offres non introduites par des moyens électroniques Les offres qui sont introduites sur papier et les offres qui sont libellées par des moyens électroniques mais qui ne sont pas introduites par ces moyens, sont glissées dans une enveloppe fermée. Les offres seront déposées 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 mentionné ci-dessous ; - à la poste. Toute autre modalité d’expédition (comme Taxipost, courrier exprès, etc.) se fera sous l’entière responsabilité du soumissionnaire. Les offres sont acceptées pour autant que la séance d’ouverture des offres n’ait pas été déclarée ouverte. Toutefois, une offre 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'offre 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. L’offre sera déposée en trois exemplaires sur papier dont un original et un exemplaire sur support électronique (CD-ROM) dans un format PDF . En cas de divergence entre la version papier et la version électronique, l’exemplaire original de la version papier fera foi. Le soumissionnaire procèdera à un ScanVirus du support électronique afin d’éviter toute contamination par virus de l’infrastructure informatique du SPF-Finances. Il indiquera dans son offre : le logiciel utilisé pour le ScanVirus (et la version de celui-ci) et la garantie que le support a été vérifié et ne contient pas de virus. Le SPF Finances procèdera également un ScanVirus après l’ouverture des offres. L’offre sera glissée dans une enveloppe fermée port ant les deux indications suivantes - la référence du cahier spécial des charges : S&L/AO/437/2015 - a date et l’heure de l’ouverture des offres : le 06/10/2015 à 10h00 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/437/2015 - 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: o OPDECAM Christine 0257/63 482 o VAN OVERWAELLE Wendy 0257/68 347


o AUBRY Céline 0257/89 634 o DEBANDE Michaël 0257/79 775 o DE PROOST Patricia 0257/73 122 o WOUTERS Bart 0257/53 133 o BOSMAN Heidi 0257/62 865

- à l’endroit prévu à cet effet l’adresse du destinataire. Le soumissionnaire qui remet son offre 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’offre est déposée par porteur, un accusé de réception ne sera délivré que si la demande en est faite expressément auprès d’un fonctionnaire repris ci-dessus. Il est important de noter que seul cet accusé de réception peut servir de preuve du dépôt de l’offre. Le soumissionnaire assume l’entière responsabilité des modalités d’envoi et de réception de son offre dans les délais impartis. Les offres 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. Remarque: pour des raisons techniques et organisationnelles, le pouvoir adjudicateur préfère que les offres soient introduites électroniquement. Le choix appartient bien entendu

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

Division Achats A l’attention de Monsieur Frédéric DUPONT, Conseiller

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

1030 BRUXELLES


au soumissionnaire et en aucune façon ce choix n’aura d’influence sur l’analyse et l’évaluation de l’offre.

1.2. Ouverture des offres La séance d’ouverture des offres aura lieu le 06/10 /2015 à 10h00, dans une des salles de réunion du North Galaxy, accessible via l’entrée « visiteurs », boulevard du Roi Albert II, 33 à 1030 BRUXELLES, (sans proclamation des prix). 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.

2. Offres

2.1. Données à mentionner dans l’offre Il est fortement recommandé au soumissionnaire d’utiliser le formulaire d’offre joint en annexe. Dans cette optique, l’attention du soumissionnaire est attirée sur l’article 80 de l’arrêté royal du 15 juillet 2011, qui stipule: "Lorsqu’aux documents du marché est joint un formulaire destiné à établir l’offre 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: - le prix forfaitaire global pour le développement des 3 tranches ; - le prix forfaitaire mensuel de la maintenance (concerne tant le système actuel que les

produits à livrer) préventive, corrective (Bugs Fixing), évolutive; - le montant forfaitaire de l’assistance complémentaire ; - la signature de la personne ou les personnes, selon le cas, ayant mandat pour signer

l’offre ; - la qualité de la personne ou des personnes, selon le cas, qui signe(nt) l’offre ; - la date à laquelle la personne ou les personnes précitée(s), selon le cas, a/ont signé

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

des Entreprises (pour les soumissionnaires belges) ; - le numéro d’inscription à l’ONSS ;


- le numéro et le libellé du compte du soumissionnaire ouvert auprès de la Banque de la Poste ou d’un autre établissement financier ;

- les noms, prénoms, la qualité ou profession, la nationalité et le domicile du soumissionnaire ou lorsque celui-ci est une société, sa raison sociale ou dénomination, sa forme juridique, sa nationalité et son siège social ;

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

2.2. Structure de l’offre L’offre du soumissionnaire se compose obligatoirement de quatre volets distincts : 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 : 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é, réalisés au cours des trois dernières années ;

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

- La déclaration quant aux services exécutés au cours des 3 dernières années ; Volet B « Volet financier » Ce volet de compose de : Le tableau de prix : détailler et résumer les coûts (modèle: voir ci-dessous) Volet C « Volet technique » L’offre suit la structure de la partie III du cahier spécial des charges. Volet D « Annexes » Dans ce volet, le soumissionnaire joint à son offre des documents qui permettent de clarifier son offre.


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

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 4 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é à prix mixte.

a. Tous les prix mentionnés dans le formulaire « inventaire » doivent être obligatoirement libellés en euros.

b. Dans son offre, le soumissionnaire indiquera les prix de toutes les parties de l'offre. Il complétera à cet effet l'inventaire prévu en annexe du présent cahier spécial des charges (annexe « inventaire »).

c. Les prix sont mentionnés tous frais compris, mais hors TVA. L'offre doit mentionner le prix de TVA inclusif séparé de celle-ci pour chaque partie de l'offre.

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 4.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é Sociale toutes les déclarations requises

jusque et y compris celles relatives à l’avant-dernier trimestre civil écoulé par rapport à la date limite de réception des offres et

2° n’a pas pour ces déclarations une dette en cotisations supérieure à 3.000 EUROS,

à moins qu’il n’ait obtenu pour cette dette des délais de paiement qu’il respecte strictement.

Toutefois, même si la dette en cotisations est supérieure à 3.000 EUROS, le soumissionnaire sera considéré comme étant en règle s’il établit, avant la décision d’attribuer le marché, qu’il possède, à la fin du trimestre civil visé à 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.

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

§ 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. Pour le soumissionnaire ou le candidat


belge, le pouvoir adjudicateur procédera lui-même à la vérification des obligations en matière de cotisations de sécurité sociale.

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

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

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

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

En vue de l’application du présent paragraphe, le pouvoir adjudicateur a le droit de demander aux soumissionnaires de fournir les renseignements ou documents nécessaires. Lorsqu’il a des doutes sur la situation personnelle de ces candidats ou soumissionnaires, il peut s’adresser aux autorités compétentes belges ou étrangères pour obtenir les informations qu’il estime nécessaires à ce propos. Troisième critère d’exclusion Conformément à l’article 20 de la loi et à l’article 61, § 2, 1° et 2° de l’arrêté royal du 15 juillet 2011, peut être 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.

Pour le soumissionnaire ou le candidat belge, le pouvoir adjudicateur procédera lui-même à

la vérification de sa situation en matière de faillite. 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é, 1957) 2° le droit à la liberté syndicale (convention n° 87 sur la liberté syndicale et la protection du

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

d’organisation et de négociation collective, 1949) 4° l’interdiction de toute discrimination en matière de travail et de rémunération (conventions

n° 100 sur l’égalité de rémunération, 1951 et n° 111 concernant la discrimination (emploi et profession), 1958)

5° l’âge minimum fixé pour le travail des enfants (convention n° 138 sur l’âge minimum,

1973), ainsi que l’interdiction des pires formes du travail des enfants (convention n° 182 sur les pires formes du travail des enfants, 1999).

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, conformément aux dispositions de l’article 63 de l’AR du 15 juillet 2011. Est en règle par rapport aux obligations susmentionnées applicables en Belgique, le candidat ou le soumissionnaire qui n'a pas pour l'ensemble de ses obligations fiscales professionnelles une dette supérieure à 3.000 euros, à moins qu'il n'ait obtenu pour cette dette des délais de paiement qu'il respecte strictement. Toutefois, même si la dette fiscale professionnelle est supérieure à 3.000 euros, le candidat ou le soumissionnaire est considéré comme étant en règle s'il établit, avant la décision de sélection ou d'attribution du marché, selon le cas, qu'il possède à l’égard d’un pouvoir adjudicateur au sens de l’article 2,1°, de la loi ou d’une entreprise publique au sens de l’article 2,2°, de la loi, à la fin de la période fiscale visée précédemment, une ou des créances certaines, exigibles et libres de tout engagement à l'égard de tiers pour un montant au moins égal, à 3.000 euros près, à celui pour lequel il est en retard de paiement de ses dettes fiscales professionnelles. Pour le soumissionnaire ou le candidat belge, le pouvoir adjudicateur, ayant accès gratuitement à l'attestation du SPF Finances, procèdera à la vérification de la situation de tous les soumissionnaires dans les quarante-huit heures suivant la séance d'ouverture des offres. IMPORTANT


Il est rappelé au soumissionnaire ou au candidat qu i possède une dette fiscale professionnelle supérieure à 3.000 euros et qui peu t se prévaloir d’une créance à l’égard d’un pouvoir adjudicateur ou d’une entrepri se publique qu’il convient au soumissionnaire ou au candidat d’établir qu’il poss ède une telle créance et que celle-ci soit certaine, exigible et libre de tout engagem ent à l’égard de tiers. A cette fin, le soumissionnaire est invité à commun iquer dans son offre l’existence d’une ou de créances pouvant être prises en considé ration par le pouvoir adjudicateur ainsi que le caractère certain, exigible et libre d e tous engagements à l’égard de tiers. Pour que le soumissionnaire étranger ou le candidat étranger soit considéré comme étant en règle celui-ci joint à sa demande de participation ou à son offre, selon le cas, une attestation dont il résulte qu'il est en règle par rapport à ses obligations fiscales professionnelles selon les dispositions légales du pays où il est établi. Cette attestation doit 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) Pour pouvoir introduire une soumission pour le marché, le soumissionnaire doit : avoir réalisé, pour chacun des trois derniers exercices comptables clôturés, un chiffre d'affaires cumulé relatif à des services de même nature que le présent marché d’au moins 5.000.000 EUR (art. 67, 3° A.R. du 15 juillet 2011). Cette capacité financière sera jugée sur base des comptes annuels approuvés des trois dernières années déposés auprès de la Banque Nationale de Belgique. Les soumissionnaires qui ont déposé les comptes annuels approuvés auprès de la Banque Nationale de Belgique, ne sont pas tenus de les joindre à leur offre, étant donné que le pouvoir adjudicateur est à même de les consulter via le guichet électronique de l’autorité fédérale Les soumissionnaires qui n’ont pas déposé les comptes annuels approuvés des trois dernières années comptables auprès de la Banque Nationale de Belgique, sont tenus de les joindre à leur offre. Cette obligation vaut également pour les comptes annuels approuvés récemment et qui n’ont pas encore été déposés auprès de la Banque Nationale de Belgique, parce que le délai légal accordé pour le dépôt de ceux-ci n’est pas encore échu. Pour les entreprises individuelles, il convient de faire rédiger un document reprenant tous les actifs et tous les passifs par un comptable IEC ou un réviseur d’entreprise. Ce document doit être certifié conforme par un comptable IEC agréé ou par le réviseur d’entreprise, selon le cas. Le document doit refléter une situation financière récente (datant de 6 mois au maximum, à compter de la date d’ouverture des offres). Au cas où l’entreprise n’a pas encore publié de compte annuel, un bilan intermédiaire certifié conforme par le comptable IEC ou par le réviseur d’entreprise suffit.


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) Le soumissionnaire joindra à son offre : Un minimum de 3 références (en utilisant le modèle de l’annexe 6) de services exécutés, au cours des trois dernières années satisfaisant aux conditions cumulatives suivantes : - développements de logiciels dont les fonctionnalités sont similaires à celles du présent

marché. - Java/J2EE-based, DB2. - de min. 500.000 euros/an Pour chaque référence, il est demandé qu’une appréciation du client pour qui le service a été exécuté soit communiquée sous peine de non prise en considération de cette référence.

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 d’attribution Pour le choix de l’offre la plus intéressante d’un point de vue économique, les offres régulières des soumissionnaires sélectionnés seront confrontées à une série de critères d’attribution. Ces critères seront pondérés afin d’obtenir un classement final. 4.3.1. Liste des critères d’attribution

1. Le prix (/50) 2. Le délai de développement (/20) 3. La qualité technique (/30)

IMPORTANT Sous peine d’exclusion, le soumissionnaire doit obt enir au moins 60% pour le critère 3 « La qualité technique ».

4.3.2. Méthode de détermination de l’offre la plus intéressante L’évaluation des critères d’attribution se fera comme suit:


1. Le prix (/50) Pour ce qui concerne le critère d’attribution « prix », les offres seront évaluées sur la base des prix renseignés par les soumissionnaires dans leur inventaire des prix (annexe 2) appliqués à la configuration d’évaluation fixée préalablement par le pouvoir adjudicateur. Les points attribués pour le critère « prix » seront calculés sur la base de la formule suivante: Po = Pi + 84 M + (300XA) Où :

Po = le prix total TVAC de l’offre régulière analysée Pi : le prix global forfaitaire TVAC pour les développements pour les tranches 1, 2 et 3

M = le prix forfaitaire TVAC pour un mois de maintenance (concerne tant le système actuel que les produits à livrer aux tranches 1,2 et 3) préventive, corrective (bug fixing) et évolutive

A = le prix forfaitaire TVAC pour UN jour/hommes d’assistance complémentaire

P = 50 X Pm

Po

Où : P est le nombre de points attribués au soumissionnaire pour le critère « Prix »; Pm est le prix total TVAC le plus bas proposé par un soumissionnaire dans une offre régulière; Po est le prix total TVAC proposé par le soumissionnaire dont l’offre est évaluée.

Le nombre de points obtenus est arrondi à la deuxième décimale. 2. Le délai de développement (/20) Pour la tranche 1 : Par délai de développement, on entend le délai maximum entre la fin de la réunion de kick-off et la remise du programme totalement développé et prêt à fonctionner. Le soumissionnaire renseigne dans son formulaire d’offre le délai de développement exprimé en mois. Pour ce critère, les points seront attribués de la manière suivante: - Si Di = 24 mois, alors Dn = 20; - Si Di est = à 25 mois, alors Dn = 15; - Si Di est = à 26 mois, alors Dn = 10 ; - Si Di est = à 27 mois, alors Dn = 5; - Si Di est > 27 mois, alors Dn = 0.


Où Di = le délai de développement exprimé en mois. Ce délai commence à courir le lendemain de la réunion de kick-off. Dn = le nombre de points obtenus par le soumissionnaire pour ce critère d’attribution. Pour les tranches 2 et 3 : Par délai de développement, on entend le délai maximum entre la fin de la réunion de kick-off et la remise du programme totalement développé et prêt à fonctionner. Le soumissionnaire renseigne dans son formulaire d’offre le délai de développement exprimé en mois. Pour ce critère, les points seront attribués de la manière suivante: - Si Di = 36 mois, alors Dn = 20; - Si Di est = à 37 mois, alors Dn = 15; - Si Di est = à 38 mois, alors Dn = 10 ; - Si Di est = à 39 mois, alors Dn = 5; - Si Di est > 39 mois, alors Dn = 0. Où Di = le délai de développement exprimé en mois. Ce délai commence à courir le lendemain de la réunion de kick-off. Dn = le nombre de points obtenus par le soumissionnaire pour ce critère d’attribution. Le total des points attribués pour la tranche 1 et les tranches 2 et 3 sera ramené à 20. 3. Qualité technique (/30) Une commission d’évaluation composée de fonctionnaires et/ou d’agents du S.P.F. FINANCES procèdera à l’évaluation de la qualité du logiciel sur la base des offres introduites. Dans son offre, le soumissionnaire veillera à fournir tous les détails nécessaires permettant d’évaluer la qualité de chacune des tranches sur base de la description des besoins décrite dans la partie E « Prescriptions techniques ». Pour la tranche 1, la qualité de l’offre sera évaluée sur base : - du caractère générique et extensible de la solution proposée pour tous les droits ; - des types d’intefaces proposées pour l’intake générique (Web services, changement

fichier, web applications, exclusivement ou ensemble) ; - des taux de dépendance entre le module « Intake générique » et le module

« Accounting ». Pour la tranche 2, la qualité de l’offre sera évaluée sur base : - du caractère générique et extensible de la solution proposée pour tous les droits ;


- de la capacité de traiter des gros volumes (imputations des paiements, génération de gros fichiers de remboursements,…) ;

- du type d’interfaçage avec les services internes comme Filenet, Fedopress,… (synchrone ou asynchrone).

Pour la tranche 3, la qualité de l’offre sera évaluée sur base : - du caractère générique et extensible de la solution proposée pour toutes les actions de

recouvrement ; - du nombre d’interfaces avec les applications/services existants ou avec le monde

extérieur permettant de faire du recouvrement (DIV, SAFS, FCA, eNotariat,…). - la possibilité donnée à l’utilisateur de faire des actions de recouvrement ponctuellement

et manuellement hors ou en interaction avec le flux automatique. Le score obtenu n’a aucun lien avec l’évaluation relative à la satisfaction des exigences minimales. Une offre jugée conforme au cahier des charges obtient au moins 0 point. Un score supérieur à 0 est accordé si l’offre propose une plus-value par rapport à la simple conformité au cahier des charges.

Evaluation des plus-values par rapport à la conformité au cahier des charges

Score correspondant

Aucune plus-value 0 Plus-value moyenne 5 Grande plus-value 20 Très grande plus-value 30

Le total des points attribués pour les tranches 1, 2 et 3 sera ramené à 30.

4.3.3. Cote finale La cote finale est attribuée à chaque offre en additionnant les points obtenus pour les 3 critères susmentionnés. IMPORTANT Le pouvoir adjudicateur se réserve le droit de faire appel pour l’analyse des offres à un ou plusieurs expert(s) externe(s) au SPF Finances. L’offre qui sera choisie sera celle qui obtiendra la cotation finale la plus élevée.


D. EXECUTION

1. Fonctionnaire dirigeant. 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 : le prestataire de services 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 :

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

+= 2.0*8,0*

00 S

SPP


Les prix des services commandés en supplément peuvent être revus. La révision suit les règles ci-dessus. Le pouvoir adjudicateur se réserve le droit de revoir les prix en cas de baisse des coûts salariaux. 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. Le prestataire de services assume la pleine responsabilité des fautes et des omissions constatées dans les services fournis, spécialement dans les études, les calculs, les plans ou toute autre pièce qu’il fournit dans le cadre de l’exécution du marché. En outre, le prestataire de services garantit le pouvoir adjudicateur contre toute action en dommages et intérêts intentée par des tiers en raison de son retard ou de sa défaillance. Le prestataire de services garantit que tous les services qui devront être exécutés dans le cadre du contrat seront exécutés conformément aux meilleures normes professionnelles, par un personnel suffisamment formé et compétent, en respectant les délais prévus. L’adjudicataire a donc une obligation de résultat. Sur la base de l’article 1384 du Code civil, le prestataire de services est en tous cas responsable de tout fait ayant un rapport avec les activités exercées pour le compte du SPF Finances commis par des membres de son personnel.

4. Garantie Dans cette section, le terme « élément » fait référence à toute méthodologie, équipement ou logiciel et, par extension, à tout ce qui relève de la période de garantie et/ou de maintenance et qui a été développé/livré par l’adjudicataire et fait partie du présent marché. Après chaque réception provisoire partielle, la période de garantie d’un élément débute ; elle se termine 1 année après la dernière réception provisoire globale pour chacune des tranches. Si des éléments sont défectueux, si les fonctions et/ou les prestations et/ou le respect du SLA (Service Level Agreement – accord sur le niveau des services), prescrits dans le cahier des charges ou annoncés dans l’offre de l’adjudicataire, ne sont pas satisfaisants ou ne le sont qu’en partie, dans la mesure où les défauts ne sont pas la conséquence d’une utilisation anormale des éléments, l’adjudicataire s'engage à effectuer toutes les réparations ou corrections nécessaires à ses frais ou à remplacer, le cas échéant, les éléments défectueux dans les délais indiqués dans les spécifications du SLA. Pendant les périodes de garantie, les sanctions relatives au SLA s’appliquent. La garantie couvre notamment :

• la réparation ou la correction des défauts de fonctionnement ou les non-conformités d’un logiciel ;

• la correction des paramètres ; • la durée des travaux prestés ; • les déplacements du personnel de l’adjudicataire.


Le soumissionnaire doit veiller à mettre à jour les éléments pendant la période de garantie. Ces mises à jour se rapportent tant à d’éventuelles ‘corrections’ qu’aux évolutions des éléments installés.

5. Réception des services prestés.

5.1. Réceptions provisoires partielles Pour la partie développement et par tranche, un procès-verbal de la réception provisoire partielle sera établi à l’issue de chaque « release ». Par release, il faut entendre la phase de réalisation d’un ensemble de fonctionnalités selon le plan de releases défini par le soumissionnaire dans son offre et validé par le SPF FINANCES lors du kick-off. Dans le cas où la réception provisoire partielle d’un nouvel élément a un impact sur une partie qui a été réceptionnée antérieurement, les changements doivent être apportés à l’élément réceptionné auparavant avant que le SPF Finances marque son accord sur la réception provisoire partielle de cette nouvelle partie. Après la dernière réception provisoire partielle, suit la réception provisoire partielle globale pour la tranche concernée.

5.2. Réception définitive La réception définitive est déclarée à la demande du fournisseur à l’issue de la durée du marché. 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.

6. Cautionnement

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 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 sur base du montant annuel en raison du caractère pluriannuel du marché, de la possibilité de mettre fin à celui-ci chaque année, de la nature récurrente des prestations et du surcoût anormal que devrait supporter l’adjudicataire, si le montant à prendre en considération était le montant global du marché calculé pour la durée de sept ans initialement prévue. Pour chacune des tranches, le cautionnement est fixé à 5% du montant initial, hors TVA, relatif à la partie développement ainsi qu’à 5% du montant correspondant à une année de maintenance (concerne tant le système actuel que les produits à livrer) (corrective (bug fixing), préventive et évolutive). Le montant ainsi obtenu est arrondi à la dizaine d’euro supérieure.

6.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 du caissier de

l’Etat au siège de la Banque nationale à Bruxelles ou dans l’une de ses agences en province, pour compte de la Caisse des Dépôts et Consignations, ou d’un organisme public remplissant une fonction similaire

3° lorsqu’il s’agit d’un cautionnement collectif, par le dépôt par une société exerçant

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

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

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

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

organisme public remplissant une fonction similaire

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

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

l’entreprise d’assurances accordant une garantie. Ces documents, signés par le déposant, indiquent au profit de qui le cautionnement est constitué, son affectation précise par l’indication sommaire de l’objet du marché et de la référence des documents du marché, ainsi que le nom, le prénom et l’adresse complète de l’adjudicataire et éventuellement, du tiers qui a effectué le dépôt pour 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 :

6.2. Libération du cautionnement

Pour cette partie, il est dérogé à l’article 33 de l’arrêté royal du 14 janvier 2013 établissant les règles générales d’exécution des marchés publics et concessions de travaux publics. Pour chacune des tranches, la partie de cautionnement concernant :

- le développement sera libérée après la réception provisoire globale ; - la maintenance sera libérée après réception définitive du marché exécuté 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.

7. Exécution des services.

7.1. Lieu où les services doivent être exécutés.

L'exécution du marché se déroulera principalement au sein du complexe North Galaxy situé au 33 Boulevard Roi Albert II à 1030 Bruxelles. Si, au cours de certaines périodes, certaines prestations devaient s’effectuer en d’autres lieux, aucun frais de déplacement ne sera alloué à l’adjudicataire. 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 agents des Finances. Par “heures de bureau normales”, nous entendons les jours ouvrés, du lundi au vendredi, de 8h00 à 17h00. Le 2 novembre, le 15 novembre et la période entre Noël en Nouvel An sont considérés comme jours fériés par le SPF Finances, ainsi que le premier jour ouvrable de l’année. Des « ponts » obligatoires sont également prévus ; ils seront communiqués chaque année.

7.2. Conditions de l’exécution. 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. L’équipement (les logiciels) sera livré et installé par l’adjudicataire suivant un calendrier détaillé, mis au point de commun accord après la notification de l’attribution du marché. Les

Service Public Fédéral FINANCES Service d’Encadrement Budget et Contrôle de la Gestion Gestionnaire des engagements divisions et services de

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

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


locaux d’installation seront préparés par le SPF Finances suivant les prescriptions énoncées dans l’offre de l’adjudicataire

7.2.1. Livraisons Spécification techniques Les services doivent correspondre en tous points avec les plans, documents et domaines applicables à ce marché. Même en cas de défaut de spécification technique contractuelle, les livraisons et services doivent satisfaire à toutes les exigences et règles de bonne exécution.

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

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

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

Le chef de projet doit être en outre capable de : • communiquer oralement tant en français qu’en néerlandais.

Le service d’assistance et de support technique doit en outre pouvoir :

• communiquer avec aisance dans les deux langues. Le personnel de l’adjudicataire devra satisfaire à toutes les dispositions légales en vigueur en Belgique en matière d'immigration et de permis de travail. L’adjudicataire garantira le SPF Finances contre tout dommage généralement quelconque que le SPF Finances pourrait subir du fait du non-respect par l’adjudicataire ou les membres de son personnel des dispositions légales en question. L’adjudicataire doit disposer de suffisamment de personnel possédant les connaissances nécessaires et adaptées à l’exécution des tâches. Le personnel concerné doit également disposer d'une connaissance suffisante des outils utilisés dans le cadre du projet. Les adjudicataires doivent être capables de répondre immédiatement aux besoins résultant de l’attribution du marché. L’équipe de projet mise à disposition par l’adjudicataire doit être suffisante afin de mener à bien les missions qui lui sont confiées. Le personnel affecté à l'exécution du marché doit être le même que celui proposé dans l'offre. A défaut, le personnel mis à disposition pour l'exécution sera de niveau et d’expérience équivalents. Le SPF Finances devra marquer son accord sur la composition de l'équipe proposée pour le projet.

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


L'adjudicataire garantit pour toute la durée du marché, la stabilité des personnes affectées à l'exécution du présent marché. En cours d'exécution, l'adjudicataire n'apportera aucun changement dans la composition de l'équipe de projet sans l'autorisation préalable du SPF Finances. Le SPF Finances pourra réclamer le remplacement immédiat d'une ou plusieurs personnes de l'équipe de projet de l'adjudicataire si elle juge que leurs qualifications ou leurs prestations entravent la bonne exécution du marché. Le changement devra intervenir dans les 10 jours ouvrables de la demande du SPF Finances, et ce sans frais à dater de la notification de l’incident au soumissionnaire. Les soumissionnaires doivent joindre à leur offre, le curriculum vitae (obligatoire selon le modèle de « curriculum vitae » repris à l’annexe 5) de toutes les personnes amenées à réaliser le marché. L’offre devra contenir une proposition claire concernant la composition réelle de l’équipe de projet et le type de profils qui participeront à la réalisation du marché. Un certain nombre de personnes pourront être proposées par profil, mais le soumissionnaire devra indiquer combien et quels membres du personnel feront partie de l’équipe de projet réelle. La liste des membres du personnel proposés (effectifs et suppléants éventuels) sera considérée comme une liste exhaustive comprenant tous les membres du personnel susceptibles de faire partie de l’équipe de projet. Toute modification apportée à cette liste devra faire l’objet d’une approbation par le pouvoir adjudicateur.

7.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 et livraisons 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 à leur responsabilité lorsque les travaux 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. Frais de réception Tous les frais se rapportant à la livraison et à la (aux) réception(s) technique(s) et/ou définitive(s) sont à charge de l’adjudicataire.

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

7.5. Matériel et équipement de l’administration

7.4.1. Moyens techniques L’adjudicataire mettra à disposition de son personnel tout le matériel nécessaire à l’exécution de sa mission (ordinateur portable, etc.). On applique le principe que le SPF Finances mettra simultanément la disposition des membres du personnel au cours de leur mission, au maximum deux bureaux de type "shared desk", sans armoires. Le personnel de l’adjudicataire dispose d’un accès limité au réseau du SPF Finances, ainsi que d’une adresse e-mail. Le SPF Finances ne dispose pas d’emplacements de parking pour le personnel de l’adjudicataire. Le SPF Finances n'effectuera aucune adaptation aux postes de travail des membres du personnel de l'adjudicataire afin de les faire mieux fonctionner au sein de l'infrastructure du SPF Finances. L'adjudicataire ne peut en aucun cas modifier, perturber ou surcharger l'infrastructure du SPF Finances par l'ajout de postes de travail pour son personnel dans cette infrastructure, sauf pour ce qui est directement associé au développement de l'application concernée. L'adjudicataire est intégralement responsable de la protection des postes de travail concernés contre les virus et de la gestion de ces postes. Il utilisera de manière prioritaire les outils mis à sa disposition par le SPF Finances. Au cas où d'autres logiciels devraient être utilisés dans le cadre du projet, leur utilisation se déroulera, après acceptation par le comité de pilotage, sous la responsabilité de l'adjudicataire et le coût de cette utilisation sera compris dans le prix des services.


Le personnel de l’adjudicataire devra suivre les procédures internes et les règlements relatifs à l’utilisation des moyens mis à sa disposition et à leur accès, et ne peut exiger aucun ajout ou modification à l’environnement de travail du pouvoir adjudicateur. Si des manquements dans le soutien logistique entraînent des perturbations de service, il devra être fait appel aux moyens d’arbitrage décrit dans le point « Moyens d’actions de l’administration – Litiges » avant de faire appel au droit.

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

• la définition du contenu du projet ; • la participation au choix de solutions : architecture, etc. ; • la validation des documents de réalisation : dossiers de spécification, dossiers de

réalisation, dossiers d’acceptation, dossier de tests, manuels d’utilisation, manuels de maintenance, etc. ;

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

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

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

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

IMPORTANT Sous-traitance 1. Conformément à l’article 42, §2 et 3 de la Loi du 15 juin 2006 relative aux marchés publics

et à certains marchés de travaux, de fourniture et de services, l'adjudicataire d'un marché public de services est tenu :

1° de respecter et de faire respecter par toute personne agissant en qualité de sous-traitant

à quelque stade que ce soit et par toute personne mettant du personnel à disposition sur le chantier, toutes dispositions légales, réglementaires ou conventionnelles aussi bien en matière de sécurité et d'hygiène qu'en ce qui concerne les conditions générales de travail, que celles-ci résultent de la loi ou d'accords paritaires sur le plan national, régional ou local;

2° de respecter et de faire respecter par ses propres sous-traitants et par toutes personnes

lui procurant du personnel, toutes dispositions légales, réglementaires ou conventionnelles en matière fiscale et de sécurité sociale.


2. Conformément aux articles 12 et 13 de l’arrêté royal du 14 janvier 2013, 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 aux articles 61 à 66 de l'arrêté royal du 15 juillet 2011. Il est en outre interdit à l'adjudicataire de faire participer les personnes concernées à la conduite ou à la surveillance de tout ou partie du marché. Toute violation de ces interdictions peut donner lieu à l'application de mesures d'office.

De plus les sous-traitants ne peuvent se trouver dans une des situations d’exclusion

prévues au point 4.1.1. droit d’accès du volet « C. Attribution » du cahier spécial des charges et ils sont tenus de satisfaire en proportion de leur participation au marché aux critères concernant la sélection qualitative imposés aux soumissionnaires au point 4.1.2. sélection qualitative du volet « C. Attribution » du cahier spécial des charges.

3. L'adjudicataire est tenu de recourir lors de l'exécution du marché aux sous-traitants

annoncés dans l'offre. En cas d'impossibilité dûment justifiée de se conformer à cette obligation, l'adjudicataire doit en informer immédiatement le pouvoir adjudicateur et lui demander l'autorisation de recourir à d'autres sous-traitants.

4. 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. Celui-ci ne se reconnaît aucun lien contractuel avec ces tiers.

7.6. Délais d’exécution Chacune des trois tranches doivent être réalisées en mode itératif avec des délais variables ne pouvant excéder :

• 27 mois pour la tranche « Intake générique » ; • 39 mois pour la tranche « Amélioration Accounting et interface Fedcom GL » ; • 39 mois pour la tranche « Module générique d’actions de recouvrement ».

L’adjudicataire est tenu d’assurer pour chacune des tranches ainsi que pour le système actuel la maintenance corrective (bug fixing) et préventive ainsi que la maintenance évolutive à partir de la réception provisoire du développement.

7.7. Contrôle des présences et prestations Le SPF Finances a le droit de maintenir une surveillance permanente sur les livraisons et les services qui sont exécutés par l’équipe impliquée dans l’exécution du marché. L’équipe d’exécution doit fournir aux représentants du SPF Finances tous les renseignements et facilités afin de remplir cette tâche. Les plans, spécifications, dossiers, etc. sont établis, dans le cadre de ce marché, par le personnel de l’adjudicataire. Ils doivent avoir été approuvés par le SPF Finances avant exécution. Le SPF Finances dispose d’un délai de 20 jours calendrier afin d’approuver ces documents ou de formuler des remarques. En cas de remarques, les documents concernés doivent être corrigés avant l'exécution et sans que ces corrections n'aient comme conséquence une révision des délais d'exécution planifiés, à moins que les remarques ne proviennent de nouvelles exigences de la part du SPF Finances. Tout dépassement du terme planifié pour l’acceptation d’un document mène, à la demande de l’adjudicataire concerné, à un prolongement du délai d’exécution. Le fait qu'un retard


puisse être imputé au SPF Finances ne dégage pas l'adjudicataire de son obligation de veiller à en réduire les conséquences. L’adjudicataire ne peut pas faire appel au fait que cette surveillance a été exécutée, dans le but de se soustraire à sa responsabilité au cas où les fournitures ou les prestations seraient refusées pour cause de manquements de quelque nature que ce soit et que dès lors des délais d’exécution prolongés en découleraient.

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

7.8. Contrôle et encadrement du marché Dans les 30 jours suivant la livraison par l’adjudicataire, le SPF Finances commencera un contrôle complet, appelé tests d’acceptance, des éléments constitutifs de chaque release définie dans le calendrier de la réalisation du projet. 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 modules 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 livraisons et 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… - La fourniture de la documentation.

Les contrôles sont considérés comme fructueux lorsque les modules passent les tests avec succès dans les délais impartis. Les tests et leur calendrier sont définis de commun accord. 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 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 logiciels 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 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’un module détectent des anomalies de fonctionnement ou des éléments non-conformes à l’analyse fonctionnelle, les modifications devront y être apportées au frais de l’adjudicataire et retestées par les utilisateurs. Dans le cas où ces modifications ont un impact sur un module 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 ce module.

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.

7.8.1. Décision Go/No Go

A la fin des tests d’acceptation, le SPF Finances insère une décision explicite de « Go/No Go » avant le chargement de l’application dans l’environnement de production. Une décision de « Go » initiera la phase du projet : chargement dans l’environnement de production, Go-live, support au démarrage. Une décision « No Go » par non-acceptation de la livraison suite aux tests d’application impliquera l’obligation pour l’adjudicataire de revoir l’application afin de répondre aux tests d’acceptation. A l’issue de deux décisions « No Go », le pouvoir adjudicateur pourra mettre fin de facto aux prestations dans le cadre de projet en n'entraînant aucune forme d'indemnisation au bénéfice de l’adjudicataire. Toutefois le pouvoir adjudicateur le cas échéant se réserve dans ce cas à l’application de mesure d’office quelle prévu dans l’article 47 de l’AR du 14 janvier 2013. Une décision « No Go », pour des raisons d’opportunité, de l’abandon unilatéral du projet par le SPF Finances fera l’objet d’une réception provisoire partielle. Cette réception provisoire partielle entrainera une facturation partielle des prestations selon les modalités administratives reprises au point 9 « Facturation et paiement des services » du présent cahier des charges.

7.8.2. Aspects personnels

Sauf cas de force majeure, l'adjudicataire s’engage à ce que les personnes, dont le CV sera repris dans l’offre (annexe 5 du présent cahier spécial des charges), soient effectivement disponibles pour participer au projet. Tout changement au sein de l’équipe de projet (l’ajout, le retrait ou le remplacement) doit être soumis à l’approbation du comité de pilotage.

7.9. Accès aux locaux et sécurité

7.9.1. Accès aux locaux

L’Administration peut interdire l’accès des locaux au personnel de l’entreprise dont la conduite n’offre pas des garanties suffisantes. IMPORTANT


Le prestataire doit être en mesure de justifier à tout moment que son personnel est en règle avec la réglementation belge du Travail. A cette fin, le prestataire fournira au fonctionnaire dirigeant ou à son délégué: - le contrat de travail, - le certificat de bonne vie et mœurs, - la carte d’identité Le prestataire fournira au fonctionnaire dirigeant ou à son délégué au plus tard le premier jour de l’exécution du contrat une liste complète du personnel affecté à l’exécution du contrat. Cette liste sera systématiquement mise à jour lors de tout changement dans la composition du personnel. Cette liste doit contenir au moins les renseignements individuels suivants :

- le nom - le prénom - la date de naissance - la fonction - les prestations réelles ou assimilées, effectuées dans le cadre du présent marché - le type de contrat d’emploi liant le personnel à l’entrepreneur, - le nom de la société à laquelle appartient chaque travailleur.

7.9.2. Sécurité En matière de contrôle d'accès, l'adjudicataire devra se conformer aux normes en vigueur dans le bâtiment. Pour des raisons évidentes de sécurité, ces normes ne seront communiquées qu'au moment de l'attribution du marché et ce, uniquement à l'adjudicataire.

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

• les normes techniques pour logiciels ; • la méthode de gestion de projet (PMFin, une méthodologie de projet unique au sein

du SPF Finances qui est basée sur la méthode internationalement reconnue Prince2);

• la tenue de la documentation ; • les règles de programmation (création, structures des codes, commentaires,

conventions en matière de dénomination, standards de développement conformément aux fondements ICT, y compris les Standards ouverts, etc.);

• les règles de gestion définies par les services de gestion des environnements d'exploitation ;

• les procédures pour les garanties de base Toutes les normes utilisées par le SPF Finances figurent dans un document explicatif, disponible sur http://finances.belgium.be/fr/sur_le_spf/historique_modernisation/ict/ict_fundamenten/ (sous « Fondements ICT du SPF Finances ») et http://financien.belgium.be/nl/over_de_fod/geschiedenis_modernisering/ict/ict_fundamenten/ (sous “ICT Fundamenten van de FOD Financiën”). Toute référence à quelque norme ou méthodologie que ce soit dans le présent cahier des charges dépend de la description exacte dans le document officiel présent sur ce site.


Seul le comité tactique est compétent au sein du SPF Finances pour modifier ou ajouter des normes et méthodologies. Si l’adjudicataire a besoin de l’approbation d’une nouvelle norme, il devra en introduire la demande auprès du comité tactique et entièrement se soumettre à sa décision.

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

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

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

droit syndical, 1948)

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

4. l’interdiction de toute discrimination en matière de travail et de rémunération (conventions

n° 100 sur l’égalité de rémunération, 1951 et n° 111 concernant la discrimination (emploi et profession), 1958)


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

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

8. Propriété des softs développés 8.1. Propriété intellectuelle Les droits de propriété intellectuelle et industrielle relatifs notamment aux dessins, modèles, œuvres et/ou documents littéraires (enregistrés de manière durable ou en langage de machine), rapports, logiciels et bases de données, ainsi que les méthodes, le savoir-faire, les concepts et autres développements dont le SPF Finances est propriétaire ou détenteur de licence, continueront à appartenir au SPF Finances en tant que propriétaire ou détenteur de licence (ci-après dénommé la « propriété intellectuelle de l’Administration »). Tous les droits de propriété intellectuelle qui découlent d’une modification ou d’une adaptation de la propriété intellectuelle de l’Administration reviennent automatiquement au SPF Finances. Le prestataire de services s’engage à documenter de manière précise toute modification ou adaptation. Toute la documentation, sous quelque forme que ce soit, qui concerne ces modifications ou adaptations de la propriété intellectuelle de l’Administration, est considérée comme en faisant partie intégrante. Les droits de propriété intellectuelle et industrielle relatifs notamment aux dessins, modèles, œuvres et/ou documents littéraires (enregistrés de manière durable ou en langage de machine), rapports, logiciels et bases de données, ainsi que les méthodes, le savoir-faire, les concepts et autres développements, que le prestataire de services, et/ou le(s) sous-traitant(s) désigné(s) par le prestataire de services crée(nt) dans le cadre de l’exécution du marché sont ci-après dénommés « développements spécifiques ». Les droits de propriété intellectuelle et industrielle relatifs notamment aux dessins, modèles, œuvres et/ou documents littéraires (enregistrés de manière durable ou en langage de machine), rapports, logiciels et bases de données, ainsi que les méthodes, le savoir-faire, les concepts et autres développements, que le prestataire de services utilise dans le cadre de l’exécution du marché et qui sont la propriété du prestataire de services et/ou du (des) sous-traitant(s) désigné(s) par le prestataire de services, ou qui sont la propriété de tiers, sont ci-après dénommés « Autres composants ». Immédiatement après leur création, les « développements spécifiques » appartiennent au SPF Finances en propriété pleine et exclusive. Si nécessaire, afin de permettre au SPF Finances d’utiliser, d’adapter, de (faire) maintenir (par des tiers) et/ou de reproduire les développements spécifiques, le prestataire de services s’engage et/ou se fait fort d’octroyer au SPF Finances, en ce qui concerne les autres composants utilisés pendant et après l’exécution du marché, une licence non exclusive, transmissible, universelle, irrévocable et susceptible de sous-licence, pour la durée de la protection légale des droits de propriété intellectuelle en vue de l’utilisation, de la modification et de la reproduction des autres composants.


Le prestataire de services renonce à utiliser les développements spécifiques de quelque manière que ce soit à d’autres fins que l’exécution du présent marché sans l’accord préalable, écrit et exprès du SPF Finances ; il veillera à ce que ses employés, agents et sous-traitants soient également liés par cette obligation. Le prestataire de services s’engage à mettre à la disposition du SPF Finances et à maintenir à jour en permanence pour lui, sans frais supplémentaires, la documentation (y compris toutes les spécifications techniques pertinentes) et, dans le cas de logiciels, aussi le code source des développements spécifiques sous forme d’un environnement de développement et de production utilisable. Les indemnités que le SPF Finances paie pour la fourniture des services comprennent les indemnités pour le transfert ou le droit d’utilisation de ces droits de propriété intellectuelle. 8.2. Garanties Le prestataire de services s’abstiendra d’exiger, n’importe où dans le monde, le droit de propriété intellectuelle des développements spécifiques ou de prétendre y avoir droit de quelle que manière que ce soit, de soumettre une demande de brevet ou de toute protection similaire. Il veillera à ce que ses travailleurs, agents et sous-traitants soient aussi liés par cette obligation. Le prestataire de services garantit qu’il possède tous les droits et toutes les autorisations nécessaires pour transférer les droits de propriété intellectuelle décrits ci-dessus ou d’en permettre une licence d’utilisation. Le prestataire de services s’engage à fournir au SPF Finances toute l’assistance requise, à remplir les formalités qui s’imposent et à entreprendre les démarches nécessaires afin d’assurer et de prouver la validité de la cession des droits précités. Le prestataire de services s’engage à et se fait fort de faire respecter cette obligation par ses employés, ses préposés et d’éventuels sous-traitants. Le prestataire de services informera le SPF Finances de tous les autres composants utilisés lors de la fourniture des services. Le prestataire de services garantit que les droits conférés concernant les développements spécifiques et les autres composants ne porteront pas atteinte aux droits intellectuels et autres d’un tiers. Si une action est intentée par un tiers en raison d’une prétendue violation du droit de propriété intellectuelle ou autre de ce tiers par n’importe quelle personne à la suite de la fourniture ou de l’utilisation des services, le prestataire de services fournira, à la première requête du SPF Finances, toutes les informations possibles, ainsi qu’une aide et une assistance (notamment l’intervention volontaire dans une procédure à la première requête du SPF Finances) pour permettre au SPF Finances d’organiser sa défense de manière effective et efficace. Le prestataire de services supportera tous les frais découlant d’une telle accusation (frais d’avocat y compris). Si le SPF Finances doit, à la suite d’une telle action, payer une amende et/ou des dommages et intérêts, le prestataire de services prendra ce paiement à sa charge. Si, à la suite d’une telle action, les services ne peuvent plus être fournis avec succès ou si un service fourni ne peut plus continuer à exister avec succès, le prestataire de services, après concertation avec le SPF Finances et à ses frais, se chargera de les rétablir.


Sans porter préjudice à l’obligation du prestataire de services de garder secrètes les informations sur le présent marché et les informations confidentielles, le prestataire de services a le droit de réutiliser le savoir-faire ou l’expérience qu’il a acquis(e) dans le cadre de l’exécution du marché à d’autres fins que l’exécution du marché.

9. Facturation et paiement des services. Par chacune des tranches, le paiement se fait, après chaque réception provisoire partielle pour la partie développement sur production de factures régulièrement et justement établies au nom de :

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

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

Le procès-verbal de réception provisoire partielle sera joint à la facture à laquelle il se rapporte. Pour chacune des tranches, le paiement se fait, trimestriellement (au-delà de la période de garantie) à terme échu, pour la maintenance sur production de factures régulièrement et justement établies au nom de :

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] Les factures seront revêtues de la mention : « Le montant dû doit être versé sur le compte nº… au nom de…à… ». Le numéro du bon de commande (4500XXXXXX) et le cas échéant le numéro du contrat (5XXXXXXX) seront systématiquement indiqués sur chacune des factures. 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. IMPORTANT Le SPF FINANCES ne dépose pas de déclarations TVA p ériodiques. Par conséquent, conformément à la décision TVA n° E.T. 122.360 dd. 20.03.2012 de l’Administration générale de la Fiscalité, n’est pas d’application pour les travaux, fournitures ou services exécutés dans le cadre du présent marché, le régime cocontractant organisé à l’article 20 de l’Arrêté royal n° 1 du 29 décembre 1992 relatif aux mesures tendant à assurer le paiement de la taxe sur la valeur ajoutée.


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 technique et en notifier le résultat au prestataire de services. Le paiement du montant dû au prestataire de services doit intervenir dans le délai de paiement de trente jours à compter de l'échéance du délai de vérification. Lorsque les documents du marché ne prévoient pas une déclaration de créance séparée, la facture vaut déclaration de créance. La facture doit être libellée en EUROS.

10. Engagements particuliers pour le prestataire de services. Tous les résultats et rapports produits par l’adjudicataire pendant l'exécution de ce marché, constituent la propriété du pouvoir adjudicateur et ne peuvent être publiés ou communiqués à des tiers, sauf accord écrit préalable de la part du pouvoir adjudicateur. L'exécutant des services et ses collaborateurs sont tenus au secret professionnel quant aux informations qu'il aurait pu obtenir lors de l'exécution de ce marché. Ces informations ne pourront en aucun cas être communiquées à des tiers sans accord écrit de la part du pouvoir adjudicateur. L’adjudicataire est autorisé à mentionner le présent marché dans ses références. Tous les renseignements dont le personnel de l’adjudicataire sera amené à prendre connaissance dans le cadre de sa mission, tous les documents qui lui sont confiés et toutes les réunions auxquelles il participe sont considérés comme strictement confidentiels. Les informations 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. Toute information du SPF Finances restera la propriété du SPF Finances. Par la mise à disposition d’informations du SPF Finances, celui-ci ne concède à l’adjudicataire, ni explicitement ni implicitement, aucun droit à licence sur les droits de brevet, droits d’auteur ou autres droits intellectuels. L’adjudicataire s'engage à ne pas appliquer industriellement l'information du SPF Finances et à ne pas l'utiliser pour d'autres fins que l'exécution du présent marché ou d'une mission à lui confiée par le SPF Finances dans le cadre du présent marché. L’adjudicataire est responsable de tout dommage dont le SPF Finances serait victime du fait du non-respect par lui-même ou par les membres de son personnel d’obligations qui lui incombent en vertu du présent article.


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

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

13. 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 et les pénalités en raison de l’importance accordée par le Service Public Fédéral FINANCES à la mise en production dans les meilleurs délais.

13.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. Tout rapportage quotidien non effectué donne lieu à une pénalité forfaitaire de 100,00 EUR.

13.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 500,00 EUR sera appliquée de plein droit pour non-exécution. Les amendes s’appliquent de plein droit sans formalité ni avis quelconque.


13.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 du dédommagement dû par le prestataire est obtenu pour chaque item du SLA en multipliant le montant unitaire de dédommagement par l’écart à la norme exprimé en l’unité utilisée pour l’item considéré. 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. Le montant des amendes et pénalités, ainsi que le montant des dommages, débours ou dépenses résultant ou à résulter de l'application des mesures d'office, sont imputés en premier lieu sur les sommes qui sont dues à l'adjudicataire à quelque titre que ce soit (factures) et ensuite sur le cautionnement.


Page 46 sur 149

E. PRESCRIPTIONS TECHNIQUES

1. Introduction Le projet FIRST (Federal Integrated Recovery System and Tax-refund) vise à améliorer certaines fonctionnalités existantes et en développer des nouvelles afin d’assurer une perception juste des droits constatés et un recouvrement efficace des dettes impayées ainsi que le remboursement des sommes dues au bénéfice de personnes physiques ou morales. Concrètement, ce projet a pour objet de permettre à l’Administration Générale de Perception et de Recouvrement de :

• Prendre en charge toute demande interne ou externe, nationale ou internationale de perception et/ou de recouvrement de dette ainsi que le remboursement aux tiers via un module générique « Intake générique » qui représente Tranche 1 de ce marché.

• Améliorer le module Accounting pour y ajouter d’autres fonctionnalités, notamment,

implémentation de l’interfaces G/L avec le programme Fedcom et la fonctionnalité de remboursement aux ayants droits. Ce livrable représente la Tranche 2 de ce marché.

• Permettre d’initier des actions de recouvrement à partir d’un module générique se

basant sur des paramètres tels que la signalétique du débiteur, informations concernant la dette à recouvrer et des informations liées au paiement à recevoir. Cette fonctionnalité doit être orientée vers des applications et/ou organismes internes et/ou externes au SPF Finances. Elle doit permettre l’interaction avec ces applications et/ou organismes (modification, clôture, coûts et actes) dans les deux sens. Ce livrable représente la Tranche 3 de ce marché.

2. Remarques concernant la structure du volet techniqu e du cahier des charges

2.1 Définitions utilisées, abréviations et acronyme s.

Terme Définition

AA les amendes administratives AB de administratieve boetes BBV (belasting op de beursverrichtingen) zie TOB BCE Banque Carrefour des Entreprises

BDW

Toepassing voor het beheer van de Belasting op de Deelname van Werknemers in het kapitaal of in de winst van de vennootschappen

BLTS belasting op het langetermijnsparen

BNI/NP BNI/Ven de belasting van niet-inwoners - natuurlijke personen en vennootschappen

BTM Bank Transaction Manager BTW de belasting over de toegevoegde waarde BVB Belgische Vereniging van Banken en Beursvennootschappen BWD jaarlijkse belasting op de winstdeelnames BWP Belastingen op werknemersparticipatie ICPC Inning Comptabiliteit – Perception Comptabilité I&I Inning en Invordering IGB de met de inkomstenbelastingen gelijkgestelde belastingen: INR/PP INR/Soc l'impôt des non-résidents personnes physiques et sociétés IPM l'impôt des personnes morales


Page 47 sur 149

Terme Définition

IPP l'impôt des personnes physiques Isoc l'impôt des sociétés JBCC jaarlijkse belasting op de coördinatiecentra JBVC jaarlijkse belasting op de verzekeringscontracten KBO Kruispuntbank voor Ondernemingen NFI Niet-fiscale invordering OGM Overschrijving met Gestructureerde Mededeling OV Onroerende Voorheffing P&R Perception et Recouvrement. PB Penale Boetes Pr.M le précompte mobilier RAG Registre d’Attente Global RAC Registre d’Attente Client RN Registre National RNF Recouvrement Non Fiscal RPB de rechtspersonenbelasting RR Rijksregister RV de roerende voorheffing SC Saisies-cessions TA taxe d’affichage TACA taxe annuelle sur les contrats d’assurance TACC taxe annuelle sur les centres de coordination TAIR les taxes assimilées aux impôts sur les revenus: TAT les taxes assimilées au timbre TBT Tableaux de bord TBT Boordtabellen TBV (Taks op de beursverrichtingen) zie TOB TCA taxe compensatoire des accises TELT taxe sur l’épargne à long terme TLT taxe sur la livraison de titres au porteur TMC taxe de mise en circulation TOB taxe sur les opérations de bourse TOB Taks of de beursverrichtingen TPB taxe annuelle sur les participations bénéficiaires TPT taxe sur la participation des travailleurs TVA la taxe sur la valeur ajoutée VA les versements anticipés VA de voorafbetalingen VCS Virement à Communication Structurée VENB de vennootschapsbelasting ZGB de met de zegel gelijkgestelde belastingen:

3. Contexte de la mission

3.1 Contexte général D’un point de vue fonctionnel, le programme First est en production avec des modules métiers distincts, nommément, Amendes pénales, Saisies-cessions, Précompte mobilier, Accounting (module qui regroupe les fonctionnalités de perception et de comptabilité), Recovery (module qui regroupe les fonctionnalités de recouvrement). First peut être représenté par le schéma ci-dessous :


Page 48 sur 149

SERVICES UTILISES

CCFF

INTERFACES TECHNIQUES

DB FIRST

MODULES METIER

AP (Amendes Pénales)

PrM (Précompte Mobilier)

SC (Saisies Cessions)

ACCOUNTING

RECOVERY

IAM

ICPC

SEPA

FILENET

SITRAN

ANNUCOMP

FEDOPRESS

BTM

PROGRAMME INTEGRE FIRST

Via ces modules, le traitement de la dette se fait selon les étapes suivantes :

1. Enregistrement de la dette

Les déclarations (Pr.M) et jugements (amendes pénales) sont enregistrés dans le système via des écrans internes (précompte mobilier et amendes pénales) et externes (déclaration du précompte mobilier via une interface web). Les saisies et cessions sont également enregistrées manuellement. Pour les amendes policières, il est fait appel à des fichiers txt qui sont lus dans l’application. Les données enregistrées sont sauvegardées dans le système après validation et peuvent être consultées par la suite par l'utilisateur. Il est possible de scanner les éventuelles annexes.

2. Inscription dans la comptabilité

Le système inscrit après validation le droit positif ou négatif dans la comptabilité en tant que « document comptable » avec une série de lignes de détails qui permettent un traitement comptable ultérieur. Ce document comptable est inscrit dans un dossier comptable auquel un contribuable ou un groupe de contribuables est lié. Ce système est basé sur le système SITRAN, qui est une source unique au sein du SPF Finances pour consulter des données signalétiques de particuliers et sociétés. Pour les droits positifs, le système crée également un dossier « paiement à recevoir » et confère à la dette inscrite une référence de dette qui sera utilisée comme communication structurée dans les paiements.

3. Traitement des paiements

Les paiements fournis via des fichiers CODA par Bpost aboutissent sur une plateforme appelée BTM (Bank Transaction Manager). Après validation, les paiements sont lus dans le système où ils sont soit comptabilisés sur la dette et inscrits dans le registre d’attente du client (si le système retrouve suffisamment d’infos dans la communication), soit placés dans le registre général d’attente en cas d’informations insuffisantes. Toutes les données reçues peuvent également être consultées dans l’application en tant que « données financières du ou des comptes du bureau de recette ». Par cette voie (BTM), les CODA pour les remboursements du registre d’attente sont également remis à Bpost pour exécution.


Page 49 sur 149

4. Bilan des dettes et avoirs

Un écran qui offre un aperçu de l’ensemble des dettes et des avoirs (ainsi que des paiements inutilisés) pour un contribuable déterminé a été développé. Cet aperçu contient une vue globale de l’ensemble des dettes et avoirs qui se trouvent dans le système tous bureaux confondus. Cet écran affiche également les saisies et les cessions, ainsi que les dettes dont la société peut être tenue pour responsable. Cet écran permet en outre de consulter les dettes et les paiements en détail et contient le lien vers les écrans « registre d’attente » pour traiter les paiements indéterminés.

5. Traitement des paiements indéterminés (registres d’attente)

Un paiement que le système ne peut automatiquement attribuer à une dette est inscrit dans un registre dit d’attente. Le système actuel contient 2 types de registres d’attente. Si le client est connu, on lie le paiement indéterminé à ce client de sorte que ce paiement soit visible pour l’utilisateur dans le bilan des dettes et avoirs. Il s’agit du « registre d’attente client ». Si le client n’est pas connu, le système inscrit ce paiement dans le « registre général d’attente ». Les deux registres d’attente demandent une intervention manuelle de l’utilisateur final qui effectue les recherches nécessaires ou demande des informations complémentaires via des documents standard liés au système.

6. Workflow

Via une série de traitements de batchs, le système recherche les dettes « échues » et impayées, adapte le statut et envoie des sommations automatiques via un système centralisé « FEDOPRESS ». En ce qui concerne les dettes pour lesquelles il n’existe pas encore de titre de recouvrement, ce workflow prévoit l’« enrôlement de droits » (par exemple pour le précompte mobilier) avec l’envoi de l’avertissement-extrait de rôle. Et ce, avec la cession des droits du centre de perception vers les bureaux de perception et de recouvrement locaux. Le workflow prévoit aussi la création de « ToDo » dans un système de gestion des tâches pour avertir l’utilisateur final de prendre l’initiative en matière de poursuites. Une autre application dans ces systèmes de workflow prévoit la création des listes 204 qui sont communiquées au SPF Justice pour demander l’emprisonnement subsidiaire en raison du non-paiement d’amendes pénales dans les délais imposés. Dans ce volet de l’application, il faudra aussi effectuer un nouveau choix pour reprendre les flux sortants (documents ou fichiers) dans la vision de l’« output générique ».

7. Fiche de solvabilité

Un certain nombre d’écrans a été développé pour avoir une vision globale de la solvabilité d’une personne physique ou société assujettie concernée. Le but ultime est de collecter ici des infos pertinentes tous bureaux confondus et de permettre les liens nécessaires avec des sources de données internes et externes afin de pouvoir faire les bons choix en matière de recouvrement. Cette fiche de solvabilité donne dès lors un aperçu des actions de recouvrement déjà réalisées (du bureau propre et d’autres bureaux de recette) et permet de lancer de nouvelles demandes de renseignements et actions de recouvrement.


Page 50 sur 149

Des données signalétiques détaillées peuvent également être présentées à l’utilisateur final.

8. Actions de recouvrement

Sous ce dénominateur, nous entendons les écrans qui permettent d’entreprendre toutes sortes d’actions de recouvrement (par exemple : les demandes d’accords de paiement, les missions confiées à l’huissier de justice, les saisies-arrêts simplifiées, etc.). Le développement de ce dernier exemple fait également partie du présent cahier des charges. Ces écrans doivent en outre permettre d'introduire les éventuels frais de poursuite faits et les actes concernés dans le système. Ici aussi, un flux automatique est prévu pour lire ces données en batch via les fichiers fournis. Ici aussi, le lien est établi avec le système prévu dans le présent cahier des charges de l’« output générique ».

9. Traitement des documents

Dans les diverses applications, la possibilité existe de joindre des annexes en format pdf. Celles-ci sont scannées et sauvegardées en filenet via un formulaire de code-barres ou directement en annexe. Les adaptations apportées au système actuel sont nécessaires pour sauvegarder temporairement les fichiers pdf en cas de problèmes d’accès au filenet, pour ne les charger que par la suite sans influence sur le système utilisateur. Pour l’envoi depuis l’application de documents à partir des différentes interfaces utilisateur (p. ex. des avis de paiement, des accords de paiement, des demandes de renseignements, des actions de recouvrement, etc.), on recourt directement à filenet via FEDOPRESS ou DOCTRAN dans l’application actuelle.

D’un point de vue applicatif, FIRST se présente comme suit : La figure suivante montre l’architecture high-level actuelle de l’application FIRST.

Fig. : Architecture high-level actuelle


Page 51 sur 149

La couche supérieure qui comprend les paquets Déclaration (Declaration), Perception (Collection) et Recouvrement (Recovery) utilise la couche Comptabilité (Accounting). Toutes les couches utilisent la couche Composantes de base (Base). L’accès à une couche sous-jacente se fait toujours au moyen d'un delegate, qui protège l'implémentation interne d'une couche. L’interface qui est proposée par le delegate doit rester aussi stable que possible, de sorte que les modifications à l’implémentation interne n’aient aucun impact sur les couches supérieures.

Fig. Architecture dans un paquet.

Dans un paquet, on peut distinguer plusieurs couches. La plupart des paquets se composent d’une ou plusieurs applications web (généralement connues sous le nom de « front-office ») et d’un module EJB business (généralement connu sous le nom de « back-office »). Dans une application web, le patron de conception modèle-vue-contrôleur est utilisé pour réaliser l’application. FIRST utilise le cadre Struts 2 pour réaliser ce patron. D’autres paquets FIRST qui utilisent un paquet le font toujours au moyen d’un delegate. Les applications web propres au paquet utilisent également un delegate, mais il s’agit ici généralement d’un delegate interne avec plus de fonctionnalités que l’interface publique. Dans le backend, on peut distinguer trois couches : la façade, à laquelle le delegate se connecte, la couche de service qui implémente la logique business et la couche de repository qui garantit la persistance. Pour la façade et la couche de service, FIRST utilise EJB3, et pour le repository, qui donne accès à la banque de données, FIRST utilise JPA. La figure suivante montre FIRST en relation avec d’autres composantes et applications externes.

Backend

Delegate

Façade

Service

Repository

Internal Delegate

Web Application

View

Controller Model Client Application


Page 52 sur 149


Page 53 sur 149

Pour la communication avec des systèmes externes, on utilise les technologies suivantes : • Service web : Plusieurs systèmes sont appelés via des services web. Cette

communication se fait via le trafic HTTP standard. FIRST utilise le cadre Axis pour l’intégration de ce mécanisme.

• EJB à distance : La communication interne entre les composantes de FIRST se fait au moyen d’EJB à distance (EJB 3).

• FTP : La communication avec des applications de mainframe passe par l’échange de fichiers sur un serveur FTP.

• JCR : La communication avec Filenet se fait au moyen du connecteur CCFF sur la base de la norme JCR.

• JMS : Les signaux Sitran sont reçus via un sujet JMS distribué.

• JDBC : La communication avec les banques de données se fait (au niveau le plus bas) via la norme JDBC. Dans FIRST, cette technologie est cependant utilisée de manière indirecte via JPA.

3.2 Contexte technique Le SPF Finances souhaite exploiter au maximum les licences acquises dans le passé, et ne pas payer deux fois pour des fonctionnalités comparables. Pour cette raison, le SPF Finances exige la conformité aux standards ICT déjà en usage depuis plusieurs années. Si des développements s'imposent, le soumissionnaire est prié de faire appel aux outils de développement standard existants. Il doit également s'en tenir aux méthodologies standard d'analyse, de support au développement et de gestion de projet (PMFin, la méthodologie de projet exclusive des Finances, basée sur la norme internationale Prince2). L'attention du soumissionnaire est par ailleurs att irée sur l'extrême importance attachée aux aspects IAM dans le contexte du marché . La description complète des standards et de FUP est disponible sur http://finances.belgium.be/fr/sur_le_spf/historique_modernisation/ict/ict_fundamenten/ Dans son offre, le soumissionnaire doit tenir compte des aspects techniques évoqués ici. Environnement matériel Tous les postes doivent être déployés sur des plates-formes qui seront mises à disposition par le SPF Finances, dans le respect des normes technologiques et des normes de développement définies par le SPF. Environnements de développement, de test, d’intégration et de production L'environnement de développement, l'environnement de test et l'environnement de production sont séparés, mais du point de vue technique, ils sont identiques, afin d'éviter les incompatibilités. Le développement, les intégrations, les tests (au sens large) et la production se déroulent donc sur des plates-formes identiques.


Page 54 sur 149

Performances Le système doit être disponible 24h sur 24, 7 jours sur 7 sans dégradation notable des performances. Exigences en matière d'intégration aux standards existants Dans le prolongement de l'introduction de cette partie, l'attention du soumissionnaire est encore une fois attirée sur les exigences en matière d'intégration aux standards existants. L'adjudicataire recevra après attribution du marché des informations complémentaires concernant ce qui suit (mais aussi concernant les autres normes le cas échéant). Poste client Le SPF Finances attache une importance particulière à l'indépendance des solutions par rapport aux postes clients. Le client doit donc veiller à ce que le raccordement, l'installation des composants et l'intégration au poste client exercent un impact minimum. A cette fin, il proposera obligatoirement une solution à base internet (web) . Le soumissionnaire doit également garantir cette indépendance en termes de logiciels, dans le cadre des standards ICT.

3.3 Contexte organisationnel. L'adjudicataire aura recours à PMFin , notre méthodologie et procédure de gestion des projets. PMFin est la méthodologie de projet unique et standard du SPF Finances. Elle repose sur la norme internationale Prince 2. La méthodologie est appuyée par l’outil de projet ProjectMaster. PID Le soumissionnaire est invité à soumettre un ‘Project initiation document ’ (PID) résumant les principales tâches qui doivent permettre de réaliser le projet. Ce document est pour nous un produit, une unité de travail au sein de notre propre PID. Le Project Initiation Document répond à des exigences minimales :

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

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

• Une WBS (‘work breakdown structure’) complète, un planning détaillé et réaliste du

projet avec ses jalons (GANTT) et la durée des différentes phases, sous-phases, activités et tâches, les moyens à mobiliser par phase (financiers, humains et autres). Ce planning sera tenu à jour

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

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

• Dépendances avec d'autres projets


Page 55 sur 149

• Plan de qualité

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

• Rapports et suivis de l'exécution (situation et progression) Après la réunion de coup d'envoi (‘kick-off’), le PID est finalisé, complété, enfin soumis à la validation du comité de pilotage, sponsor compris. Le soumissionnaire doit décrire sa structure et ses capacités en termes d'organisation des services professionnels : services offerts, portée géographique, niveaux et qualités du personnel. Le plan doit spécifier les tâches, leur durée et le nombre de personnes concernées, pour chaque (partie de) phase. Le plan doit aussi détailler la collaboration attendue de la part du personnel du SPF Finances. Après l'attribution du projet, le soumissionnaire élaborera un PID et un plan de projet complets et détaillés, qu'il présentera à la structure de gestion du projet du SPF Finances. L'approbation formelle du PID (planning de projet compris) ci-dessus par le comité de pilotage du projet est indispensable avant d'entamer la phase suivante. Il appartient au soumissionnaire de veiller à la tenue à jour du PID pendant toute la durée du projet. Toute modification du plan de projet doit être approuvée formellement par le comité de pilotage du projet. Le PID du soumissionnaire constituera pour notre propre PID une source d'information à propos des produits et des unités de travail dont le soumissionnaire aura la charge. Structures de gouvernance Tous les projets sont pilotés et gérés au sein des structures de gestion de projet du SPF Finances. Celles-ci sont représentées dans le schéma suivant : Chef de projet Chaque projet du SPF Finances est dirigé par un chef de projet interne (business). Celui-ci est nommé par le Sponsor, en concertation avec le comité de pilotage. Le soumissionnaire désignera son propre coordinateur de projet externe (chef de projet externe). Celui-ci et le chef de projet assument l'entière responsabilité de la bonne exécution du projet. Comité de pilotage Le comité de pilotage détient de larges compétences : il surveille le scope et les objectifs du projet, approuve le PID et le plan de projet détaillé ainsi que toutes leurs modifications, surveille l'avancement du projet, confirme l'acceptation des livrables (produits, livraisons partielles), évalue la qualité des produits partiels et finaux, et se prononce dans tous les litiges et/ou problèmes soulevés par le chef de projet. Il s'occupe de tous les aspects


Page 56 sur 149

contractuels, administratifs et techniques de l'exécution du marché (garantie, respect des SLA, qualité de l'exécution, etc). À cette fin, le chef de projet et le coordinateur de projet externe feront régulièrement rapport au comité de pilotage : situation, progression, risques et problèmes… Le comité de pilotage regroupe le sponsor, un profil senior du soumissionnaire, le chef de projet et le coordinateur de projet externe, ainsi qu'un représentant des utilisateurs. D'autres personnes peuvent être invitées, notamment le PMO opérationnel, le coordinateur de projet ICT, le responsable du ‘work package’ ou des personnes travaillant sur des aspects spécifiques du projet. Équipe de projet L'équipe de projet se compose de différents profils (internes et externes), dont chacun rapporte au responsable de son unité de travail (‘work package’) ou au chef de projet. Idéalement, les rôles suivants font partie de l'équipe : coordinateur de projet ICT (qui assure la liaison avec le service d'encadrement ICT), change coordinator (chargé de la gestion des changements) (P&O et Communication), coordinateur externe (contractant). PMO opérationnel Le PMO opérationnel peut aider le chef de projet à gérer et à maîtriser le projet, à appliquer la méthodologie PMFin, à utiliser l'outil de projet ProjectMaster, et à rédiger les rapports destinés au comité de pilotage ou au comité de direction. Réunion de coup d'envoi (‘kick-off’) Dans un délai maximum de 2 semaines suivant l'attribution du marché, l'adjudicataire et le SPF Finances doivent tenir une première réunion du comité de pilotage, appelée réunion de coup d'envoi (ou de kick-off). La réunion officialise le début du projet. Au cours de cette première rencontre, si cela s’impose au vu du cahier des charges, on examine le PID, on présente la composition des équipes et leurs compétences professionnelles, l'agenda des réunions de rapportage et des réunions du comité de pilotage, les modalités de gestion de projet, le planning de la réalisation du marché, on explique les principes du SLA, etc. Un document rédigé en deux exemplaires par l'adjudicataire et validé par le pouvoir adjudicateur entérine officiellement le début du projet dès que la réunion de coup d'envoi a eu lieu. Réunion du comité de pilotage Dès la réunion de coup d'envoi, le premier comité de pilotage fixe la date de ses réunions suivantes, en principe une fois par mois. Le sponsor ou le chef de projet peuvent toujours convoquer un comité de pilotage en dehors des dates fixées. Autres réunions Une fois par semaine, le chef de projet rencontre l'équipe du projet et rédige un rapport décrivant la situation du projet. Le rapport est distribué aux parties concernées importantes (à déterminer au coup d’envoi).


Page 57 sur 149

Qualité Le PID réserve une large place à la qualité. Dans le PID, le soumissionnaire explique comment il entend surveiller la qualité. Par ailleurs, le SPF Finances peut demander au QUAC (Quality Assurance Control Comité) un contrôle supplémentaire du respect des normes et des standards. Un contrôle de qualité par des tiers fait également partie des possibilités. Rapports À l'occasion des réunions visées ci-dessus, ainsi qu'à des moments convenus, l'adjudicataire établira les rapports nécessaires concernant les moyens mobilisés (personnel, méthodes, matériel, logiciels), l'avancement du projet, sa situation… Périodiquement, à savoir 1 fois par mois, suivant un calendrier mis au point de commun accord lors de la réunion de coup d'envoi, l'adjudicataire rédigera un rapport complet d'avancement du projet (situation de chaque phase de la réalisation) à l'intention du comité de pilotage. Le rapport évoquera les problèmes éventuels et les solutions proposées. L'adjudicataire rédigera aussi des rapports de coordination et de travail sur l'avancement du projet (situation de chaque phase de la réalisation), les problèmes éventuels et les solutions proposées. Les réunions auront lieu ponctuellement, à la demande des parties. Le rythme de ces rencontres dépendra de la progression des phases du projet. Le lieu des réunions sera précisé par le SPF Finances avec les dates. Le soumissionnaire et le coordinateur de projet désigné par lui mettront à la disposition du chef de projet toutes les informations nécessaires pour surveiller le déroulement réel des activités du soumissionnaire et la situation par rapport au planning. Ce rapportage destiné au chef de projet suivra une fréquence hebdomadaire, sur la base d'une situation représentée sur le schéma Gantt du projet, complétée d'une brève description écrite, avec les points principaux, les problèmes éventuels et leur solution. Tous les détails des modalités de rapportage doivent être communiqués au début du projet. Tous les aspects relatifs au fond (planning, risques, qualité, réception, ressources) seront d'abord évoqués au sein de l'équipe de projet. Si le chef de projet le juge nécessaire, les problèmes seront soumis à l'examen et à la délibération du comité de pilotage. Chaque mois, le chef de projet remettra au comité de pilotage un rapport sur l'avancement du projet. Gestion des changements (voir aussi partie II, Gestion des changements (req uest for change)) Tout changement (scope, résultats/produits visés, planning, budgets) au projet doit faire l'objet d'une demande de changement spécifiant le motif et l'impact du changement. Le comité de pilotage évalue le bien-fondé et l'opportunité du changement envisagé. Il peut se faire assister du PMO (opérationnel) et/ou d'un expert (externe).


Page 58 sur 149

L'accord formel du fonctionnaire dirigeant conditionne l'exécution des changements envisagés dans la limite de ses prérogatives. Le cas échéant, l’adjudicataire devra actualiser le PID.

4 Description de la mission.

4.1 Description générale de la mission Le présent marché portera sur le développement et la maintenance d’une application dénommée FIRST. En effet, outre le développement, la maintenance de l’application doit être aussi assurée pendant la durée totale du marché. Il sera demandé à l’adjudicataire d’assurer le cycle complet de développement de l’application. On entend par cycle complet de développement d’assurer les étapes non exhaustives suivantes :

• Analyse fonctionnelle et technique • Architecture et Design • Implémentation • Documentation complète • Suivi de la qualité (tests unitaires, fonctionnels et de charge)

A côté du développement à proprement parler il sera demandé à l’adjudicataire :

• D’assurer la gestion de projet • D’assurer le delivery management (rédaction des documents d’installation, livraison

des delivrables dans les différents outils,…) • Formations des utilisateurs et du service ICT • Support à la mise place du DRP (disaster recovery plan) et du BCP (business

continuing plan) Le soumissionnaire devra dans son offre fournir un projet de PID. La première mise de celui-ci se fera pour le kick-off.

4.2 Méthode de développement Le SPF Finances souhaite que l’adjudicataire adopte une méthode itérative et incrémentale lors du développement. Ceci implique que l’adjudicataire doit prouver dans son offre sa faculté d’adaptation ainsi que sa flexibilité face aux changements. Le soumissionnaire décrira en détail dans son offre la méthode de développement qu’il compte adopter en fonction des postes à développer. Pour chaque tranche, il sera demandé à l’adjudicataire d’effectuer des cycles de développement court permettant des tests fonctionnels rapides ainsi que l’adaptation à d’éventuels changements des spécifications. Un processus de développement de type « waterfall » est donc exclu.

4.3 Intégration et déploiement dans l’environnement du SPF Finances

4.3.1 Connectors - intégrations Il est clair que le système devra interagir avec une multiplicité d'autres systèmes, dont certains restent peut-être à définir. Dans son offre, le soumissionnaire expliquera comment


Page 59 sur 149

les collaborateurs du Service d'encadrement ICT pourront à l'avenir construire des interfaces avec des applications qui ne sont pas encore connues aujourd'hui. Le soumissionnaire doit donc préciser les conditions à remplir pour qu'un système soit connectable. Dans son offre, le soumissionnaire décrit les connectors et/ou les intégrations qu'il juge nécessaires pour pouvoir mettre en place les fonctionnalités demandées. Il doit aussi spécifier les services qu'il fournira et les tâches qui devront être exécutées dans le cadre de la mise en place des connectors et/ou intégrations. L'attention est attirée sur le fait que les messages entrants sont souvent (mais pas toujours) structurés en XML. En conséquence, dans la mesure du possible, cela déclenchera une saisie de données automatique (avec ou sans contrôle par une personne humaine) dans les applications sous-jacentes. On notera par ailleurs que les messages traités peuvent aussi être à la base d'une saisie de données manuelle.

4.3.2 Installation de la solution Le soumissionnaire doit proposer un plan d'installation à haut niveau. La création et la tenue du plan incombent au soumissionnaire. Le plan d'installation doit prévoir :

1. Les délais d'installation de l'application 2. Le niveau de participation du personnel du soumissionnaire et du personnel du SPF Finances à chaque stade du projet 3. Les résultats finaux (livrables) 4. La formation du personnel du SPF Finances à dispenser à chaque phase du projet

(voir aussi ‘Gestion du projet et méthodologie’) 5. Les autres informations éventuelles que le soumissionnaire juge nécessaires.

Durant la phase d'installation qu'il sera appelé à réaliser, l'adjudicataire collaborera directement avec le personnel du SPF Finances. Le personnel du SPF Finances identifiera les principaux stades du processus et organisera une concertation pour analyser et réorienter l'installation. L'adjudicataire doit produire une présentation adéquate pour chacune de ces réunions. L'adjudicataire rédigera un rapport d'activité mensuel complet au comité de pilotage. L'adjudicataire collaborera avec le personnel du SPF Finances pour définir la teneur du rapport. Le SPF Finances possède 3 environnements reconnus : développement/packaging, Test et Production. Les développeurs ont entièrement la main sur l’environnement de développement/packaging. Par contre, les déploiements dans les environnements de Test et de Production seront effectués par les équipes du SPF Finances. Afin de pouvoir effectuer ce déploiement sans difficulté, l’adjudicataire fournira un document d’installation détaillé et conforme aux standards du SPF Finances. Il apportera aussi son aide aux équipes opérationnelles pour les configurations spécifiques de l’application fournie. Paramétrages spécifiques Pour tous les paramétrages spécifiques, le soumissionnaire précisera s'ils doivent être réalisés par lui seul ou si le SPF peut s'en charger de façon autonome, moyennant une formation adéquate.


Page 60 sur 149

4.3.3 Tests et plan qualité Le soumissionnaire explique l'approche qu'il entend utiliser pour assurer la qualité du code fourni ainsi que pour tester le système. Il présentera son plan qualité et de test au SPF Finances. Le soumissionnaire propose et documente un système de test (chargé de vérifier le bon fonctionnement du système et le traitement correct des données). Les tests d'efficacité de l'utilisation de l'application seront effectués dans des groupes d'utilisateurs spécifiques pour chaque module. Le soumissionnaire se charge aussi de cet aspect et le documente. Des essais seront exigés dans les services extérieurs. Dans son offre, le soumissionnaire explique comment il entend répondre à ces exigences et comment les environnements seront reliés entre eux.

4.4 POSTES A REALISER

IMPORTANT Remarque générale : les UC dont il est question ci-après et qui existent seront fournies tel quels à la demande du soumissionnaire sur support informatique. Le soumissionnaire devra faire sa demande pour obtenir les UC à l’adresse mail suivante [email protected]

4.4.1 TRANCHE 1 : « INTAKE GENERIQUE » Il s’agit de développer un module pour recevoir/encoder, charger et valider techniquement et fonctionnellement les données permettant l’établissement des droits fiscaux et non-fiscaux à percevoir/recouvrer ou à rembourser de manière générique et le cas échéant retourner un message avec le résultat de la validation. Ce module devra offrir la possibilité de faire cela via des web services, flux FTP et des écrans web génériques pour un encodage manuel. Le terme générique doit être compris comme indiqué ci-dessous :

• En ce qui concerne le web service et le flux FTP : utilisation d’un message xml standard et paramétrable selon le type de droit à prendre en charge.

• En ce qui concerne l’écran web : offrir la possibilité d’encoder les données nécessaires pour prendre en charge différents types de droits en se basant sur un formulaire web standard avec des champs fixes et des champs paramétrables selon le type de droit concerné.

• Les données constituent trois blocs principaux : o Signalétique de la personne, physique ou morales, o Informations liées au droit à traiter, o Informations liées au montant (à recevoir ou à rembourser)

La découpe fonctionnelle ci-dessous met en évidence les grandes étapes communes, pour les différents droits (produits) traités par l’AGPR, situées en tout ou en partie dans le périmètre de FIRST :


Page 61 sur 149

Figure – Etapes clés des processus FIRST – « Chaîne complète »

1. L’enregistrement du client et de la relation ave c le client

• Création / mise à jour du volet données personnelles du dossier unique • Création / mise à jour de l’entité fiscale, non fiscale ou autre

2. L’établissement des droits fiscaux et non fiscau x • Création / mise à jour du dossier fiscal ou non fiscal • Enregistrement et traitement de la déclaration, ou de la demande, ou du

relevé. • Calcul des droits fiscaux et non fiscaux

3. La perception des droits fiscaux et non fiscaux • Enregistrement et comptabilisation des droits fiscaux et non fiscaux • Paiements, remboursements et comptabilisation en regard des droits fiscaux

et non fiscaux correspondants 4. Le recouvrement

• Recouvrement • Mesures conservatoires

5. Le contentieux P & R • Contentieux P & R

Les produits tels qu’Amendes pénales et Précompte mobilier, de FIRST qui sont déjà en production ont principalement mis en place des chaînes complètes par lesquelles les 5 étapes précédentes sont parcourues. D’autres produits à réaliser dans le cadre de ce marché peuvent avoir une répartition sensiblement différente, dans la mesure où des parties importantes de l’établissement (fiscal ou non fiscal) sont prises en charge par d’autres applications /organismes. Les situations sont donc diverses : Ainsi, lorsque l’intégralité de l’établissement est réalisée hors FIRST, alors la chaîne de traitement est limitée à la perception, au recouvrement et au contentieux. Ceci est illustré à la figure ci-après sous l’appellation « Chaîne P & R ».


Page 62 sur 149

Figure – Etapes clés des processus FIRST – « Chaîne perception et recouvrement »

L’autre cas de figure est lorsqu’une partie de l’établissement, soit le traitement des déclarations, est réalisée hors FIRST tandis que le traitement des données de ces déclarations est réalisé par des modules propres à FIRST. Ceci est illustré à la figure ci-après sous l’appellation « Chaîne avec établissement réparti».


Page 63 sur 149

Figure 1 - Etapes clés des processus FIRST – « Chaî ne avec établissement réparti »

Le tableau ci-après, reprend pour chaque produit fiscal / non fiscal, la répartition de l’établissement en dehors ou dans FIRST.

Produits en production ou en cours de l’être VA Versements Anticipés Chaîne complète. SC Saisies-Cessions Chaîne complète. AP/ PenB Amendes Pénales Chaîne complète. PrM/ RV Précompte Mobilier Chaîne complète BDW/TPT Taxe sur la Participation

des Travailleurs Chaîne complète. Note : le droit est déterminé par self-assessment.

Produits à prendre en charge Produits enrôlés et gérés dans ICPC IPP/ PB L’impôt des personnes

physiques Chaîne perception et recouvrement. Etablissement : fait par PB/IPP et les applications connexes comme TOW Interfaces avec PB/IPP

• Utilisation des VA • Mise en compte

- Droit – Calcul initial - Droit – Supplément - Droit – Dégrèvement

ISOC/VENB L’impôt des sociétés Chaîne perception et recouvrement.

Les déclarations et le calcul sont traités dans BIZTAX


Page 64 sur 149

La gestion de l’établissement est donc intégralement réalisée hors FIRST. Il y a lieu de développer la même interface de mise en compte des droits calculés par BIZTAX avec FIRST qu’avec ICPC actuellement.

IPM/RPB L’impôt des personnes morales

Idem VENB

INR Soc/ Ven BNI

L’impôt des non-résidents – sociétés

Idem VENB

INR PP/ BNI NP L’impôt des non-résidents – personnes physiques

Idem PB/IPP

PRP/BV Le précompte professionnel

Chaîne avec établissement réparti. Les redevables du BV/PRP sont des entreprises et plus rarement des personnes physiques. Actuellement, BV/PRP possède son propre signalétique ; dans le futur, cette signalétique sera celui fourni par SITRAN. La déclaration électronique est faite via FINPROF, hors FIRST. Le calcul est réalisé par FIRST sous forme notamment de vérification des montants par rapport au 325.10.

ACNF Recouvrement des autres Créances non-

fiscales

Pour compte de l’Etat Chaîne complète. Pour compte des Institutions de l’Etat

Chaîne complète.

Pour le compte des Communautés et des Régions et des institutions publiques qui en dépendent

Chaîne complète.

TD Taxes Diverses Anciennement Taxes assimilées au Timbre : • chaîne complète • Déclaration spontanée ; le montant de la taxe

est repris sur la déclaration et est calculé par le redevable.

Produits de la Documentation Patrimoniale

- Droits d’enregistrement2

- Droits de succession² - Droit d’écriture - Droits d’hypothèques - Droits de greffe - Coût de services

Chaîne perception et recouvrement Les droits sont calculés dans le cadre des processus de « réclamation de droits ».

2 Partiellement régionalisés


Page 65 sur 149

4.4.1.1 Règles relatives aux relations entre Etabli ssement (intake générique) et Perception pour la Gestion des paiements La relation entre l’Etablissement et Perception est à haut niveau celle d’un « Module de facturation » et celle d’un module de « Comptes clients détaillés et de Gestion de paiements ».

Cette relation dépend des « modalités de facturation » et des « modalités de paiement ».

Différentes situations sont possibles. Toutes ne sont pas d’application pour un droit particulier, mais peuvent l’être pour d’autres droits ou pourraient le devenir pour un droit particulier suite à des changements de la législation.

Une solution pour un impôt particulier doit donc s’appuyer sur des principes génériques communs à tous les types de droits. Ces principes généraux sont rappelés ci-après en partant d’un ensemble illustratif et non exhaustif de modalité de facturation et de paiements.

Différentes modalités de facturations et de paiements sont reprises ici à haut niveau. Soit la facture précède le paiement, soit le paiement précède (partiellement ou non) la facture.

La facture précède le paiement - Paiement de créanc e

1. Etablissement d’une « Facture ordinaire » client, avec un ou plusieurs type(s) de droit(s), un ou plusieurs montant(s) de droit(s) et une invitation à payer le montant total. L’invitation à payer reprend une communication structurée (CS) qui donne une référence vers le « Contexte prédéfini de traitement » qui devra être appliqué au (ou aux) paiement(s) portant cette CS. La « Facture client » est mise en compte dans le « Dossier comptable » du client sous forme d’un « Document comptable » avec son (ou ses) « Détail(s) de documents comptable(s) » et un (ou plusieurs) poste(s) ouvert(s) correspondants. Lorsque le paiement arrive, sa communication structurée permet d’en retrouver le « Contexte prédéfini de traitement » et de procéder à sa mise en compte dans le « Dossier comptable du client » sous forme d’un « Document comptable » avec un ou plusieurs poste(s) ouvert(s). Egalement, le « Contexte prédéfini (de traitement) » permet de procéder à l’affectation du (ou des) poste(s) ouvert(s) du paiement au (ou aux) poste(s) ouvert(s) de la facture.

2. Etablissement d’une ou plusieurs « Facture(s) intermédiaire(s) » client, avec une invitation à payer une somme qui n’est pas nécessairement le montant définitif du droit. L’invitation à payer est munie d’une CS comme ci-avant. La « Facture intermédiaire client » est mise en compte dans le « Dossier Comptable » du client. Lorsque le paiement arrive, sa CS permet d’en retrouver le « Contexte prédéfini de traitement ». Il est mis en compte dans le « Dossier comptable » du client et affecté au règlement de la facture intermédiaire. Lorsque la « Facture finale » est établie, le module de facturation accède avant ou pendant cette facturation à une « Situation de compte » pour connaître l’état de paiement des factures intermédiaires. Le cas échéant (situation possible, mais pas obligée), la « Facture finale » doit pouvoir ajouter des suppléments relatifs aux impayés. Egalement, le cas échéant (situation possible, mais pas obligée), la « Facture finale » doit permettre des ré-imputations de « droits établis d’avance » en « droits constatés ».

Le paiement précède la facture - Paiement à l’avanc e

3. Etablissement d’une « Estimation » d’un droit avec une invitation à payer un « acompte ». L’invitation à payer reprend un montant et une CS. L’estimation n’est en général pas mise en compte dans le « Dossier Comptable » du client, bien qu’elle pourrait l’être sous forme de ‘compte d’ordre’. Lorsque le paiement arrive, sa CS


Page 66 sur 149

permet d’en retrouver le « Contexte prédéfini de traitement ». Le paiement est comptabilisé dans le « Dossier Comptable » du client. Il ne peut cependant être affecté : il y a un poste ouvert de paiement, mais pas d’affectation. Lorsque la « Facture définitive » est établie, le module de facturation doit sélectionner les acomptes versés (via une « Situation de compte ») et les consommer. Cette consommation doit être rendue en « Perception » par une (ou des) affectations. Au besoin, un remboursement de trop perçu doit être réalisé et la « Facture » devient une « Note de crédit ».

4. Envoi d’une invitation à payer une ou des « Avance(s) » sur un droit qui n’a pas encore été établi. L’invitation ne comporte pas de montant mais bien une CS. Lorsque le ou les paiements arrive(nt), la CS permet d’en retrouver le « Contexte prédéfini de traitement ». Le paiement est comptabilisé dans le « Dossier Comptable » du client. Il ne peut cependant être affecté : il y a un poste ouvert de paiement, mais pas d’affectation. Lorsque la facture est établie, le module de facturation doit sélectionner les avances (via une « Situation de compte ») et appliquer, le cas échéant, les bonifications de ces avances et les consommer. Cette consommation doit être rendue en « Perception » par une (ou des) affectations. Au besoin, un remboursement de trop perçu doit être réalisé et la Facture devient une Note de crédit.

5. Une « Provision libre » pour droits à établir est constituée. La différence par rapport à l’avance est que l’avance est censée être plutôt inférieure au montant total du (des) droit(s) et donner lieu à bonification(s) alors que la provision est censée être plutôt supérieure au montant du(des) droits et donner lieu à majoration(s) en cas d’insuffisance. Le système par provision doit être initié par rapport au redevable en lui fournissant une invitation à provisionner par paiement(s) avec une CS liée au « Contexte prédéfini de traitement ». Lorsqu’un paiement est reçu avec cette CS, la CS permet d’en retrouver le « Contexte prédéfini de traitement ». Le paiement est comptabilisé dans le « Dossier Comptable » du client. Il ne peut cependant être affecté : il y a un poste ouvert de paiement, mais pas d’affectation. Lorsque qu’une facture est établie, le module de facturation doit établir les montants déjà provisionnés (via une « Situation de compte »), appliquer, le cas échéant, les majorations prévues pour les insuffisances et consommer les montants provisionnés à concurrence des droits établis. Cette consommation doit être rendue en « Perception » par une (ou des) affectations. Le solde de provision est, de manière générale, conservé plutôt que remboursé.

6. Une « Provision obligée » pour droits à établir est constituée. La différence par rapport au cas précédent est que la provision est obligatoirement supérieure à un droit à établir avant que celui-ci ne puisse être établi : le fait générateur du droit n’est pas réalisé si le droit n’est pas provisionné. Le système par provision doit être initié par rapport à au redevable en lui fournissant une invitation à provisionner par paiement(s) avec une CS liée au « Contexte prédéfini de traitement ». Lorsqu’un paiement est reçu avec cette CS, la CS permet d’en retrouver le « Contexte prédéfini de traitement ». Le paiement est comptabilisé dans le « Dossier Comptable » du client. Il ne peut cependant être affecté : il y a un poste ouvert de paiement, mais pas d’affectation. Lorsque qu’un fait générateur de droit doit être réalisé, le module de facturation doit établir les montants déjà provisionnés (via une « Situation de compte »), et retourner un signal d’insuffisance lorsque le montant provisionné n’est précisément par suffisant. Lorsque le montant est suffisant, la facture peut être établie et consommer les montants provisionnés à concurrence des droits établis. Cette consommation doit être rendue en « Perception » par une (ou des) affectations. Le solde de provision est, de manière générale conservé, plutôt que remboursé.


Page 67 sur 149

L’indépendance entre « Etablissement » et « Perception » implique que toute tâche relative au traitement d’un « Paiement » doit être entièrement réalisée par la « Perception ». Celle-ci ne peut cependant traiter un paiement qu’en appliquant des règles qui lui sont connues. Il importe donc que les règles de traitement soient définies et implantée en « Perception » et également que l’« Etablissement » puisse instancier, en « Perception », un « Contexte prédéfini de traitement », recevoir en retour d’une telle instanciation un identificateur de ce contexte et transmettre au redevable cet identificateur, par exemple en l’inscrivant sur l’« Invitation à effectuer un paiement » remise au redevable. C’est le rôle de la « Communication Structurée (CS) » de servir de référence vers le « Contexte prédéfini de traitement ». Elle est obtenu, de la « Perception », par l’« Etablissement » et transmise au redevable en préalable à l’exécution du paiement. En l’absence d’une « Communication structurée (CS) », l’invitation à payer et le paiement doivent véhiculer des informations qui permettent à un utilisateur de retrouver, de manière assistée par le système, le « Contexte prédéfini de traitement ».

Le tableau suivant reprend les différents éléments intervenants :

Package Etablissement

Ce package représente l’« Etablissement » dans le cadre de sa relation avec « Perception » pour le traitement des paiements. Il :

1. Crée une facture ordinaire avec une invitation à payer celle-ci

2. Crée une facture intermédiaire avec son invitation à payer la facture intermédiaire ; peut en créer ainsi plusieurs, puis Crée la facture finale avec une invitation à payer celle-ci

3. Crée une estimation et envoie une invitation à verser un acompte

4. Invite le redevable à payer une (ou des) avance(s) pour un droit à établir

5. Invite le redevable à payer un montant librement choisi afin de bénéficier de bonification(s) par rapport à des droits restant à établir.

6. Invite le redevable à alimenter une provision suffisante pour assurer le paiement de droits à établir

Dans tous les cas, le paiement représente des droits établis ou restant à établir vis-à-vis de Personne(s) et d’Entité(s). Ceci est exprimé par le fait que Etablissement utilise (<<use>>) le package Entités et le package Personnes.

<<TRAITEMENT>> InvitationAEffectuerPaiement

Ce traitement représente ici de manière générique la création de l’invitation à effectuer un paiement. Dans le cas d’une facture (ordinaire, intermédiaire ou finale) ou d’un acompte, l’invitation à effectuer le paiement détermine un montant à payer et utilise (<<use>>) un résultat de Calcul. Dans le cas de l’invitation à payer une avance ou à établir une provision libre ou obligée, l’invitation à payer ne comporte pas de mention d’un montant et il n’y a pas d’utilisation d’un


Page 68 sur 149

résultat de Calcul. L’invitation à payer est réalisée dans un « Contexte prédéfini de traitement » qui comprend d’une part un Ensemble de Règles de Traitement et d’autre part un Ensemble de Données de Contexte à utiliser. Bien entendu, à haut niveau, l’Ensemble de Règles de Traitement sera identifié par un type :

• Paiement de créance o Paiement d’une facture ordinaire o Paiement d’une facture intermédiaire o Paiement d’une facture finale

• Paiement à l’avance o Paiement d’un acompte o Paiement d’une avance o Paiement d’une provision

A haut niveau, l’Ensemble de Données de Contexte comprendra notamment :

• Un type de droit, ou un ensemble de types de droits

• Une Entité fiscale ou non fiscale • Une Personne, ou un ensemble de Personnes • Un type non périodique ou périodique, et dans

ce dernier cas une ou plusieurs périodes. Pour communiquer à « Perception » ce « Contexte prédéfini de traitement » et recevoir en retour une communication structurée (CS), l’InvitationAEffectuerPaiement fait appel aux services (<<use>>) du traitement GestionCS de Perception.

Calcul

Indique de manière générale que le montant d’une invitation à payer une créance est un résultat de « Calcul ».

Package Entites

Ce package gère les Entités fiscales, non fiscales et autres. Utilisé par le Package Etablissement Utilisé par le Package Perception

Entité

Représente génériquement une entité fiscale non fiscale ou autre. Une Entité est un ensemble d’une ou plusieurs personnes dans un rôle spécifique par rapport à un type de droit ou par rapport à une activité particulière. L’Entité permet de faire la distinction entre une « Personne » en tant que « Contribuable », « Ayant-droit », « Fournisseur », etc. Egalement l’entité peut représenter un groupe de personnes liées entre-elles de manière solidaire ou conjointe par rapport à un droit (dette solidaire, dette conjointe).

Package Personnes Ce package regroupe les données signalétiques


Page 69 sur 149

relatives aux personnes physiques et morales. Utilisé par le Package Etablissement Utilisé par le Package Perception

UnitePersonne Cette entité représente une personne physique et/ou morale. Dans le cas où une personne est reprise dans plusieurs signalétiques, l’Unité Personne fait le lien entre la personne unique et les signalétiques multiples.

Package Produits Ce package regroupe les données relatives aux éléments de signalétique des types de droits. Utilisé par le Package Etablissement Utilisé par le Package Perception

TypeDeDroit Représente un type de droit dans le rôle qu’il tient par rapport aux traitements à effectuer et aux données de contexte qui doivent être établies.

Package Perception Ce package reprend ici un extrait des données et des traitements de Perception impliqués dans l’identification des Règles de Traitement et des Données de Contexte à utiliser dans la gestion des paiements dans les différents cas :

• Paiement de créance o Paiement d’une facture ordinaire o Paiement d’une facture intermédiaire o Paiement d’une facture finale

• Paiement d’avance o Paiement d’un acompte o Paiement d’une avance o Paiement d’une provision

Pour être utilisé, le traitement correspondant doit être implanté dans le système. Ceci est mis en évidence, dans le diagramme, par la spécialisation de « TraitementDuPaiement » en :

• TraitementPaiementDeCreance • TraitementPaiementAL’Avance

Ensuite, il faut pouvoir retrouver le type de traitement à appliquer à un paiement particulier. C’est le rôle de ContextePredefiniDeTraitement, qui sur le diagramme, représente les règles, primitives d’accès et les conventions qui permettent de retrouver les Règles de Traitement et les Données de Contexte à utiliser dans la gestion des paiements. Concrètement, l’implantation de ContextePredefiniDeTraitement diffère selon qu’une facture a été établie (facture ordinaire, facture intermédiaire, facture finale) ou que le paiement se fait à l’avance (acompte, avance, provision libre ou obligée). Paiement de créance Dans le premier cas, la mise en compte de la facture


Page 70 sur 149

(inscription de la facture dans le « Dossier comptable » du client crée un « Paiement à recevoir ». Facture et paiement reprennent la CS comme référence. Les données de « Données de Contexte » sont donc disponibles par défaut. De ce fait, lorsque le paiement est effectué par le client et communiqué au SPF Finances via un relevé de compte, il suffit au « TraitementDuPaiement » de retrouver, via la CS reprise sur le « Mouvement » du « ReleveDeCompte », le paiement à recevoir et la facture correspondante, pour rétablir les « Données de Contexte » :


• Une Entité fiscale ou non fiscale • Une Personne, ou un ensemble de Personne • Une Période (si d’application)

Les rôles de « UtilisationCS » et de « ContextePredefiniDeTraitement » sont clairement minimaux. Il en va de même pour « GestionCS » qui peut se réduire à noter qu’une communication structurée n’est plus libre et est associée à un paiement de type « Paiement de créance ». Sur base des informations retrouvées, le « TraitementPaiementDeCreance » va pouvoir procéder à la mise en compte du paiement dans le « Dossier comptable » du client et à l’utilisation du paiement pour le règlement partiel ou complet de la (ou des) créances. Paiement à l’avance Dans le second cas, il n’y a aucune donnée disponible par défaut. De ce fait, lorsque le paiement est effectué par le client et communiqué au SPF Finances via un relevé de compte, le « TraitementDuPaiement » ne peut retrouver via la CS que ce qui aura été associé préalablement à la CS par « UtilisationCS » et « ContextePredefiniDeTraitement ». C’est précisément le rôle de « GestionCS » de permettre à l’ « Etablissement » de passer un ensemble de données de contexte à « Perception » et d’associer la CS à ces données. Soit donc à


• Une Entité fiscale ou non fiscale • Une Personne, ou un ensemble de Personne • Une Période (si d’application)

Cette association peut être réalisée via des accesseurs de ces données (on n’a pas les données, mais les méthodes/moyens pour y accéder). Sur base des informations retrouvées, le « TraitementPaiementAL’avance » va pouvoir procéder à la mise en compte du paiement dans le


Page 71 sur 149

« Dossier comptable ». <<TRAITEMENT>> GestionCS

Voir description ci-avant dans Package Perception

UtilisationCS Cette entité représente à un niveau conceptuel, les données d’utilisation d’une communication structurée. Les attributs repris sur le diagramme représentent une liste minimale. Il faut noter que les données ne sont nécessaires qu’en l’absence d’une convention qui permet d’encoder le « ContextePredefiniDeTraitement » dans la CS. Par exemple, pour le Précompte professionnel, une convention permet d’établir que la CS, dans le contexte d’un compte de bureau de recette, est celle du Précompte professionnel, pour un redevable donné et pour une période donnée. Une convention existe également pour avances des VA et pour les provisions libres de la TVA Compte Courant.

ContextePredefiniDeTraitement Cette entité représente les données de contexte ou les manières de les retrouver pour traiter des paiements, en visant plus spécifiquement les Paiement à l’avance.

CompteFinancier Entité Compte Financier

CommunicationStructurée Entité Communication Structurée

Paiement Entité Paiement du Système de Gestion des Paiements

ReleveDeCompte Relevé de Compte (CODA)

Mouvement Détail du relevé de compte / opération CODA

<< TRAITEMENT>> TraitementDuPaiement

Voir description ci-avant dans Package Perception

TraitementPaiementDeCreance Voir description ci-avant dans Package Perception

TraitementPaiementAL’avance Voir description ci-avant dans Package Perception

4.4.1.2 Produits à réaliser :

Les UC ci-dessous doivent être réalisés dans la logique d’un intake générique offrant des interfaces tant avec les applications internes qu’externes en donnant la possibilité à l’utilisateur interne de gérer manuellement les déclarations concernées. Par ailleurs, ces UC seront appliqués aux matières reprises plus loin, sous le point «III.4.4.1.3 Impôt et taxes concernés ». Ces interfaces seront constituées de web services, chargement de fichiers et de web applications (pour l’encodage manuel) de sorte à pouvoir effectuer les tâches génériques suivantes :

• Prendre en charge une déclaration (terme générique pour déclaration/titre/demande de recouvrement/Relevé)

• Valider une déclaration • Accuser réception de la déclaration


Page 72 sur 149

• Modifier une déclaration • Calculer la dette si nécessaire • Lancer une invitation à payer

Principaux UC à réaliser avec adaptation partielle ou complète de l’analyse si nécessaire : 1. UC 02-05-17 TRAITEMENT ET VALIDATION DES DECLARA TIONS TD 2. UC 02-05-19 TRAIT. ET VALID. DES DECLARATIONS CR EANCES NON FISCALES 3. UC 02-06-01 INTRODUIRE ET VALIDER MANUELLEMENT U NE NOUVELLE

DECLARATION 4. UC 02-06-02 CONSULTER ET MODIFIER UNE DECLARATIO N EXISTANTE 5. UC 02-06-03 ANNULER UNE DECLARATION EXISTANTE 6. UC 05-04-28 CALCUL DE LA TAXE SUR LES OPERATIONS DE BOURSE 7. UC-05-04-29 CALCUL DES TAXES DIVERSES 8. UC 05-04-30 CALCUL DE LA TAXE ANNUELLE SUR LES C ONTRATS

D’ASSURANCE 9. UC 05-04-31 CALCUL DE LA TAXE ANNUELLE SUR LES P ARTICIPATIONS BENEF 10. UC 05-04-32 CALCUL DE LA TAXE SUR L’EPARGNE A L ONG TERME 11. UC 05-04-33 CALCUL DE LA TAXE D’AFFICHAGE 12. UC 05-04-34 CALCUL DE LA TAXE ANNUELLE SUR LES ORGANISMES

PLACEMENT 13. UC 05-04-43 CALCUL DE LA TAXE SUR LES ECRITS BA NCAIRES 14. UC-05-04-44 CALCUL DE LA DETTE DE L’ORDRE DE RE COUVREMENT ACNF 15. UC 06-04-14 GERER LES DECLARATIONS TAT NON REÇU ES 16. UC 00-00 ANALYSE INTERFACE – ENROLEMENT 17. UC 06-03 GERER UN TITRE EXECUTOIRE – ADDENDUM 18. UC 06-03-01 VALIDER UN TITRE EXECUTOIRE – ADDEN DUM 19. UC 07-38-24 AJOUTER UN TITRE EXECUTOIRE – ADDEN DUM PAR AILLEURS, IL EST DEMANDE AU SOUMISSIONNAIRE D’A PPORTER DES AMELIORATIONS TECHNIQUES AU NIVEAU DES DEPENDANCES ENTRE ETABLISSEMENT DES MODULES METIERS (AMENDES PENALES ET PRECOMPTE MOBILIER) ET LE MODULE ACCOUNTING POUR RENDRE CE DE RNIER INDEPENDANT DE LA NATURE DU DROIT ET COMPLETEMENT G ENERIQUE. EN OUTRE, IL FAUT INTEGRER CES DEUX MODULES METIER (AM ENDES PENALES ET PRECOMPTE MOBILIER) DANS L’INTAKE GENERIQUE EN DEVE LOPPANT LES INTERFACES NECESSAIRES.

4.4.1.3 Impôt et taxes concernés REMARQUE GÉNÉRALE CONCERNANT LES IMPÔTS ET TAXES CI -DESSOUS : IL FAUT PROCÉDER À LA MIGRATION DES DONNÉES DES SYSTÈM ES QUI LES TRAITENT ACTUELLEMENT VERS FIRST.

A - Impôt des sociétés (ISoc /VenB), Impôt des personnes morales (IPM/RPB) et Impôt des non-résidents sociétés (INR Soc/Ven BNI)

L’impôt sur le revenu des sociétés est, par rapport à FIRST, un impôt du type « chaîne


Page 73 sur 149

perception et recouvrement ». Le traitement des entités, des déclarations et des calculs est entièrement pris en charge en dehors du périmètre de FIRST. La perception et le recouvrement sont entièrement pris en charge par FIRST. Dans ICPC (as-is), l'impôt des sociétés et l'impôt des personnes morales sont immédiatement enrôlés et donc rendus exécutoires. Les paiements sont effectués principalement via une communication structurée et le pourcentage de perception est élevé. La déclaration à l’impôt des sociétés doit se faire dans les 6 mois suivant la clôture de l’exercice comptable. 80% des entreprises clôturent leur exercice comptable le 31/12. Mais outre l’introduction des déclarations papier en juin/juillet, il n’y a aucun pic dans la charge de travail. FIRST recevra un fichier structuré avec tous les impôts établis et déclarés exécutoires pour l’impôt des sociétés (résidents ordinaires et non-résidents) et l’impôt des personnes morales. Ces fichiers comprennent tout ce qui est nécessaire pour pouvoir charger les impôts et pour pouvoir réaliser la perception et le recouvrement. Pour l’heure, l’Isoc, l’Isoc/INR et l’IPM sont immédiatement mis au rôle et un avertissement-extrait de rôle est envoyé. Cela reste maintenu. FIRST chargera l’Isoc, l’Isoc/INR et l’IPM et créera le rôle, mais n’enverra pas l’avertissement-extrait de rôle.

Traitements principaux Le rôle de FIRST se limitant à la partie Perception et Recouvrement, les éléments pertinents pour cet impôt sont à trouver dans les deux sections « Généralités relatives aux relations entre Etablissement et Perception pour la Gestion des paiements » et « Généralités relatives aux relations entre Etablissement et Perception pour la Création des Documents Comptables ». B - Recouvrement des Autres Créances Non Fiscales Le pilier Recouvrement Non Fiscal de l’AGPR a dans ses attributions de recouvrer les créances non fiscales au profit de l’autorité fédérale, des Communautés, Régions et Organismes d’Intérêt Public. Ces services sont saisis des dossiers que les comptables ordinaires, dont les moyens de poursuite sont limités, n’ont pu mener à terme. Ces créanciers devraient soumettre leur demande d’intervention à l’AGPR en utilisant l’intake générique « Ordre de recouvrement ». Les activités liées au recouvrement des créances no n fiscales et autres Les activités qui sont présentées ci-dessous correspondent au traitement actuel des créances non fiscales.

1. Réception/Enregistrement des créances non fiscales

Le formulaire 33 bis « Ordre de recouvrement » permet aux départements créanciers d’introduire leur demande de recouvrement. Celui-ci contient les éléments suivants :

• Désignation du créancier (Nom ou dénomination, Adresse complète) • Désignation du débiteur (Nom ou dénomination, lieu et date de naissance, adresse

complète) • Montant de la créance (Principal, Intérêts, Frais) • Titre de la créance (Principal, Intérêts, Frais) • Nature de la créance • Nature de l'engagement • Caution • Transfert (Dénomination, N° C.C.P., Mentions) • Prescription (Disposition légale, Délai, Date de prise de cours, Date d'expiration,

Prescription déjà interrompue). Celle-ci varie entre 6 mois et 30 ans selon le cas


Page 74 sur 149

• Divers Ce formulaire devra faire servir pour développer l’intake électronique des ACNF. Il permettra de joindre des copies électroniques des pièces justificatives si nécessaire. Il existe deux types de titres :

• Les titres basés sur une décision judiciaire

• Les titres basés sur une décision administrative prévue légalement. Cette décision administrative énonce formellement si le débiteur peut faire appel de celle-ci ou si le cas n’est pas prévu.

Si le dossier est complet et recevable, un accusé de réception, individuel ou collectif, est immédiatement envoyé à l’organisme créancier avec le numéro de référence du dossier. Cet accusé de réception provoque le déchargement du comptable de sa responsabilité en cas de non-recouvrement.

2. Envoi de l’invitation à payer

Un avis de paiement est envoyé au débiteur l’enjoignant de payer dans la quinzaine (par courrier simple). Celui-ci comprend la justification de la dette ainsi que son détail.

Traitements principaux

• Introduire la demande de recouvrement avec ses éventuelles annexes • Valider le dossier • Evaluer la recevabilité • Envoyer un accusé de réception • Envoyer une invitation à payer

C -Taxes Diverses

Introduction

Les Taxes Diverses représentent du point de vue de FIRST des « chaînes complètes » Entité+Etablissement+Perception et Recouvrement. Sous l’appellation « TD » on reprend toutes les taxes listées ci-dessous :

• Taxe sur les opérations de bourse (TOB / BBV) • Taxe annuelle sur les opérations d'assurance (TACA / JBVC) • Taxe annuelle sur les participations bénéficiaires (TPB / BWD) • Taxe sur l'épargne à long terme (TELT / BLTS) • Taxe d’affichage (TA / BA) • Taxe annuelle sur les organismes de placement collectif, sur les établissements de

crédit et sur les entreprises d’assurances (TOPC / JBCB, TEC, TEA, JTKI) Flux métier Le traitement pour toutes les TD est similaire. Toutes les informations dans ce document sont applicables pour toutes les TD, sauf si mentionné explicitement. Le flux de traitement est très semblable aux autres flux d’impôts sur base de déclaration comme le Précompte mobilier (PrM) par exemple. On peut répartir les différentes TD dans les groupes suivants :

• TOB,


Page 75 sur 149

Les deux taxes visent certaines opérations sur instruments financiers (actions, obligations, sicav, …) et sont déclarées et acquittées par les mêmes déclarants : les intermédiaires professionnels (établissements de crédit et entreprises d’investissement). Il existe deux possibilités de remboursement. Ceux-ci sont effectués soit par compensation dans une déclaration ultérieure (tolérance administrative) soit sur base d’une demande express à laquelle doivent être joints les documents justificatifs (CDTD, art. 136).

• TPB, TELT, TACA

Les trois taxes concernent le secteur des assurances auquel s’ajoute, pour la TELT, l’épargne-pension constituée auprès d’un établissement de crédit ou d’une société de bourse. Les 3 taxes sont déclarées et acquittées par l’assureur établi en Belgique. Pour la TACA, à défaut d’assureur établi en Belgique, sont redevables soit le courtier établi en Belgique soit l’assureur établi à l’étranger. En dernier ressort, le preneur d’assurance est redevable. En ce qui concerne la TELT sur l’épargne-pension, la taxe est due par l’établissement de crédit ou la société de bourse. Pour la TACA, la déclaration et le paiement de décembre sont anticipatifs. Un montant égal à celui déclaré en novembre doit être acquitté.

• TA

Type de déclarant : • La personne au profit de laquelle l’affichage a lieu (PP, PM, SOC) • Les entrepreneurs d’affichage • Les fabricants d’affiches (ex. : les imprimeurs), sur base volontaire.

Pour la taxe d’affichage le paiement est anticipé pour les affiches ponctuelles. Le code reçu après paiement doit être imprimé sur les affiches (>=1m²) Les professionnels reçoivent une référence à utiliser sur toutes leurs affiches. Leurs déclarations ne se font pas par affiche mais de façon périodique. Elles reprennent les affiches apposées ou fabriquées durant le mois précédent. En début d’activité, une provision est payée, sur base d’une estimation de l’activité future. A chaque déclaration, la taxe due est calculée, imputée sur la provision et une nouvelle provision est versée.

• TOPC

Les deux taxes sont déclarées et payées une fois par an (entre le 1 janvier et le 31 mars).

Traitements principaux

• Création de l’entité fiscale • Réception de la déclaration + Validation • Traitement des erreurs • Calcul : le calcul ne sert qu’à acter le montant calculé par le redevable et à le mettre

en compte • Mise en compte du calcul • Invitation à payer

Voir « Généralités relatives aux relations entre Etablissement et Perception pour la Gestion des paiements » et « Généralités relatives aux relations entre Etablissement et Perception pour la Création des Documents Comptables » pour les principes de la mise en compte et de la gestion des paiements à l’avance. D – Impôt des personnes physiques (résidents et non -résidents) L’impôt sur le revenu des personnes physiques est, par rapport à FIRST, un impôt du type « chaîne perception et recouvrement ». Le traitement des entités, des déclarations et des


Page 76 sur 149

calculs est entièrement pris en charge en dehors du périmètre de FIRST. La perception et le recouvrement sont entièrement pris en charge par FIRST. Chaque contribuable reçoit annuellement une invitation à déclarer son impôt sur le revenu des personnes physiques (IPP). Mariés ou cohabitant légaux qui sont imposés ensemble reçoivent une seule invitation pour les deux. La déclaration peut être faite sur papier et via Tax-on-Web. Les déclarations papiers sont numérisées et les données transférées à Taxi "Système d’intégration des données fiscales". Il y a aussi les données de Tax-On-Web. Dans TAXI se produit un certain nombre de vérifications et de validations logiques selon certaines règles métier. Les données de TAXI sont utilisées par l'application Calcul-IPP pour calculer l'impôt qui est ensuite enrôlé. FIRST recevra un fichier structuré contenant les données concernant l’impôt sur le revenu des personnes physiques (résidents et non-résidents). Ce fichier contient les données à charger nécessaires pour réaliser la perception et le recouvrement de l’impôt.

Traitement Important FIRST assure l’enrôlement à la fois des droits positifs et négatifs. TAXI est mis à l'état "Enrôlé". A la fin du 2ème mois suivant le mois d’envoi de l’avertissement-extrait de rôle, l’impôt doit être payé ou le remboursement est effectué. Si un contribuable a une ou plusieurs dette(s) et a droit à un remboursement d'impôt sur le revenu, ce dernier peut être retenu partiellement ou entièrement pour apurer la dette. Les paiements sont principalement traités automatiquement grâce à la communication structurée. Cependant, il continue d'y avoir une grande proportion des paiements à attribuer manuellement. Suite à un défaut de paiement dans le délai imparti, il est immédiatement procédé au recouvrement. Cela implique l'envoi d'un rappel, rappel recommandé et à entamer une action de recouvrement par huissier de justice, saisie et autres. Ces actions sont enregistrées dans FIRST. Rédaction dette, cas de faillite, etc. relèvent des procédure de recouvrement. Dans le cas de couples mariés qui ne sont pas encore divorcés mais séparés de fait, des procédures spéciales doivent être suivies (article 393bis WIB92). Les coûts associés à ces mesures de recouvrement sont également inscrits dans FIRST. En cas de retard de paiement des intérêts sont comptabilisé par FIRST. Afin de prévenir la prescription de la dette, FIRST crée des listes de prescription qui permettent aux gestionnaires de dossiers de prendre les actions pour suspendre la prescription.


Page 77 sur 149

4.4.2 TRANCHE 2 « Amélioration Accounting + Interf ace GL avec Fedcom »

4.4.2.1 Architecture fonctionnelle originale Un bref aperçu de la conception originale de l’architecture fonctionnelle de FIRST : La Comptabilité Dettes et Avoirs

Le bloc fonctionnel de Comptabilité Dettes et Avoirs prend en charge la gestion « comptable » des Dettes et des Avoirs qui sont générés par l'Établissement, par le Recouvrement Non Fiscal et par le Recouvrement proprement dit. Ce système supporte les processus

• P7 – Perception - Recettes • P8 – Perception – Dépenses • P9 – Clôtures

Il collabore de manière très étroite avec le système de Recouvrement qui supporte quant à lui les processus

• P30 – Mesures Conservatoires • P31 – Recouvrement

Les packages fonctionnel Package fonctionnel Description Centralisation et Compteurs

Produit les documents comptables de centralisation et donc les écritures correspondantes à destination de la Comptabilité Générale (ou plus généralement, Générale, Budgétaire et Analytique). Permet également de produire les documents de liquidation au profit des différents ayants-droit. Les compteurs représentent actuellement le seul mode de centralisation existant. Pour des raisons de compatibilité, ce

Situation de Compte (Serveur)

Interface Comptable

(Finalisation)

Déterminationde Compte (F)

Etablissement

Mise en Compte

Situation de Compte

Détermination de Compte (P)

RNF

Mise en Compte

Situation de Compte

Détermination de Compte (P)

Reporting

Interface Banque

Interface CG / Trésorerie

Interface Liquidation

via Trésorerie

Comptabilité Dettes et Avoirs

DossiersComptables

Interface Comptable

Personnes,Contribuables

et Autres Tiers

Mesures Conservatoires

Recouvrement

Recouvrement

CentralisationEt

Compteurs

Système de Gestion

Des paiements

Perception


Page 78 sur 149

Package fonctionnel Description mode doit aussi être supporté.

Détermination de compte Détermine les comptes correspondants de Comptabilité pour des Transactions et Sous-Transactions Données

Dossiers Comptables Ce package prend en charge la gestion du Dossier Comptable pour les Entités Fiscales, les Entités Non Fiscales, les Entités Autres

Gestion des Paiements Le système de Gestion des Paiements prend en charge la gestion des paiements dans un mode unifié. Il présente, vis-à-vis de l’ensemble des autres composants une vue unifiée, indépendante du canal financier utilisé (virement, chèque, espèces et, fonction des besoins, paiement électronique (Carte de Débit, Carte de Crédit, …).

Interface Comptable L’interface comptable accepte les « Documents de Calcul » (équivalent de « facture ») qui proviennent de l’Établissement et du Recouvrement non Fiscal et procède à la mise en compte dans le « Dossier Comptable ».

Perception Le package perception prend en charge l’ensemble des fonctionnalités non automatiques de la perception en recettes et en dépenses : il s’appuie bien entendu sur le cadre fourni par la Gestion des Dossiers Comptables et par le Système de Gestion des Paiements.

Reporting

Assure la production des états de contrôle : • Au niveau des dossiers • Au niveau de la centralisation et des compteurs • Au niveau des paiements

Situation de Compte (Serveur)

Fournit un ensemble de services de consultation de comptes à destination de l’Établissement Fiscal et Non Fiscal et du Recouvrement Non Fiscal

4.4.2.2 Une analyse business plus pratique

Chaque dette ou remboursement qui est enregistré ou repris dans FIRST donne lieu à la création de droits.

DROITS POSITIFS

Droits constatés positifs : Chaque droit qui doit être perçu et/ou recouvré via l’application FIRST sera inscrit par le système dans le dossier comptable. À cette fin, un document comptable « Débit » est créé sur la base des données communiquées par « Etablissement ».

Les données de base du droit inscrit peuvent provenir soit d’une application externe à FIRST (p. ex. Calcul IPP), soit du calcul de droits sur la base de l’enregistrement de données dans l’application de FIRST. Lors de l’inscription du droit dans le dossier comptable, le système créera simultanément une communication structurée (CS) et un « paiement à recevoir » afin de permettre l’imputation des paiements ou futurs paiements.

Exemple de tels droits dans FIRST : précompte mobilier, amendes pénales ;

Particularité pour le précompte mobilier : après un certain laps de temps si la dette reste impayée, elle est enrôlée. Pour ce faire, on crée un deuxième « paiement à recevoir » avec la même « communication structurée » qui est lié au premier et identifie le nouveau bureau compétent. En cas de paiement avec communication structurée sur le compte de l’ancien bureau compétent après l’enrôlement, le paiement est automatiquement « transféré » vers le nouveau bureau compétent.


Page 79 sur 149

Droits reçus au comptant Dans le cas de droits au comptant, il ne faut inscrire aucun droit préalablement au paiement et il n’existe aucun titre de recouvrement. Lors de la comptabilisation du paiement effectué en la matière, le principe de la double comptabilité requiert toutefois la création d’une dette dont le montant correspond au paiement reçu. C’est par exemple le cas des versements anticipés où il est procédé comme suit - pour chaque nouveau client VA, une entité VA est créée - en cas de paiement, un paiement à recevoir et une communication structurée auxquels le paiement est affecté sont créés

DROITS CONSTATES NEGATIFS

Inscription d’un droit constaté négatif dans le dossier comptable

a. « Crédit dégrèvement » : cette dénomination s’applique à un crédit contracté dans le cadre d’un litige relatif à une dette déterminée (p. ex. : décision prise dans le cadre d’une réclamation contre une dette Pr.M, dégrèvement Pr.M. résultant d’une déclaration corrigée, nouveau jugement annulant tout ou partie d’un jugement antérieur concernant l’Isoc ou les VA, etc.

b. « Crédit Remboursement » : cette dénomination s’applique à un crédit qui ne peut être lié à une dette déterminée (p. ex. restitution octroyée concernant l'IPP sur la base de la déclaration, crédit TVA déclaré par l'assujetti, etc.)

c. « Crédit annulation » : cette dénomination s’applique à un crédit visant à annuler une dette existante dans le plan comptable. (p. ex. décision d’admission en non-valeur en cas d’insolvabilité, etc.) ; ce type de crédit, qui est toujours lié à une dette, est toujours inscrit à concurrence du solde de la dette à laquelle il est lié et ne donne jamais lieu à un remboursement

À partir de l’inscription d’un « Crédit dégrèvement », « remboursement » ou « annulation », le système cherchera les dettes qui peuvent être utilisées. S’il s’agit d’une imputation d’un « Crédit dégrèvement » ou d’un « Crédit annulation », le système cherchera d’abord les dettes liées.

RECHERCHE DE LA DESTINATION ET DE L’IMPUTATION DES PAIEMENTS

Le système traitera les données financières dès que les données fournies par l’établissement financier auront été reçues via Isagate. Ceci devrait permettre le traitement avant le début de la journée de travail des utilisateurs. Sur la base de ces données, le système créera pour chaque mouvement de crédit un « Paiement reçu » (pour chaque mouvement de débit, un « paiement sortant exécuté » sera également créé). Le but est de pouvoir le lier à un « paiement à recevoir ».

Certaines règles déterminent à présent comment le système va comptabiliser « le paiement reçu ». Les situations les plus fréquentes sont les suivantes :

a) Si, dans la communication du paiement, on trouve une communication structurée qui correspond à celle d’un « paiement à recevoir » ouvert (avec le même compte bénéficiaire), le paiement sera comptabilisé dans le dossier comptable (création document comptable paiement) du débiteur et il sera immédiatement procédé à l’affectation à la dette ; si la dette en question a déjà été payée auparavant, elle ne peut plus être affectée et le paiement aboutit dans le « registre d’attente client »

b) si, dans la communication, un NN ou un ON apparaît, le système comptabilisera aussi le paiement dans le dossier comptable (création document comptable paiement) du client qui correspond à ce numéro. Cela signifie que le paiement aboutit dans le « registre


Page 80 sur 149

d’attente client ». En ce qui concerne le précompte mobilier, une règle spécifique s’applique encore si le montant d’un tel paiement correspond au principal de l’unique dette impayée, il est également procédé à l’affectation à cette dette ;

c) À défaut de communication claire, le paiement ne peut être comptabilisé dans un dossier comptable et il aboutit dans le « registre général d’attente » Un paiement sur le compte des versements anticipés est immédiatement comptabilisé et affecté dans le dossier comptable après la création du paiement à recevoir (et éventuellement de l’entité).

Dans les cas b et c, les paiements devront trouver leur destination via un traitement ultérieur du registre d’attente par les utilisateurs au bureau. Il effectuera les recherches nécessaires et :

- le paiement pourra être imputé sur une dette impayée : le registre d’attente présentera automatiquement les dettes impayées pendant le traitement (dans le cas du registre général d’attente, il faut d’abord chercher le débiteur ou le groupe de débiteurs et sélectionner leur dossier unique)

- à défaut de dettes, il peut également être procédé au remboursement au donneur d’ordre du paiement

- en cas de soldes réduits ou si on n’a toujours pas pu obtenir de destination après un certain laps de temps, le paiement pourra être comptabilisé dans les recettes spéciales

- en cas de dettes auprès d’un autre bureau, le paiement pourra y être transféré

Remarque : il n’est question de « document comptable » que s’il y a un mouvement comptable dans un dossier comptable et que si un paiement laissé à l’AWR a déjà été comptabilisé globalement avec tous les « paiements reçus » au début du traitement du fichier CODA à titre d’« Opération » (= mouvement comptable sans document comptable concerné).

CLOTURES ET RAPPORTS

Tout enregistrement de droits, toute recette et toute comptabilisation de paiements donnent également lieu dans FIRST, outre ce qui est expliqué ci-dessus, à des mouvements comptables sur les comptes GL. Sur la base de la totalisation de mouvements comptables similaires (même compte GL, débit ou crédit, même type de mouvement), des rapports ou clôtures peuvent être générées dans FIRST (p. ex. rapport mouvements financiers). Les totaux susmentionnés de mouvements alimenteront également l’interface avec FEDCOM (voir plus loin).

4.4 .2.3 Produits à réaliser 4.4.2.3.1 Vue globale des Use cases Dans le tableau ci-dessous, on trouve un aperçu des use cases des analyses existantes de FIRST avec leur statut actuel et la stipulation de ce qui reste encore à réaliser dans le cadre du présent cahier des charges.


Page 81 sur 149

Rubrique N° use-case Titre Statut (en bref)

Archivage 08-96 Archivage à analyser et à développer

Dettes contestées et scindées 07-38-14 Modifier un débit à développer

Dettes contestées et scindées 07-38-34-01 Scission d’un PO à analyser et à développer

Dettes contestées et scindées 07-38-35-01 Gérer les dettes scindées et les liens débiteurs à développer

Clôtures 09-01 Clôtures périodiques en production (compléter)

Comptabilisation 07-38-00-01 Inscrire un document comptable en production (compléter)

Comptabilisation 07-38-01-01 Créer un dossier comptable en production

Comptabilisation 07-38-05-01 Attribuer un crédit à un débit en production (compléter)

Comptabilisation 07-38-06-01 Inscrire un crédit en production

Comptabilisation 07-38-07-01 Inscrire un débit en production

Comptabilisation 07-38-08-01 Afficher bilan DU en production (compléter)

Comptabilisation 07-38-13-01 Sélectionner débits et crédits en production

Comptabilisation 07-38-15-01 Use case 07-38-15-01 Mettre un crédit en recette exceptionnelle en production

Comptabilisation 07-38-19-01 Annuler un lien en production

Comptabilisation 07-38-21-01 Chercher un débit en production (corriger)

Comptabilisation 07-38-22-01 Chercher un crédit en production (compléter)

Comptabilisation 07-38-25-01 Créer une communication structurée en production (compléter)

Comptabilisation 07-38-26-01 Solder un débit en production (compléter)

Comptabilisation 07-38-27-01 Imputer un crédit en production (compléter)

Comptabilisation 07-38-28-01 Modifier les imputations en production (corriger)

Comptabilisation 07-38-30-01 Impression du courrier lié au bilan à développer

Comptabilisation 07-38-32-01 Créer un payement en production

Comptabilisation 07-38-33-01 Créer une opération en production

Corrections 07-06-01 Annuler imputation en production (compléter)

Corrections 07-06-03 Modifier la date valeur d'un crédit en production (compléter)

Corrections 07-06-06 Corriger des frais en production

Corrections 07-06-07 Retrait de crédits du RE en production (compléter)

Gestion Echéances 06-03 Gérer un titre exécutoire en production (compléter)

Gestion Echéances 06-03-01 Valider un titre exécutoire en production (compléter)

Gestion Echéances 07-06-02 Suspendre le calcul des intérêts de retard à développer

Gestion Echéances 07-21 Contrôler les échéances en production (compléter)

Gestion Echéances 07-30 Calculer la dette (intérêts de retard) en production (compléter)

Gestion Echéances 07-30-01 Calculer la dette CD en production (compléter)

Gestion Echéances 07-30-05 Calculer la dette AC à développer

Gestion Echéances 07-30-06 Calculer la dette TD à développer

Gestion Echéances 07-38-24 Ajouter un titre exécutoire en production (compléter)

Institution financière 07-16 Traiter les données transmises par l'institution financière en production

Institution financière 07-33 Consulter les données de l'institution financière en production

Paramètres 07-38-90-01 Gestion des paramètres en production (compléter)

Réception payement 07-18-01 Rechercher la destination d'un payement en production

Réception payement 07-18-02 Traiter registres d'attentes en production (compléter)

Réception payement 07-18-03 Suivi registres d'attente à développer

Réception payement 07-18-04 Attribution de crédits pour traitement à développer

Remboursement 08-03-01 Calcul du montant définitif IM à analyser et à développer

Remboursement 08-08 Evaluer une proposition d'un remboursement en production (compléter)

Remboursement 08-10 Exécuter les virements en production (compléter)

Remboursement 08-17 Traiter des montants à rembourser en production (compléter)

Remboursement 08-19 Liquidation des frais aux ayants droits en production

Remboursement 08-20 Suivi débit compte bancaire en production (compléter)

Remboursement 30-06 Consulter saisie-cession à développer

VA 02-06-10 Joindre des informations VA au dossier unique en production

VA 02-17-17 Rédiger liste des entités pour les versements en production

VA 07-01-01 Demande de remboursement ou de report VA en production

VA 07-02-01 Traitement d'une demande de remboursement ou de report VA en production

VA 07-07 Envoi automatique des extraits de compte en production

VA 07-11 Envoi automatique d'une invitation à payer VA en production

VA 07-87 Traitement d’une modification à la date du bilan en production

VA 07-88 Gestion envoi VA en production

VA 07-89 Gestion dossier VA en production

VA 07-90 Traitement des VA non consommés par Taxation en production

VA 07-90-01 Traitement des VA non consommés par le service VA en production

VA 07-90-02 Contrôle des VA consommés en production


Page 82 sur 149

Explication de la colonne ‘statut’ : - À analyser et à développer : il n’existe encore aucune analyse pour FIRST

- À développer : il existe une analyse qui doit éventuellement être actualisée

- En production : actuellement en production (une éventuelle actualisation relative aux nouvelles dettes à traiter est possible)

- En production (compléter) : partiellement développé, certaines fonctionnalités du use case manquent encore (une éventuelle actualisation relative aux nouvelles dettes à traiter est possible)

- En production (corriger) : développé, mais certaines fonctionnalités ne fonctionnent pas correctement (une éventuelle actualisation relative aux nouvelles dettes à traiter est possible)

- En production (contrat actuel) : sera en production après le contrat actuel (une éventuelle actualisation relative aux nouvelles dettes à traiter est possible)

- En production (interne) : actuellement développé en interne (une éventuelle actualisation relative aux nouvelles dettes à traiter est possible)

- 4.4.2.3.2 Produits à réaliser par use case Remarque préalable : Nous ne reprenons ci-dessous aucun use case ayant l’un des statuts suivants dans le tableau susmentionné : en production . Là où cela s’avère nécessaire, ces use cases devront être actualisés par l'impact que l’« intake générique » et le « moteur générique de recouvrement » peuvent avoir sur eux.

Archivage • UC 08-96 Archivage : À analyser et à développer

L’archivage des débits et crédits dans la base de données n’est actuellement pas prévu et sera nécessaire vu le volume des nouvelles dettes.

Dettes contestées et scindées • UC 07-38-14 Modifier un débit : À développer

Modifier les données de la dette existante et, si nécessaire, adapter les imputations (p. ex. en ce qui concerne les NR) suite à une contestation de la taxation. L’analyse a déjà été actualisée pour les dettes aux contributions directes.

• UC 07-38-34-01 Scission d’un ‘Poste ouvert’ : À analyser et à développer

Modification du statut d'une (partie d’une) dette (p. ex. En cas de remise partielle de la dette contestée). Découle du précédent UC.

• UC 07-38-35-01 Gérer les dettes scindées et les liens débiteurs : À développer

Scission de dettes entre plusieurs débiteurs (p. ex. héritage, séparation de biens, …).

Clôture • UC 09-01 Clôtures périodiques : Autres clôtures et rapports encore à développer

Clôtures périodiques de recettes et dépenses, et établissement de rapports comptables. Pour l’heure, uniquement un rapport pour les opérations financières (sera corrigé dans le contrat actuel).


Page 83 sur 149

Comptabilisation • UC 07-38-00-01 Inscrire un document comptable : À compléter et à développer plus

avant

Les documents comptables sont inscrits à paiements reçus et paiements sortants, à inscription et exonération de droits, à remboursements et à annulations. Est partiellement en production et l’analyse est actualisée pour ICPC et devra encore être adaptée à la lumière de ‘l’intake générique’.

• UC 07-38-05-01 Attribuer un crédit à un débit : À compléter et à développer plus avant (notamment pour ce qui concerne les dettes d’un dossier unique impliquant plusieurs personnes)

Imputation de crédits sur des débits p. ex. En cas de paiement, mais aussi en cas de compensation dans un document comptable, détail du fonctionnement des postes ouverts, des affectations, des mouvements sur les comptes GL ; compte tenu également d’éventuels mouvements de transfert entre différents dossiers comptables. L’analyse a été actualisée pour ICPC

• UC 07-38-08-01 Afficher bilan DU : À compléter et à développer plus avant : notamment les nouveaux onglets et suppression de la limitation par pilier et secteur au sein de l’AGPR

Consulter (les détails de) l’ensemble des dettes et avoirs (paiements non comptabilisés, remboursements en cours), les versements anticipés de tous les dossiers comptables liés à une personne : - de son propre dossier - de dossiers d’un groupe de personnes auquel appartient la personne consultée L’analyse a été actualisée pour ICPC et prévoit des onglets supplémentaires pour la correspondance, les contestations et l’historique qui ne sont pas encore développés

• UC 07-38-21-01 Chercher un débit : A améliorer : suppression des limites par pilier et secteur au sein de l’AGPR

Recherche d’un débit = dette (voir fonction chercher débit - crédit) • UC 07-38-22-01 Chercher un crédit : À développer plus avant : les crédits manquants

+ suppression des limites par pilier et secteur au sein de l’AGPR

Recherche d’un crédit (voir fonction chercher débit - crédit) : 4 possibilités (paiement, versement anticipé, remboursement, dégrèvement). N’est en production que pour ce qui concerne les paiements UC 07-38-25-01 Créer une communication structurée : A développer plus avant (réservation de CS pour les dettes ICPC, etc.) Génération et attribution d’une communication structurée (pour la création d’un paiement à recevoir). Analyse détaillée pour ICPC.

• UC 07-38-26-01 Solder un débit : À compléter et à développer plus avant (règles spécifiques par type de dettes)

Lors de l’inscription d’une dette (débit), utiliser automatiquement des crédits disponibles sur celle-ci (p. ex. en cas de paiements rentrants avant la déclaration ou en cas d'enrôlement de l’imputation automatique des paiements qui ont été réservés dans l'attente de l'enrôlement).

• UC 07-38-27-01 Imputer un crédit : À développer plus avant et à revoir

Use case très détaillé pour l’imputation automatique d’un crédit sur une dette (et ses dettes liées comme des suppléments, VK et NR), avec les règles dites de la 'moulinette'. Utilisé lors


Page 84 sur 149

de la comptabilisation des codas et dans le cadre des propositions en cas d’imputation à partir du registre d’attente. Après l’exécution de ce UC, une dette est comptabilisée sur la dette soit dans le WR client, soit dans l'AWR. Analyse déjà actualisée pour ICPC. N’est que partiellement en production, il faut vérifier s’il est opportun de développer toutes les règles prévues, surtout à présent qu’il y aura une extension à diverses autres dettes.

• UC 07-38-28-01 Modifier les imputations : À développer plus avant et à revoir

Ce use case est appelé si une imputation sur une dette doit être modifiée (p. ex. en cas d’annulation, en cas de modification de la date valeur avec un recalcul des intérêts pour conséquence, en cas de comptabilisation d’un dégrèvement, en cas de comptabilisation d’un paiement préalablement à des paiements déjà comptabilisés sur la dette) et est exécuté automatiquement dans certains cas. L’analyse a été actualisée pour ICPC. Vu que la mise en production de ce UC n’a jamais complètement réussi, une révision complète s’avère nécessaire.

• UC 07-38-30-01 Impression du courrier lié au bilan : À développer

L’impression de certaines lettres à partir des écrans du ‘bilan’, comme par exemple des relevés de dettes, la situation d’une dette déterminée, le détail d’imputations de paiements, …

Corrections

• UC 07-06-01 Annuler imputation : À développer plus avant L’annulation d’une imputation d’un paiement, d’un remboursement ou d’un versement anticipé à restituer. En cas de paiement, également possibilité de transfert vers l’AWR.

• UC 07-06-03 Modifier la date valeur d’un crédit : À compléter et à développer plus avant

Modifier la date valeur d’un paiement (p. ex. paiement de l'huissier de justice pour plusieurs dossiers comportant différentes données, paiement provenant de la retenue de la restitution) plus éventuelle révision d’intérêts, de frais de poursuites, de dates de prescription et d’autres paiements sur la dette qui en sont impactés. Partiellement en production.

• UC 07-06-07 Retrait de crédits des ‘Recettes spéciales’ : À développer plus avant (voir ci-dessus)

Annulation de paiements qui ont été comptabilisés dans les recettes spéciales. Pas encore développé pour les comptabilisations dans les recettes spéciales à partir du registre général d’attente.

Gestion Échéances • UC 06-03 Gérer un titre exécutoire : À développer plus avant (pour les nouveaux

types de dettes, ICPC et autres)

La création d’un titre exécutoire sous la forme d’un rôle pour les impôts prélevés à la source qui sont restés impayés. À l’heure actuelle, seulement partiellement en PROD pour Pr.M. Analyse actualisée pour ICPC.

• UC 06-03-01 Valider un titre exécutoire : À développer plus avant (pour les nouveaux types de dettes, ICPC et autres)

Impression des rôles et déclaration au système qu’ils sont exécutoires + blocage paiement pendant la procédure d’enrôlement. À l’heure actuelle, seulement partiellement en PROD pour Pr.M. Analyse actualisée pour ICPC.

• UC 07-06-02 Suspendre le calcul des intérêts de retard : À développer


Page 85 sur 149

Suspension du calcul des intérêts pour certaines périodes (p. ex. Faillite, RCD, réclamation). • UC 07-21 Contrôler les échéances : À développer plus avant (pour les nouveaux


Ce workflow comprend notamment le contrôle des échéances, l’établissement de rappels, l’enrôlement et la transmission à ‘recouvrement’. Sera développé dans le contrat actuel. Analyse actualisée pour ICPC.

• UC 07-30 Calculer la dette (Intérêts de retard) : À compléter et à développer plus avant

Use case général pour le calcul des intérêts sur une dette. • UC 07-30-01 Calculer la dette Contributions Directes (Intérêts de retard) : À

compléter et à développer plus avant (ICPC, suspension, cas spécifiques))

Use case pour le calcul des intérêts de retard contributions directes. Actuellement uniquement pour Pr.M. L’analyse a été actualisée pour ICPC

• UC 07-30-05 Calculer la dette Autres Créances Non-Fiscales (Intérêts de retard) : À développer

Use case pour le calcul des intérêts de retard sur les autres créances non fiscales. • UC 07-30-06 Calculer la dette Taxes Diverses (Intérêts de retard) : À développer

Use case pour le calcul des intérêts de retard sur diverses taxes. • UC 07-38-24 Ajouter un titre exécutoire : À développer plus avant (pour les nouveaux


détermination de la signature proprement dite, validation et signature du rôle, cession des droits et comptabilisation du paiement bloqué. Analyse actualisée pour ICPC.

Paramètres • UC 07-38-90-01 Gestion des paramètres : À compléter et à développer plus avant

(notamment pour les comptes GL et leur durée de validité)

Modification, ajout ou suppression de paramètres (p. ex. taux et codes Pr.M). Un nombre limité de paramètres sont ajoutés dans le contrat actuel

Réception payement • UC 07-18-01 Rechercher la destination d’un paiement : (Eventuellement) à

développer plus avant (en ce qui concerne le numéro de compte)

Recherche de la destination du paiement sur la base de la CS, communication libre comprenant CS ou NN ou NE, sur la base du numéro de compte. Non développé pour ce qui concerne le numéro de compte.

• UC 07-18-02 Traiter les registres d’attente : À compléter et à développer plus avant (voir ci-dessus)

Traitement des paiements qui n’ont pas pu être immédiatement comptabilisés en recette. Registre d’attente client : le paiement a déjà pu être attribué à un dossier unique ; registre général d’attente : le paiement n’a pas encore pu être attribué à un dossier unique. Un certain nombre de fonctionnalités manque encore, comme : transfert pour dettes autres bureaux, scission du paiement pour imputation sur différents dossiers uniques, remboursement via assignation, …

• UC 07-18-03 Suivi des registres d’attente : À analyser et à développer


Page 86 sur 149

Suivi (automatique) du registre d’attente pour éviter que certains crédits restent bloqués trop longtemps dans le registre d’attente.

• UC 07-18-04 Attribution de crédits pour traitement : À développer

Attribution de crédits à certains utilisateurs pour traitement pour éviter un double traitement : vise le traitement du registre d’attente dans les grands bureaux (actuellement, un traitement simultané par plusieurs utilisateurs n’a pas été bloqué, ce qui peut entraîner des problèmes).

Remboursement • UC 08-03-01 Calcul du montant définitif d’Intérêts Moratoires : À développer

Nouveau use case pour le calcul des intérêts moratoires sur les montants à restituer. • UC 08-08 Evaluer une proposition d’un remboursement : À compléter et à développer

plus avant (voir ci-dessus)

Use case spécifique pour la validation de certains concepts comme les remboursements du registre d’attente, les intérêts moratoires, les propositions relatives aux versements anticipés : n’est actuellement en production que pour les remboursements à partir du registre d'attente.

• UC 08-10 Exécuter les virements : À compléter et à développer plus avant (notamment pour ce qui concerne les véritables restitutions comme l’impôt des personnes physiques, la consultation préalable des saisies et cessions, etc. …)

Exécution des remboursements (comme le remboursement de l'impôt des personnes physiques ou du montant payé en trop à partir du registre d’attente), virement Trésor, versements anticipés à rembourser ... L’analyse a été actualisée pour les remboursements ICPC (p. ex. Impôt des personnes physiques)

• UC 08-17 Traiter des montants à rembourser : À compléter et à développer plus avant (notamment pour ce qui concerne les véritables restitutions comme l’impôt des personnes physiques)

Traitement des remboursements (comme le remboursement de l'impôt des personnes physiques ou du montant payé en trop à partir du registre d’attente), virement Trésor, versements anticipés à rembourser ... L’analyse a été actualisée pour les remboursements ICPC (p. ex. Impôt des personnes physiques)

• UC 08-20 Suivi débit compte bancaire : À compléter et à développer plus avant (notamment pour ce qui concerne les véritables restitutions comme l’impôt des personnes physiques)

Contrôle des débits du compte pour déterminer s’ils peuvent être liés à un paiement à exécuter.

• UC 30-06 Consulter saisie-cession : À développer

Vérifier s’il y a eu saisie ou cession avant de rembourser quelque chose et, si oui, annuler le remboursement et générer un ‘ToDo'. Analyse actualisée pour ICPC. 4.4.2.4 Interface Fedcom GL

FEDCOM est un ERP mis en place dans le but de gérer la comptabilité et le contrôle financier de l'État fédéral.


Page 87 sur 149

Objectif de l’interface :

En exécution de la Loi du 22 mai 2003 portant organisation du budget et de la comptabilité de l'Etat fédéral, FEDCOM a introduit entre autres la comptabilité en partie double et l'enregistrement des dépenses et des recettes sur base de droits constatés, c'est-à-dire, sur base de transactions et non plus sur base de caisse.

Dès lors, il convient de développer une interface entre FIRST et FEDCOM se basant sur des échanges de fichiers xml pour charger:

1. les droits constatés fiscaux et non-fiscaux, 2. les recettes fiscales et non-fiscales, 3. les remboursements ou restitutions aux ayants-droits.

Étant donné qu’il s’agit de ‘grandes’ quantités d’opérations individuelles, ces détails ne seront pas intégralement repris dans FEDCOM. Mais il sera procédé à une comptabilisation globale sur une base périodique (fréquence journalière ou mensuelle). Les éventuels remboursements à des clients seront directement effectués à partir de FIRST (FEDCOM ne tient aucun détail de clients). Ces comptabilisations seront périodiquement enregistrées au niveau global dans FEDCOM.

Bank RAG RAC Droit

Clôture quotidienne Clôture mensuelle

FEDCOM

Flux d’écriture comptable de FIRST vers. FEDCOM


Page 88 sur 149

4.4 .3 TRANCHE 3 : « Module générique de recouvreme nt »

4.4 .3.1 Le processus de recouvrement

Description générale du P031 – Recouvrement Ce processus comprend l'exécution d'une série de procédures dans le but de récupérer rapidement et efficacement les impôts, droits, taxes, dettes douanières, amendes et accessoires, etc., dus à l'Etat fédéral, aux autres autorités publiques et à certains autres ayants droit. Il vise également à inciter les citoyens au respect de leurs obligations, à la mise en œuvre d'actions judiciaires à l'encontre de redevables ou de tiers défaillants et à la défense de l'administration dans les contestations judiciaires dirigées contre des actions de recouvrement. Dans le processus P31, un ensemble d’actions sont conduites pour obtenir le paiement d’une dette là où les procédures largement automatisées de la perception ont rencontré leurs limites. Par exemple : des droits ont été constatés et les paiements n’ont pas été faits en regard de ces droits ; des lettres de rappel et des sommations ont été envoyées, sans résultat, - soit que le client ne voulait pas payer, soit qu’il n’était pas en mesure de payer. Le processus P31 doit donc s’appuyer sur une approche structurée mais largement discrétionnaire : le gestionnaire du dossier de recouvrement évalue la situation – notamment en consultant la fiche de solvabilité – et choisit l’action de recouvrement qui lui paraît la plus appropriée. Cette action doit conduire à une réaction de la part du débiteur. En fonction de cette réaction - ou de son absence dans des délais définis – une nouvelle action peut être décidée. Ce cycle ‘action – réaction’ se répète autant de fois que nécessaire pour obtenir le recouvrement partiel ou complet, ou au contraire acter la nécessité d’arrêter les actions et demander à être déchargé du recouvrement de la dette (action en suspension de recouvrement).


Page 89 sur 149

a. Schéma P031_Recouvrement

Mapping des activités de P031 et UC 31 : 1. P031.AB01 Choix et analyse d’un dossier de dette

• UC 31-03 Distribution automatique de dossiers

• UC 31-44 Désignation de fonctionnaire chargé traitement info reçues

• UC 31-61 Désigner manuellement agent chargé de traiter info reçue

• UC 31-52 Sélection de dossiers

• UC 31-63 Consultation d’une fiche de solvabilité

• UC 31-64 Prendre une photo de la fiche de solvabilité

• UC 31-89 Chercher des dossiers

• UC 31-91 Demandes de renseignements concernant la solvabilité (demande enquête de police (amende pénale))

• UC 31-97 Etablissement d’un dossier de recouvrement permanent

2. P031.AB02 Création d’un titre exécutoire

• UC 31-94 Contrôle des demandes de contrainte

a) P031.AB03 Envoi d’une sommation/notification (recommandée) • UC 31-07 Enregistrement d’actes et de coûts (traitement

automatique des notes de frais) • UC 31-22 Enregistrement manuel d’actes et de coûts

(traitement manuel des notes de frais)


Page 90 sur 149

• UC 31-30 Créer manuellement des sommations recommandées

• UC 31-42 Créer automatiquement des sommations recommandées

b) P031.AB05 Attribution d’un dossier à l’huissier de justice • UC 31-93 Préparer visa contrainte • UC 31-23 Poursuite attribution à un huissier de justice • UC 31-33 Demande d’autorisation de saisie immobilière • UC 31-07 Enregistrement d’actes et de coûts (traitement

automatique des notes de frais) • UC 31-22 Enregistrement manuel d’actes et de coûts

(traitement manuel des notes de frais)

3. P031.AB04 Traiter la demande d’un plan d’apureme nt

• UC 31-04 Octroi de facilités de paiement

4. P031.AB06 Recouvrement simplifié chez un tiers/n otaire

• UC 31-24 Notifications à des notaires

• UC 31-53 Notification vente publique

• UC 31-37-01 Saisie-arrêt simplifiée

• UC 31-37-02 Envoyer une notification de délégation de sommes

• UC 31-79 Envoyer une proposition de cession volontaire

• UC 07-38-31 Renouvellement d’un avis de saisie

• UC 31-07 Enregistrement d’actes et de coûts (traitement automatique des notes de frais)

• UC 31-22 Enregistrement manuel d’actes et de coûts (traitement manuel des notes de frais)

5. P031.AB07 Traitement de dossiers de justice offe nsifs, IH, opposition

à la division, …

• UC 31-10 Fourniture d’un avis juridique

• UC 31-16 Traitement de dossiers judiciaires

• UC 31-38 Inscription hypothécaire

• UC 31-07 Enregistrement d’actes et de coûts (traitement automatique des notes de frais)

• UC 31-22 Enregistrement manuel d’actes et de coûts (traitement manuel des notes de frais)

• UC 31-95 Etablissement d’une fiche d’avocats

• UC 07-38-29 Gérer les contestations sur des actions

6. P031.AB08 Demander une assistance au recouvremen t

• UC 31-56 Recouvrement international

7. P031.AB09 Traitement d’une dette (temporairement ) non recouvrable


Page 91 sur 149

• UC 31-11-01 Examen des propositions de suspension du recouvrement

• UC 31-11-02 Suite de la suspension annulation avant prescription

• UC 31-12 Décision d’autorisation de suspension

• UC 31-27 Proposition manuelle de demande en suspension

• UC 31-60 Proposition automatique de demande en suspension

• UC 31-90 Enregistrement de la décision de suspension (Demande de surséance indéfinie et d’exonération NR)

• UC 31-98 Suspension ou exonération intérêts de retard

8. P031.AB10 Suivi du dossier

• UC 31-09-01 Interruption de la prescription

• UC 31-09-02 Calculer la prescription

• UC 31-09-04 Suivi interruption de la prescription

• UC 31-09-05 Encoder un acte interruptif de prescription

• UC 31-09-06 Produire un Etat 204

• UC 31-09-07 Radier un jugement

• UC 31-19 Traitement des frais, dédommagements et intérêts dus à l’Etat

• UC 31-20 Contrôle des actions interruptives de la prescription

• UC 31-21 Traitement des dossiers responsabilité du comptable

• UC 31-28 Déclaration de créance

• UC 31-31 Droits du Trésor menacés

• UC 31-32-01 Apurement des soldes minimes

• UC 31-32-02 Apurement des soldes à ne pas recouvrer

• UC 31- 35 Sommation pour plan d’apurement

• UC 31-36 Scission des dettes

• UC 31-39 Evaluation et approbation d’un concept

• UC 31- 43 Cessation des plans d’apurement

• UC 31-45 Modification manuelle du statut de la dette

• UC 31-46 Attestation de cession de fonds de commerce

• UC 31-47 Réactions après le paiement de la dette dans les poursuites

• UC 31-49 Nouvelle attribution de dossiers

• UC 31-50 Mainlevée à la demande d’une partie intéressée

• UC 31-51 Suivi automatique des dossiers

• UC 31-54 Suivi manuel de dossiers

• UC 31-57 Reconnaissance de dette

• UC 31-58 Réexpédition automatique du courrier

• UC 31-59 Renvoi manuel de la correspondance

• UC 31-62 Traitement des frais, dédommagements et intérêts dus par l’Etat

• UC 31-65 Modification des privilèges

• UC 31-69 Création d’une action de recouvrement vide


Page 92 sur 149

• UC 31- 77 Clôture du dossier (établissement) et renvoi au demandeur

• UC 31-80 Gestion des paramètres du recouvrement

• UC 31-81 Statistiques et rapports en matière de recouvrement

• UC 31-88 Statistiques et rapports en matière de contentieux

• UC Xx-99 Gestion des paramètres

Le P031 et le dossier de recouvrement

Au sein du processus P031, le dossier de recouvrement peut être organisé en phases logiques :

• Introduction (Signal) • Examen • Décision (Action de recouvrement via moteur générique) • Suivi • Clôture

L’élément déclencheur de la constitution du Dossier de Recouvrement est la présence de dettes non payées. Le dossier est établi au niveau d’un bureau de recouvrement concerné habilité à gérer un ou plusieurs types de dettes en recouvrement. On peut ainsi avoir plusieurs dossiers de recouvrement ouverts pour une même personne. Le dossier est ensuite examiné par le gestionnaire qui va dans un premier temps demander / consulter la fiche de solvabilité afin de choisir une stratégie de recouvrement appropriée à la situation du client. Cette fiche de solvabilité intègre d’une part des informations qui sont maintenues à jour par différents systèmes accessibles en ligne et d’autre part des informations qui ont été collectées par différents moyens manuels (enquête, correspondance) et inscrites dans le Dossier Permanent de Recouvrement de la personne. La stratégie de recouvrement se matérialise par une décision qui porte sur le choix d’une action de recouvrement. Une action de recouvrement attend une réaction (ou un événement) dans un délai fixé. • Certaines actions ou événements peuvent conduire à une interruption ou

une suspension de la prescription. • Dans le cas d’une solvabilité insuffisante, l’action peut être d’un type

particulier : la suspension du recouvrement, qui acte le caractère irrécouvrable (à titre provisoire ou indéfini) de la dette. Lorsque l’insolvabilité définitive est actée, une proposition d’annulation comptable du droit est émise.

• Selon son type, une action peut ou non impliquer des prestataires de services externes comme, par exemple, des huissiers. Dans ce cas, des frais peuvent être associés à l’action (ou à un ensemble d’actions) ces frais doivent être gérés.

• Enfin, une action de recouvrement peut également donner lieu à un contentieux administratif ou judiciaire. Par convention, le contentieux judiciaire en recouvrement a reçu l’appellation contentieux civil.

• Toutes ces actions sont initiées à partir d’un moteur générique d’actions de recouvrement.


Page 93 sur 149

Action générique de recouvrement

Le moteur générique d’actions de recouvrement fera partie du module «Recovery » de First. Il permettra d’initier des actions de recouvrement de la façon la plus générique possible à l’encontre du débiteur via un envoi électronique vers une autre application, interne (via Fedopress, … : p. ex. envoi au débiteur) ou externe au SPF Finances (vers un huissier,…).

Schéma :

Fig. Vue globale du programme First

Ce module générique comprend • les données nécessaires pour pouvoir lancer le recouvrement : Toutes

les actions de recouvrement envers un débiteur se basent sur le même type de données :

Etablissement

(déclaration, input,

demande)

Création du

document comptable

Avis de

paiementDette impayée Signal

Dossier de

recouvrement

Sélectionner

une action

Initier une

action

Moteur générique

RECOUVREMENT


Page 94 sur 149

� signalétique complète du débiteur (via lien SITRAN) : Identification et Etat

• Données personnelles • Etat civil • Adresses – adresse du domicile • …

� la dette • Type Nature • Montant total • Statut • …

� les informations liées au paiement • numéro de compte IBAN, • communication à utiliser, • …

• liens vers d’autres applications en vue de l’enquête sur la solvabilité du débiteur concerné

o Si possible, travailler avec des liens dynamiques (les liens s’affichent si la personne concernée a des dettes).

o Exemples : � Recherche BCSS � Belcotax-on-Web (BOW) � ConsultImmo � DIV � Stirint (voir p. ex. les données relatives à des biens

immobiliers étrangers) Il existe déjà un service web. Le but consiste à établir des liens avec ces applications.

Des actions doivent pouvoir être lancées à partir du dossier de recouvrement sur la base des données connues. Le module générique extrait les données de base, nécessaires à l’action à entreprendre, et les affiche, spécifiquement pour l’envoi papier (via Fedopress) ou électronique (service web ou autre application électronique). Chaque dossier de données (voir données de base) est actualisé au quotidien sur la base des fichiers de paiement.


Page 95 sur 149

Cette fonctionnalité devra prévoir l’ajout ultérieur d’autres types d’actions de recouvrement ou de modifier, si nécessaire, les existantes moyennant un ensemble de paramètres prédéfinis.

Dossier de recouvrement

Sélection action

Envoi papier ou

électronique

Adaptation dossier de recouvrement -

output (électronique ou manuel)

TraitementInput manuel

ou électronique

Moteur générique: Action générique de recouvrement

Moteur générique: Gestion des retours


Page 96 sur 149

Principe : Moteur générique :

Recherchez données de base

La sélection des actions de recouvrement passe par un menu déroulant : le module générique extraira (de façon dynamique) les données, nécessaires à cette action, des dossiers de données. Sur la base de l’action sélectionnée, le moteur sait s’il s’agit d’un envoi papier ou électronique.

Packages fonctionnels Recouvrement

La découpe fonctionnelle en packages soutient le processus de gestion présentés ci-avant :

• Gestion des dossiers de recouvrement • Gestion des actions de recouvrement • Gestion des prescriptions • Gestion des frais

Data records

NN Nom Adresse ... ... ... ...

Actions: Mission huissier

Déclaration de créance

Saisie

Demande en décharge

...

Papier

Electronique


Page 97 sur 149

Package fonctionnel Description Gestion des dossiers de recouvrement

La gestion de dossier est prise ici au sens de la gestion de l’introduction et de l’examen du dossier. Les éléments clé de cette gestion sont la constitution, la prise en charge du dossier par un gestionnaire du dossier et l’examen du dossier qui implique notamment la demande et consultation de la fiche de solvabilité

Gestion des actions de recouvrement

La gestion des actions de recouvrement couvre le cœur du métier selon le modèle actions – réactions.

Gestion des prescriptions et calcul du nouveau délai

Regroupe les fonctions de gestion de la prescription pour l’interruption ou la suspension de celle-ci.

Gestion des frais Regroupe l’ensemble des fonctions liés à la gestion des frais depuis l’engagement de ceux-ci (choix du prestataire) jusqu’au traitement de ceux-ci (notes de frais).


Page 98 sur 149

b. Sélection des actions de recouvrement selon les packages fonctionnels

Rubriek Activiteit P031 - Process -UseCase-SubCase Titel Current status Manueel Electronisch

Gestion des dossiers 31-00 Common screens Recouvrement En producti on

Gestion des dossiers P031.AB01 - 31-03 Automatisch verdelen van dossiers A analyser et à dével opper x

Gestion des dossiers P031.AB01 - 31-44 Désignation fonctionnaire chargé traitement info reçues A analyser et à dével opper x

Gestion des dossiers P031.AB10 - 31-49 Opnieuw toekennen van dossiers A analyser et à dével opper x

Gestion des dossiers P031.AB10 - 31-51 Suivi automatique des dossiers A développer x

Gestion des dossiers P031.AB01 - 31-52 Selecteren van dossiers A analyser et à dével opper x

Gestion des dossiers P031.AB10 - 31-54 Manueel opvolgen van dossiers A développer x

Gestion des dossiers P031.AB10 - 31-58 Réexpédition automatique du courrier A analyser et à dével opper x

Gestion des dossiers P031.AB10 - 31-59 Manuele herverzending van correspondentie A analyser et à dével opper x

Gestion des dossiers P031.AB01 - 31-61 Désigner manuellement agent chargé de traiter info reçue A analyser et à dével opper x

Gestion des dossiers P031.AB01 - 31-63 Consulteren van Solvabiliteitsfiche En production et à ada pter x

Gestion des dossiers P031.AB01 - 31-64 Nemen van foto van de solvabiliteitsfiche A analyser et à dével opper x

Gestion des dossiers P031.AB01 - 31-89 Dossiers opzoeken A analyser et à dével opper x

Gestion des dossiers P031.AB01 - 31-97 Opstellen Permanent invorderingsdossier En producti on x

Actions de recouvrement P031.AB10 - 31-80 Beheer van parameters invordering A analyser et à dével opper

Actions de recouvrement P031.AB04 - 31-04 Toekennen van betalingsfaciliteiten En production et à ada pter x x

Actions de recouvrement P031.AB10 - 31-09-07 Radier un jugement A analyser et à dével opper x

Actions de recouvrement P031.AB09 - 31-11-01 Examen des propositions de suspension du recouvrement A analyser et à dével opper x

Actions de recouvrement P031.AB09 - 31-11-02 Suite de la suspension annulation avant prescription A analyser et à dével opper x

Actions de recouvrement P031.AB09 - 31-12 Beslissing van toelating voor opschorting A analyser et à dével opper x

Actions de recouvrement P031.AB05 - 31-23 Vervolging toewijzing aan een gerechtsdeurwaarder / Opdracht voor een gerechtsdeurwaarder En production et à ada pter x

Actions de recouvrement P031.AB06 - 31-24 Notificaties aan notarissen A analyser et à dével opper x

Actions de recouvrement P031.AB10 - 31-25 Toepassing art. 393bis, WIB92 ingebrekestelling belast echtgeno(o)te A analyser et à dével opper x

Actions de recouvrement P031.AB10 - 31-26 Toepassing art.393bis, WIB92 Tweede aanslagbiljet A analyser et à dével opper x

Actions de recouvrement P031.AB09 - 31-27 Manueel voorstel tot verzoek om opschorting /Manueel voorstel tot annulatie van een schuld A analyser et à dével opper x

Actions de recouvrement P031.AB10 - 31-28 Verklaringen van schuldvordering / Aangifte van schuldvordering A analyser et à dével opper x

Actions de recouvrement P031.AB03 - 31-30 Manueel creëren van aangetekende aanmaningen A analyser et à dével opper x

Actions de recouvrement P031.AB10 - 31-31 Rechten van de Schatkist in gevaar A analyser et à dével opper x

Actions de recouvrement P031.AB10 - 31-32-01 Aanzuivering van geringe saldi A développer x

Actions de recouvrement P031.AB10 - 31-32-02 Apurement des soldes à ne pas recouvrer A développer x

Actions de recouvrement P031.AB05 - 31-33 Demande d'autorisation de saisie immobilière A analyser et à dével opper x

Actions de recouvrement P031.AB10 - 31-35 Sommation pour plan d'apurement En production et à ada pter x

Actions de recouvrement P031.AB10 - 31-36 Splitsing van schulden A développer x

Actions de recouvrement P031.AB06 - 31-37-01 Vereenvoudigd derdenbeslag A développer x

Actions de recouvrement P031.AB06 - 31-37-02 Envoyer une notification de délégation de sommes A développer x

Actions de recouvrement P031.AB07 - 31-38 Hypothecaire inschrijving A analyser et à dével opper x

Actions de recouvrement P031.AB03 - 31-42 Créer automatiquement des sommations recommandées A analyser et à dével opper x

Actions de recouvrement P031.AB10 - 31-43 Stopzetten van betalingsplannen A développer x

Actions de recouvrement P031.AB10 - 31-45 Manueel wijzigen van het statuut van de schuld En producti on x

Actions de recouvrement P031.AB10 - 31-46 Attest overdracht van handelsfondsen A analyser et à dével opper x

Actions de recouvrement P031.AB10 - 31-47 Reacties na betaling schuld in vervolging A développer x

Actions de recouvrement P031.AB10 - 31-50 Handlichting op verzoek van een geïnteresseerde partij A développer x

Actions de recouvrement P031.AB06 - 31-53 Notificeren openbare verkoop A analyser et à dével opper x

Actions de recouvrement P031.AB08 - 31-56 Internationale invordering A analyser et à dével opper x

Actions de recouvrement P031.AB10 - 31-57 Schulderkenning A analyser et à dével opper x

Actions de recouvrement P031.AB09 - 31-60 Automatisch voorstel tot verzoek om opschorting A analyser et à dével opper x

Actions de recouvrement P031.AB10 - 31-65 Modification des privilèges A analyser et à dével opper

Actions de recouvrement P031.AB10 - 31-69 Aanmaken lege invorderingsactie / Registratie verjaringstuitende of -schorsende akte A développer x

Actions de recouvrement P031.AB10 - 31-77 Clôture du dossier (établissement) et renvoi au demandeur A analyser et à dével opper x

Actions de recouvrement P031.AB06 - 31-79 Envoyer une proposition de cession volontaire A analyser et à dével opper x

Actions de recouvrement P031.AB10 - 31-81 Statistieken en rapporten invordering A analyser et à dével opper x x

Actions de recouvrement P031.AB09 - 31-90 Registeren beslissing opschorting /Aanvraag onbeperkt uitstel en vrijstelling NI A analyser et à dével opper x

Actions de recouvrement P031.AB01 - 31-91 Demande enquête de police (amende penale) /Vragen om inlichtingen inzake solvabiliteit A développer x

Actions de recouvrement P031.AB05 - 31-93 Voorbereiden visum dwangbevel A analyser et à dével opper x

Actions de recouvrement P031.AB02 - 31-94 Controle van aanvragen voor dwangbevel A analyser et à dével opper x

Actions de recouvrement P031.AB09 - 31-98 Schorsing of Vrijstelling nalatigheidsintresten A analyser et à dével opper

Actions de recouvrement P031.AB06 - 07-38-31 Renouvellement d'un avis de saisie A analyser et à dével opper

Gestion des frais P031.AB03 - 31-07 Automatisch verwerken van onkostennota's /Registratie van akten en kosten A analyser et à dével opper x

Gestion des frais P031.AB10 - 31-19 Verwerking van aan de staat verschuldigde kosten, schadevergoedingen en interesten A analyser et à dével opper x

Gestion des frais P031.AB03 - 31-22 Manuele verwerking van kostennota's (manuele registratie akten en kosten) A développer x

Gestion des frais P031.AB10 - 31-62 Verwerking van de door de staat verschuldigde kosten, schadevergoedingen en interesten A analyser et à dével opper x

Gestion des frais P031.AB07 - 31-95 Opstellen Advocatenfiche A analyser et à dével opper x

Gestion des prescriptions P031.AB10 - 31-09-01 Interruption de la prescription A analyser et à dével opper x

Gestion des prescriptions P031.AB10 - 31-09-02 Calculer la prescription A ana lyser et à développer x

Gestion des prescriptions P031.AB10 - 31-09-04 Suivi interruption de la prescription A développer (x) x

Gestion des prescriptions P031.AB10 - 31-09-05 Encoder un acte interruptif de prescription A analyser et à dével opper x

Gestion des prescriptions P031.AB10 - 31-20 Controleren van verjaringsstuitende acties en schorsende evenementen A analyser et à dével opper x x

Gestion des prescriptions P031.AB10 - 31-21 Behandelen dossiers verantwoordelijkheid rekenplichtige A analyser et à dével opper x


Page 99 sur 149

4.4 .3.2 Produits à développer 1. Gestion des dossiers

• 31-51 Suivi automatique des dossiers

Current status: A développer Pour obtenir le paiement d'une dette, il est parfois nécessaire de recourir à plusieurs actions de recouvrement. Ce UC automatique a pour but de présenter à nouveau au gestionnaire les dettes pour lesquelles une action de recouvrement n'a pas abouti dans un délai donné.

• 31-54 Suivi manuel de dossiers

Current status: A développer Il faut développer les fonctionnalités qui permettent les interventions manuelles susceptibles d’intervenir dans le cadre du suivi d’une action de recouvrement.

• 31-59 Renvoi manuel de la correspondance Current status: A analyser et à développer Le courrier expédié par le SPF Finances peut, pour diverses raisons, ne pas être distribué à son destinataire, le client, par La Poste. Ce Use Case permet de traiter manuellement la partie du courrier qui a fait retour au SPF.

• 31-63 Consultation de la fiche de solvabilité

Current status: En production et à adapter Le principe de départ consiste à offrir à l’utilisateur via ce UC 31-63 la possibilité de lancer une enquête de manière uniforme sur la solvabilité du « client ». L’écran de base de la « Fiche de solvabilité » fera office de point de départ pour visualiser toutes sortes d’informations liées qui peuvent avoir une influence sur le pouvoir libératoire du « client ». Les liens avec des applications existantes (service s web) doivent être développés à partir de la fiche de solvabilité (exe mples : Recherche BCSS, ConsultImmo, DIV, Stirint, BOW).

2. Moteur générique de recouvrement

• 31-04 Octroi de facilités de paiement Current status : En production et à adapter L’utilisateur code le plan d’apurement attribué dans la dette. Le système calcule le montant à payer et envoie l’aperçu et les formulaires de paiement du montant à payer, ainsi que la date au client. Il faut développer un lien avec e-Plan d’apurement via Myminfin.

• 31-11-01 Examen des propositions de suspension du r ecouvrement Current status: A analyser et à développer


Page 100 sur 149

Ce UC découle du UC 31-27 (manuelle) de demande en « suspension de recouvrement ». La réception et le contrôle du document électronique « Proposition de demande en suspension de recouvrement » avec les données du dossier unique. Codage dans le système de sorte que la décision (accord définitif, accord provisoire motivé, rejet motivé) soit préparée pour le médiateur réglementaire.

• 31-11-02 Suite de la suspension annulation avant pr escription Current status: A analyser et à développer Le UC cherchera toutes les dettes qui

o se prescrivent dans les 10 jours ou moins ;

o ont le statut de « suspension du recouvrement » ;

o et annulera ces dettes.

• 31-12 Décision d’autorisation de suspension Current status: A analyser et à développer L’utilisateur prendra une décision sur la base des propositions de « suspension du recouvrement » du gestionnaire de dossier (use case 31-11). L’élaboration de la décision est reprise dans ce UC.

• 31-23 Attribution poursuite à un huissier de justic e Current status: En production et à adapter Parfois, il est nécessaire de recourir à des mesures de contrainte pour recouvrer les droits. Le but de ce use case est de confier à l’huissier la mission d’intenter, pour une ou plusieurs dettes, des poursuites directes ou indirectes (saisie-exécution ou conservatoire).

• 31-24 Notification aux notaires Current status: A analyser et à développer Les notaires, commissaires des comités d’acquisition et les autres fonctionnaires ou officiers publics tenus aux obligations légales semblables (communes, provinces) requis de dresser un acte ayant pour objet l’aliénation ou l’affectation hypothécaire d’un immeuble, d’un navire ou d’un bateau, sis en Belgique, doivent aviser par voie électronique le centre unique créé à cette fin au sein du SPF Finances du projet de cet acte. Ce centre fait un tri automatique de ces avis et les transfère aux différents services concernés. Le(s) fonctionnaire(s) chargé(s) du recouvrement, peut (peuvent), si les droits du Trésor sont en péril, notifier par voie électronique les impôts restant dus qui peuvent donner lieu à inscription hypothécaire. L’acte doit être passé dans les trois mois à compter de l’expédition de l’avis notarial à défaut d’être nul et non avenu. Il faut développer un lien avec eNotariat.

• 31-27 Proposition manuelle de demande en suspension / Proposition

manuelle d’annulation d’une dette Current status: A analyser et à développer Ce use case assure la création manuelle d'une demande en "suspension du recouvrement" de dettes pour lesquelles il n'existe plus aucune possibilité de recouvrement. Le gestionnaire rassemble les éléments qui permettront au comptable de prendre la décision de demander à être déchargé du recouvrement des dettes en question.


Page 101 sur 149

• 31-28 Déclaration de créance

Current status: A analyser et à développer En cas de faillite, concordat, liquidation, règlement collectif de dettes, etc., l’utilisateur doit adresser un document reprenant les dettes du client (=déclaration de créances) aux mandataires compétents ou aux greffes des tribunaux de commerce.

• 31-32-01 Apurement des soldes minimes

Current status: A développer Ce UC fait partie de la « gestion des échéances ». En ce qui concerne les dettes (ou les soldes de dettes) inférieures à un montant déterminé par les services d’encadrement (actuellement 2,5 €), il manque l’intérêt économique pour les percevoir. Afin d'écarter définitivement ces dettes des procédures de recouvrement et de poursuite, un statut de recouvrement ‘Annuler’ est conféré à ces dettes.

• 31-32-02 Apurement des soldes à ne pas recouvrer Current status: À développer Ce UC annule une dette si le solde en recouvrement + cette dette est inférieur à un certain montant (12,5 € en 2007) après envoi d’une sommation non recommandée.

• 31-35 Sommation pour plan d’apurement Current status: En production et à adapter Il s’agit d’un UC automatique. Pour un plan d'apurement qui n’est pas suivi, le système crée une sommation automatisée de sorte que le client puisse immédiatement verser le déficit dans le plan d’apurement.

• 31-36 Scission des dettes Current status: A développer Il existe des dettes qui doivent être répercutées sur plusieurs débiteurs. Il se peut que la dette doive être scindée parce qu’elle ne peut être légalement recouvrée à charge de l’un de ces débiteurs que pour une partie. (des conjoints avec un contrat de mariage de séparation pure de biens, la part de chacun des héritiers, ...).

• 31-37-01 Saisie-arrêt simplifiée

Current status: A développer Une dette impayée à l'échéance et munie d’un titre exécutoire peut, afin d’être recouvrée, faire l’objet de poursuites indirectes, c'est-à-dire des actions dirigées contre des tiers, débiteurs du client (organisme bancaire, par exemple). Les poursuites indirectes consistent à saisir cette créance afin d’apurer totalement ou partiellement la dette du client. A cet effet, l'administration dispose d'une saisie-arrêt simplifiée ne nécessitant pas l'intervention d'un huissier de justice. Il faut développer un lien avec l’application SAFS.

• 31-38 Inscription hypothécaire Current status: A analyser et à développer Dans le cadre des mesures à prendre en matière de recouvrement, il existe une mesure conservatoire consistant à inscrire une hypothèque sur les


Page 102 sur 149

immeubles, navires ou bateaux sis en Belgique auprès d’un Conservateur des Hypothèques (Entité Documentation patrimoniale).

• 31-43 Cessation de plans d'apurement Current status : A développer Les plans d’apurement qui ne sont pas suivis par le client, pour lesquels une sommation automatique a été envoyée sans que le client y donne suite, sont résiliés de sorte que la dette est à nouveau reprise dans le circuit normal des poursuites (suite du UC 31-35).

• 31-46 Attestation de cession de fonds de commerce

Current status: A analyser et à développer Via le Use Case, l’utilisateur peut fournir un certificat en application de l’article 442bis du CIR 92, 93undecies B CTVA (cession de fonds de commerce).

• 31-47 Réactions après le paiement de la dette dans les poursuites Current status: A développer Ce Use Case part d’un paiement qui a été signalé et dont le gestionnaire de dossier a été informé via un ToDo. Pour informer le tiers qu’un paiement a été reçu ou qu’il faut tenir compte d’une réduction des droits constatés, l’acteur utilise des documents standardisés.

• avis de réception paiement tiers : avis au « client », qui confirme la réception du paiement et donne l’état de la dette après comptabilisation ;

• ‘mainlevée de la saisie-arrêt' : notification à un tiers qu’il ne faudra plus tenir compte de la saisie à l’avenir ;

• ‘mainlevée inscription hypothécaire’ envoyée au « client ». • ‘lettre d’info huissier de justice’ : avis à l’huissier d’un paiement • ‘mainlevée avis de saisie’ : avis au tribunal de première instance

et/ou au tribunal de commerce mentionnés dans l'avis de saisie. Une annulation d’une dette doit également être notifiée à ce tiers.

• 31-50 Mainlevée à la demande d’une partie intéressé e Current status: A développer Le UC est utilisé pour donner des mainlevées ou radier des avis de saisie suite à des mesures de recouvrement : • Conservatoires (ex. : retenues, inscription hypothécaire, …) • Exécutoires à la demande d'une partie intéressée => intervention manuelle. Exemples : notification, hypothèque, saisie conservatoire, saisie-arrêt, …

• 31-56 Recouvrement international Current status: A analyser et à développer Lorsqu'un contribuable belge ou étranger est redevable de dettes envers la Belgique et qu'il possède des avoirs dans un autre état de l'Union européenne ou dans un état avec lequel la Belgique a conclu une convention d'assistance au recouvrement, le receveur belge peut adresser une demande d’assistance à l’autorité compétente belge laquelle se chargera de la transmission de cette demande à l’autorité compétente de l’Etat requis. Cette


Page 103 sur 149

demande d'assistance peut être adressée que le contribuable soit domicilié en Belgique ou à l'étranger. Les caractéristiques de la dette (type d'impôt, montant du principal et des accessoires, date d'échéance, date de prescription, etc.) doivent être transmises à l'autorité requise afin de lui permettre d'effectuer la perception et le recouvrement. A l'exception des frais de poursuite que l'autorité requise engagerait pour recouvrer la dette, les droits transmis et les perceptions effectuées par cet état sont dus à la Belgique. Ce use case prend uniquement en charge les demandes de recouvrement et les demandes de mesures conservatoires destinées à une autorité étrangère. Les demandes de renseignement et les demandes de notification ne sont pas prises en compte. Ce use case assure la création et l'envoi de la demande d'assistance à l'autorité requise. La réception et le traitement de la réponse reçue de l'autorité requise sont pris en charge par le UC 31-09-03 (Conclure une action de recouvrement). Ce UC doit permettre de faire un lien avec l’applic ation Stirint en lui envoyant la demande d’assistance au recouvrement do nt il est question ci-dessus et traiter les informations, et le retour de cette demande.

• 31-77 Clôture du dossier et renvoi de statut au dem andeur Current status: A analyser et à développer Titre complet : Clôture du dossier et renvoi au demandeur (si irrécouvrable ou solde perçu par demandeur) Via ce UC, l’utilisateur peut clôturer le dossier et le renvoyer au demandeur.

• 31-79 Envoyer une proposition de cession volontaire Current status: A analyser et à développer Une ‘cession volontaire' peut être proposée. Le ‘client’ doit approuver cette cession. Avant cette approbation, il faut signer un document standard, la ‘proposition de cession volontaire’. Ce use case permet de créer et d’envoyer cette proposition. La personne en question devra ensuite renvoyer une version signée.

• 31-90 Enregistrement de la décision de suspension Current status: A analyser et à développer Dans le cadre d’une surséance indéfinie au recouvrement, une décision peut être très étendue, avec différentes décisions par dette ou groupe de dettes.

• 31-98 Suspension ou exonération intérêts de retard

Current status: A analyser et à développer

• 07-38-31 Renouvellement d’un avis de saisie Current status: A analyser et à développer Il faut développer un lien avec FCA (l’avis de saisie doit être renouvelé après 3 ans).

• 31-81 Statistiques et rapports en matière de recouv rement Current status: A analyser et à développer Pour un bon fonctionnement des équipes de recouvrement, il est nécessaire de pouvoir imprimer des rapports et statistiques concernant l’état d’avancement et la situation du recouvrement.


Page 104 sur 149

3. Gestion des frais

• 31-19 Traitement des frais, dédommagements et intér êts dus à l’Etat Current status: A analyser et à développer Ce UC permet la récupération par l'Etat des dépens, indemnités de procédure et dommages-intérêts qui lui ont été alloués par la justice dans le cadre d'une procédure judiciaire.

• 31-62 Traitement des frais, dédommagements et intér êts dus par l’Etat

Current status: A analyser et à développer Ce UC permet à l'Etat de liquider les dépens, indemnités de procédure et dommages-intérêts auxquels une décision judiciaire l'a condamné.

5 Encadrement de la mission

5.1 Phasage Le soumissionnaire doit préciser dans son offre le phasage qu’il préconise pour réaliser et livrer les produits à développer dans les meilleures conditions en respectant les délais fixés au point 7.6 « Délais d’exécution » du point D Exécution.

5.2 Aspects liés au personnel Pour les personnes-clés du projet (chef de projet, analyste, team leader architect-design), le soumissionnaire est invité à joindre un CV nominatif conforme au modèle de l'annexe ‘curriculum vitae’. Il spécifiera aussi la fonction et les responsabilités de chaque personne dont il soumet le CV. L’offre comprendra un aperçu schématique de l’équipe mise en place. Il est demandé au soumissionnaire de justifier clairement les raisons pour lesquelles les personnes reprises dans l’équipe occupent leur fonction ainsi que l’organisation qu’il mettra en place. Les personnes-clés du projet (chef de projet, analyste, team leader architect-design) doivent, en outre, capable de communiquer oralement tant français qu’en néerlandais.

5.3 Documentation à produire. L'adjudicataire remettra au SPF Finances toute la documentation technique nécessaire à l'utilisation et à la gestion du système, soit en français et en néerlandais, soit en anglais, selon la langue dans laquelle la documentation est disponible. La documentation contiendra plus particulièrement les manuels techniques qui décrivent les caractéristiques et les règles d'utilisation du matériel et des logiciels faisant partie du projet, avec un exposé détaillé du système complet ainsi que des précisions sur les différents sous-systèmes et leurs liaisons. En plus de la documentation technique, un « end user guide » devra être rédigé et fourni au SPF Finances en français, néerlandais et allemand.


Page 105 sur 149

Afin d’être intégrée dans le logiciel de gestion documentaire ICT du SPF, une version électronique sera obligatoirement fournie en Word 2010 (ou au format PDF permettant d’effectuer des recherches « plein texte ») et sera envoyée au plus tard à la réception technique globale de chaque module. L'offre précisera sur quels autres types de support la documentation sera livrée (papier, CD-Rom) de même que les quantités standard et les conditions auxquelles des exemplaires supplémentaires peuvent être commandés. Le soumissionnaire est invité à expliquer sa méthode de tenue à jour de la documentation. Le SPF Finances peut copier les manuels pour les besoins de leur diffusion interne.

6 Services à fournir

6.1 Transfert de connaissance Description de la ou des formations demandées Chacune des formations demandées doit être proposée en français et en néerlandais. Le SPF Finances se réserve la possibilité de commander ultérieurement des formations supplémentaires. Les formations sont demandées pour les rôles suivants : • Train the trainer : le soumissionnaire propose une formation du type « train the trainer ».

Après cette formation, les formateurs seront capables de former les utilisateurs afin qu’ils soient capables de s'orienter dans l'environnement et de s'en servir. Une formation est prévue par groupe de 10 maximum. Cette formation doit permettre d'apprendre l'utilisation du logiciel.

• Gestionnaire de systèmes & développeurs : 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. A la fin de cette formation, le personnel du SPF Finances sera capable, en cas de panne, de détecter quel est le composant logiciel responsable de celle-ci et, pour les composant les plus simple, de corriger lui-même le code de l’application.

• Service desk (le service desk opère d'après les principes ITIL) : le soumissionnaire propose une brève formation, en groupes de 10 personnes maximum. La 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). A la suite de cette formation, la première ligne du service desk sera capable d’analyser les demandes des utilisateurs et ainsi transférer à la deuxième ligne (adjudicataire) uniquement les demandes les concernant.

Pour les formations ci-dessus, le soumissionnaire décrit les objectifs, le contenu et la forme. Exigences générales Les modalités ci-dessous restent intégralement applicables. À défaut, l'offre du soumissionnaire peut être considérée comme irrégulière. Le soumissionnaire doit organiser les formations en néerlandais et en français. Les personnes chargées de la formation doivent :

• posséder l'expérience nécessaire dans le domaine qu'elles enseignent ;


Page 106 sur 149

• faire preuve d'une maîtrise PARFAITE de la langue dans laquelle le cours est donné ; • posséder les qualités pédagogiques indispensables pour transmettre la matière de

façon structurée et systématique aux participants ; • savoir exploiter efficacement les moyens pédagogiques et s'en servir aux bons

moments ; • tenir compte des remarques du pouvoir adjudicateur en ce qui concerne le contenu et

la présentation de la formation. Le cas échéant, l'offre peut se contenter de faire référence au CV de la ou des personnes concernées. Le pouvoir adjudicateur se réserve le droit d'exiger par téléphone, télécopie ou courriel, suivis d'une confirmation par lettre recommandée, le remplacement immédiat d'un ou plusieurs formateurs qui ne répondraient pas aux qualifications requises, par des formateurs possédant des qualifications équivalentes à celles qui sont mentionnées dans l'offre. En principe, les formations sont dispensées dans les locaux proposés par le SPF Finances, situés dans l'agglomération bruxelloise. Le soumissionnaire annonce clairement les moyens et impératifs techniques propres aux différentes formations (par exemple, le nombre de PC). Chaque participant recevra un manuel relatif à sa formation, rédigé dans sa langue. Il ne peut être dérogé à cette règle sans en avoir averti le SPF Finances au préalable et avoir obtenu son autorisation.

6.2 Assistance complémentaire Maximum 300 jours-hommes d'assistance complémentaire sont prévus pour la durée du projet. L'utilisation de ces 300 jours de services ne peut se faire qu'avec l'approbation des membres du comité de pilotage et du Steering. Chaque jour utilisé devra être expliqué de manière détaillée. Le SPF peut au besoin faire appel à des jours entiers ou des demi-jours d’assistance, qui sont facturés au fur et à mesure qu’ils sont utilisés. Le soumissionnaire est tenu de remettre offre pour cette assistance mais le SPF Finances est libre de commander ou non ces jours, sans que l’adjudicataire ne puisse réclamer de dommages et intérêts au cas où le SPF Finances ne commanderait pas entièrement ou partiellement ce poste. Il est demandé au soumissionnaire de fournir un prix unique par jour (tous profils confondus) pour les services complémentaires.

6.3 Transférabilité L’adjudicataire remettra au SPF Finances toutes les informations nécessaires pour transférer le contrat afin que le SPF 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 de bonne foi 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


Page 107 sur 149

documents appartenant au SPF. Les méthodes et procédures instaurées durant les prestations sont la propriété du SPF Finances. Aussi, en cas de résiliation ou de non-renouvellement, 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. 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.

Le soumissionnaire explique au minimum comment il compte aborder les éléments ci-dessus, en ajoutant les informations supplémentaires qu'il juge utiles.

6.4 Maintenance et support La maintenance de l’application doit être assurée durant toute la durée d’exécution du marché. Elle concerne tant le sytème actuel que les produits à livrer. Programme de maintenance Le soumissionnaire doit décrire la maintenance à assurer pour les produits livrés. Cela couvre notamment :

• Maintenance préventive. • Maintenance corrective (Bugs Fixing). • Maintenance évolutive.

La réponse doit être cohérente avec les exigences ci-dessous. Maintenance préventive La maintenance préventive couvre les interventions techniques de paramétrage, d'optimisation, de mise au du système livré. Ces interventions sont effectuées de façon à perturber le moins possible la production, autrement dit de préférence dans les périodes calmes. L'adjudicataire avertira l'Administration au moins quatre jours ouvrables avant une intervention programmée. Celle-ci ne pourra avoir lieu qu'avec l'autorisation explicite de l’Administration. La maintenance préventive est gratuite pendant la période de garantie.


Page 108 sur 149

Maintenance corrective/ problèmes techniques L'adjudicataire assurera au minimum l'assistance technique nécessaire à la résolution des problèmes techniques du système livré. L'assistance technique est assurée pendant les heures d'ouverture des services du SPF (de 7 h 00 à 19 h). Les demandes doivent pouvoir être suivies par les collaborateurs du SPF Finances. Le suivi des interventions doit être possible chaque jour de la semaine, aux heures d’ouverture bureaux (7h à 19h). L'application de suivi est celle du service desk du SPF Finances. Elle permettra de mesurer la capacité de réaction et la qualité des interventions dans le cadre du SLA. La maintenance corrective est gratuite pendant la période de garantie. Délai d'intervention : L'adjudicataire doit réagir à chaque demande d'intervention dans un délai de 8 heures (avec un début de solution). Dans un délai de 16 heures, une solution doit être en place pour permettre la reprise des activités de production. Ce délai est également valable pour les parties du système qui ne sont pas directement livrées par l'adjudicataire. Le rythme normal du travail doit donc être rétabli dans les 24 heures suivant la notification d'un problème de priorités 1 et 2. Ce délai peut être allongé ou raccourci, par exemple pour les problèmes de priorité 3 et 4, en fonction de la nature du problème. Si l'on prévoit que les mesures curatives vont prendre trop de temps, l'adjudicataire doit, dans la mesure du possible, proposer un palliatif permettant de contourner le problème ou le défaut. Maintenance évolutive La maintenance évolutive concerne les modifications aux logiciels et aux applications résultant des changements et upgrades apportés aux environnements, aux applications clients et aux standards de l'Administration, à quoi il faut ajouter de nouvelles fonctionnalités. La maintenance évolutive est expressément demandée par le SPF Finances. Planning de la maintenance L'adjudicataire exposera les grandes lignes du programme de maintenance qu'il recommande pour le système en production et les produits à livrer, programme à appliquer par le personnel du SPF Finances afin que les produits de l'adjudicataire soient adéquatement supportés. Cela concerne toutes les opérations d'entretien du système : quotidiennes, hebdomadaires, mensuelles ou autres. Par ailleurs, le planning de la maintenance doit répondre aux exigences décrites dans le chapitre SLA.

7. SLA

7.1. Introduction

Afin de garantir le niveau de qualité de la maintenance FIRST à fournir et des services y afférents, le SPF Finances souhaite, dans le cadre du présent cahier des charges, que le SLA nécessaire soit présenté et implémenté après l’attribution du marché.


Page 109 sur 149

Le SPF Finances accorde une grande importance au SLA qu’il demande. Les SLA permettent 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’adjudicataire s’engage à respecter les niveaux de service (service levels) et les obligations de résultats fixés par le 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 service 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. Les niveaux de service individuels décrits constitueront le SLA du présent cahier des charges. Le 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 de pénalité 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 les processus ITIL© V3-2011. Le SLA sera élaboré dans ce cadre. La gestion des niveaux de service 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.

Documents à introduire obligatoirement avec l’offre :

1. Service Quality Plan & Service Improvement Plan 2. SLA (conformément au modèle de SLA joint en anne xe …) 3. DAP 4. Exemple de rapport 5. Tableau des KPI dûment rempli (conformément au t ableau des KPI en format

A3 joint en annexe … du présent cahier des charges) a. En ce qui concerne le tableau des KPI, il convie nt, outre la version

papier ou numérique non modifiable, d’également dép oser une version électronique en format Excel avec 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 être m odifiées.


Page 110 sur 149

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

7.2.1. SLA - modèle SPFFIN (= SPF Finances) En annexe à ce cahier des charges figure le modèle de SLA actuel du SPF Finances qui sert de point de départ à la rédaction du SLA. Il s’agit d’un modèle 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. Outre les éléments standards du ou des SLA que le soumissionnaire doit présenter, les niveaux de service et les obligations de résultats que le SPF Finances demande dans le cahier des charges doivent y être notamment détaillés. Aucune information financière ne figure dans le SLA, sauf, éventuellement, une liste des clauses de pénalité.

7.2.2. Concept de « Dossier Accords et Procédures (DAP) » – contenu

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

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

• Accords concernant les processus et procédures (modèles, processus de gestion, tâches de gestion, description détaillée avec flowcharts par processus de gestion, interfaces, accords…) ;

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

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

• Exemples de rapportage (organisation du rapportage pour chaque processus de gestion, fréquence et forme du rapportage sur les SLA, exemple de rapport, etc.).

Pour l’élaboration détaillée, veuillez consulter un ouvrage de référence3 qui contient un modèle 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 projet de DAP. En ce qui concerne les processus et les procédures, le standard au sein du SPF Finances est actuellement ITIL© V3-2011. Il est spécifiquement demandé qu'une première version des

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


Page 111 sur 149

processus et des procédures y afférentes suivants soit traitée et décrite dans le projet de DAP à présenter, le cas échéant :

o ITIL Service Delivery Set (gestion tactique) � Gestion du Service Level ; � Gestion de la disponibilité ; � Gestion de la capacité ; � Gestion de la continuité du service IT ;

o Service Support Set (Gestion opérationnelle)

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

Cette première version de ce projet de DAP sera obl igatoirement jointe à l’offre. 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 SLA, soit dans le DAP avec une référence claire au paragraphe concerné. P. ex. les processus et procédures des SLA peuvent faire référence à des procédures élaborées dans le DAP.


Page 112 sur 149

7.2.3. Tableau des KPI avec clauses de pénalité

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 joint en annexe contient à la fois les KPI et les indicateurs de performance (IP) et normes de performance correspon dants. Une clause de pénalité 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. Ce tableau des KPI avec clauses de pénalité doit ob ligatoirement être joint à l’offre (voir critères d’évaluation). Elle doit permettre à la commission d’évaluation d’ évaluer le tableau de KPI proposé.

7.2.4. Service Level Reporting (SLR) - rapportage 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.

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

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

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


Page 113 sur 149

L’adjudicataire 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.

7.2.8. Délai d’élaboration et moyens mis à disposition pour l’élaboration du DAP après l’attribution du marché

Le SLA global complet, élaboré en concertation et définitif, les éventuels tableaux de KPI et le DAP (Dossier Accords et Procédures) doivent être disponibles pour signature deux mois après l'attribution du marché. 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 (SLA, DAP, tableau des KPI…) ainsi que les procédures et processus correspondants durant toute la durée de ce marché.

7.3. Encadrement des SLA

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

• http://wiki.en.it-processmaps.com/index.php/Main_Page 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.aspx 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 explicitement signalé dans le cahier des charges. Seule cette définition sera valable.

7.3.2. Relations entre SLA et normes et fondements ICT du SPF Finances.

Les normes et fondements ICT du SPF Finances sont publiés en ligne sur les sites Web suivants :

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

• Français


Page 114 sur 149

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

7.3.3. 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. Exigences (FUP D2) 2. Conception (FUP D3) 3. Développement (FUP D4) 4. Test (FUP D5)

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

1. Requirements Review : la validation des exigences en concertation avec le business. L’adjudicataire décrira l’approche qu’il utilisera dans la review afin d’identifier et de valider les exigences. L’approche doit permettre d’obtenir une compréhension mutuelle optimale de chaque exigence 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 décrira l’approche qu’il utilisera dans la review pour faire en sorte que la conception corresponde aux standards ICT et aux exigences 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 décrira l’approche qu’il utilisera dans la review pour garantir que le code fourni est, d’une part, développé selon les meilleures pratiques généralement admises et satisfait, d’autre part, aux exigences des normes ICT.

4. Test Review : l’adjudicataire décrira l’approche spécifique qu’il utilisera dans la review pour garantir la qualité des tests.

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

Requirements (FUP D2)

•Quality Gate 1: Requirement review

Design (FUP D3)

•Quality Gate 2: Design review

Ontwikkeling (FUP D4)

•Quality Gate 3: Development Review

Testing (FUP D5)

•Quality Gate 4: Test review


Page 115 sur 149

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 modèles décrits dans les standards ICT reste obligatoire (ex. modèle deliverables FUP, outils FUP…). Ils devront donc également être intégrés dans les approches des reviews demandées dans ce paragraphe.

7.3.4. Environnements à supporter dans le cadre de ces 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. Le tableau des KPI indiquera pour chaque KPI l’environnement pour lequel il est valable.

• D : développement • A : acceptation • P : production

7.4. Service Levels et engagements de résultats y afférents

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. Service 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 relatifs aux services du personnel mis à disposition par

l’entrepreneur ;

7. Service Levels relatifs au rapportage périodique sur les SLA.

Ces 7 SLA et engagements de résultats sont discutés dans les sections suivantes.


Page 116 sur 149

7.5. Service Levels concernant la gestion de projets : délai, exhaustivité et planification

7.5.1. PI-Project Plan-Planning

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

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

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

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

• l’utilisation correcte des standards définis dans les standards ICT publiés4.

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

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

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

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

o à un unit test coverage élevé : min. 80% ;

4 Architecture Building Blocks 5 Vu la durée du contrat-cadre, ces principes et critères pourront être adaptés aux nouvelles évolutions et découvertes technologiques.

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 • La comparaison manuelle des dates conformément au planning. Formule de calcul • Date de livraison – date prévue dans le planning. Période de calcul • Chaque trimestre sera établi l’état du retard de tous les projets en cours. 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.


Page 117 sur 149

o à un degré suffisamment élevé de documentation du code : une bonne documentation de tous les public API’s, etc.

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

7.6.1. PI-FUP-deliverables

Remarque : L’évaluation de qualité des deliverables fournis fait partie des procédures de

livraison convenues dans le cadre du contrat.

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

• La date à laquelle la version finale des deliverables FUP sera reçue au repository central. 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 a mis la version corrigée à disposition au repository central.

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 • 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 et prouve qu’elles ont été résolues.

Période de calcul • Trimestrielle


Page 118 sur 149

7.6.3. PI-Quality-of-Code

7.6.4. PI-Security-Integrity-Code

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

7.7.1. PI-Continuous-Integration-Tool-Chain

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 • Le nombre de jours ouvrables entre la date de livraison de la version non conforme et la

date de livraison de la version corrigée. 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 • L’objectif de cet indicateur de performance est que l’entrepreneur informe le SPF

Finances des manquements de sécurité pertinents dont il a connaissance dans son Service Level Report (SLR). Application des « Best Practices » dans le cadre de la protection des systèmes informatiques.

Selon le manquement de sécurité signalé, un plan d’action éventuel, un planning et une analyse de risques doit être reprise dans le rapport SLR. Ceci doit permettre de prendre les mesures adéquates en concertation avec l’entrepreneur.

Résultat à atteindre Mettre en place une politique de protection aussi e fficace que possible pour le projet.

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.


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

Tool Chain.


Page 119 sur 149

7.7.2. PI-Releases-in-production

7.8. Service levels exigences non fonctionnelles

7.8.1. PI–Availibility-7x12x365 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.

7.8.1.1. Périodes d’ouverture d’un service (service window) et périodes de maintenance 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.

Service window 7x12x365 heures de bureau Les services impliqués sont disponibles 7 jours sur 7, tous les jours de l’année, de 19h à 7h, à l’exception des week-ends de maintenanc e 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 des services, pa r exemple en raison d’incidents, seront traitées comme telles si elles relèvent de l a compétence de l’entrepreneur.

7.8.1.2. PI–Availability-7x12x365-FIRST normes des service windows

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 car inexactes, incomplètes ou douteuses / Nombre total de versions


Max. 10%

Objectifs

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

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

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

• 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 périodique (p. ex. toutes les 10 minutes) qui contrôle les fonctionnalités.

Période de mesure • 6 mois


Page 120 sur 149

7.8.1.3. Clause de pénalité PI–Avail(ability) La disponibilité et les clauses de pénalité correspondantes s’appliquent à toutes les applications individuelles que l’adjudicataire a en production. Les amendes sont donc calculées par disponibilité d’une application individuelle.

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

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

Ce SLA aura notamment trait : • à la disponibilité du help desk de 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’adjudicataire seront basées sur les principes suivants :

• Assistance téléphonique pendant les heures d’ouverture du SPF Finances les jours ouvrables entre 7h00 et 19h00.

Formule de calcul • La disponibilité exprimée en % sur la période à mesurer, en tenant compte des interruptions convenues (maintenance)

Résultat à atteindre

99,50% de disponibilité (mesurée sur six mois)

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

Par ex. X % < Y secondes

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

requis après l’attribution du marché.


Page 121 sur 149

• À 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 encodée dans un système de suivi des incidents qui est mis à la disposition de l’entrepreneur. L’entrepreneur doit y compléter tous les éléments requis par rapport à la résolution de l’incident, conformément aux obligations du SLA qu’il a signé dans le cadre de son offre.

7.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 sur l’activité 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.

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

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


Page 122 sur 149

Définitions de l’impact sur l’activité : • Very High Risk – Impact sur un département complet ou un délai de livraison/service critique

ou impact important sur l'activité sans solution d'urgence réalisable pour l'activité • High Risk – Impact sur un grand groupe d’utilisateurs ou impact moyen sur l’activité sans

solution d’urgence réalisable pour l’activité • Moderate Risk – Impact sur un groupe spécifique ou sur plusieurs utilisateurs, ou faible

impact sur l’activité • 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

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

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


Niveau de priorité Délai de réaction (Incident Response Time)

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

2 100 % dans 30min après attribution de l’incident au groupe de support du soumissionnaire

3 100 % dans 30min après attribution de l’incident au groupe de support du soumissionnaire

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


Page 123 sur 149

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

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

7.10.1. PI-Staff-Timesheet

6 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 • 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 »6 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 4h après attribution de l’incident au groupe de support du soumissionnaire

2 80 % dans les 24 heures et 100 % dans les 48 heures après attribution de l’incident au groupe de support 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 du soumissionnaire

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

• Retour des incidents :

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

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

Objectifs Définition • Fournir des timesheets avec les prestations individuelles du personnel qui travaille sur le

projet sur base mensuelle. Méthode de mesure • Remise officielle du timesheet en deux exemplaires, signés par le représentant de

l’adjudicataire et celui du SPF Finances Formule de calcul • Date de remise – 1er jour ouvrable du mois Période de calcul • Trimestrielle


Page 124 sur 149

Remarque : Dans ses timesheets, l’entrepreneur indiquera clairement les heures réellement prestées avec heure de début et de fin, compte tenu des pauses légales prévues qui ne peuvent pas être intégrées aux prestations fournies. Le nom de la personne (et éventuellement son profil) qui a effectué les prestations sera indiqué, ainsi qu’une brève description des prestations effectuées. Si un pool de prestations prévues est utilisé, les prestations qui restent à effectuer seront mentionnées sur le timesheet.

7.11. Service Levels relatifs au rapportage périodique sur les SLA

7.11.1. Rapportage Service Level (SLR) général

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

À un stade ultérieur, il se peut que certains rapportages n'aient pas de valeur ajoutée ou que seules les exceptions doivent être reprises pour certains indicateurs de service. Ceci peut mener à une correction de cette structure de rapportage. Les changements dans les service levels mêmes peuvent également entraîner l’adaptation de la structure de rapportage définie dans ce document. Le soumissionnaire formulera une proposition de rapports trimestriels (SLR) sous la forme d’un document exploitable qui indique les niveaux de SLA atteints. Si des incidents de priorité 1 et 2 ou des « SLA breaches » importantes se produisent, l’adjudicataire établira un rapport SLR intermédiaire avec les éléments clés devant permettre de suivre les projets et de les présenter aux services concernés du SPF Finances (Reviews). Si nécessaire, une réunion SLA est occasionnellement 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é. Les résultats sont aussi 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 disponibilité et de performance ; 4. Statut des composants de la solution (si d’application) ;

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.

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


Page 125 sur 149

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, etc.) ; 7. Rapports d’incidents (détails sur les incidents par catégorie, Incident Response et

Resolution Time, etc.) ; 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.

7.11.2. PI-SLR

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

2. Service Levels relatifs à la phase de

développement

De l’attribution à la mise en production

D-A-P

3. Service Levels relatifs à la mise en production

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

D-A-P

4. Service Levels exigences non fonctionnelles

À partir de la mise en production

P

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

À partir de la mise en production

P

6. Service Levels relatifs aux services du personnel mis à disposition par l’entrepreneur


7. Service Levels relatifs au rapportage périodique sur les SLA


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

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 • Trimestrielle Résultat à atteindre

Réception au plus tard le 7 e jour ouvrable après la période de rapportage écoul ée.


Page 126 sur 149

d’encourager l’adjudicataire à respecter toutes les conventions afin de toujours garantir la prestation de services.

7.13.1. Principe des propositions d’amendes Le SPF Finances impose des amendes standard pour la plupart des niveaux de service. Le soumissionnaire peut proposer des amendes supérieures. Toutes les amendes proposées doivent être reprises dans le tableau des KPI. Le montant de base pour le calcul des amendes reste d’application pendant toute la durée du contrat, sauf si un montant plus élevé a été proposé par le soumissionnaire. Dans ce dernier cas, ce montant plus élevé sera d’application. Les amendes proposées constituent un critère d’évaluation.

7.14. SLA monitoring et concertation de Service Management

7.14.1. SLA-monitoring

7.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, et plus précisément au chapitre ABB.9.1.1 End-to-End Monitoring et mesures service level.

7.14.1.2. Assistance dans le cadre du monitoring par l’adjudicataire Dans le cadre du présent marché, la société collaborera à l’établissement et à la validation d’un scénario de base et aidera à élaborer les éventuelles adaptations occasionnelles, si une version adaptée /mise à jour d'une application est déployée. Le coût de l'assistance pour établir ce monitoring de base et des éventuelles adaptations dans le courant du projet est compris dans le prix de la maintenance annuelle et des projets supplémentaires. Les résultats du monitoring seront utilisés pour le rapportage SLA et peuvent être mis à disposition de l’adjudicataire pour les traiter dans le rapportage SLA à fournir chaque mois.


Page 127 sur 149

Le SPF Finances fournira à l’adjudicataire les chiffres liés au monitoring pour le 10e jour ouvrable du mois suivant. Si des manquements sont constatés, le monitoring lancera la procédure de règlement des incidents avec l'enregistrement nécessaire. L’adjudicataire se déclarera d’accord avec cette méthode de travail pour mesurer la disponibilité. Avec l’équipe de monitoring, l’adjudicataire conclura les accords requis lors du lancement du projet. En cas de doute, il peut faire effectuer à sa charge un audit du système de monitoring des Finances pour vérifier la fiabilité des mesures, et ce pour la partie qui lui importe.

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

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é adjudicataire

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

7.15. Autres Service levels, engagements de résultats et remarque finale

Le SPF Finances peut, s’il le souhaite, exécuter lui-même les mesures des SLA approuvés dans le cadre de ce marché, ou les faire contrôler et exécuter par un bureau d’études indépendant à sa charge. Cela ne dégage pas l’adjudicataire 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 a ttribuer le marché.


Page 128 sur 149

1030 BRUXELLES, Le Président du Comité de direction Hans D’HONDT


Page 129 sur 149

F. ANNEXES

1. Formulaire d’offre;

2. Inventaire ;

3. Standards ict du spf finances – DIRECTIVES TECHNIQUES (informatiques)

4. SLA

5. Références CV

6. Modèle de référence projets similaires


Page 130 sur 149

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/437/2015

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 7

(nom)

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

(rue)

(code postal et commune)

(pays)

agissant comme soumissionnaire ou fondé de pouvoirs , signe ci-dessous et s’engage à exécuter conformément aux clauses et conditions du cahier spécial des charges n°S&L/AO/437/2015 le présent marché aux prix menti onnés dans l’inventaire joint en annexe au présent document.

7 Biffer la mention inutile

Appel d’offres ouvert pour First 2015


Page 131 sur 149

Délais de développement : Pour la tranche 1 :

Délai de développement en mois (avec un maximum de 27 mois)

…………………………………………. mois

Pour les tranches 2 et 3 :

Délai de développement en mois (avec un maximum de 39 mois)

…………………………………………. mois

En outre, j’autorise le pouvoir adjudicateur à prendre auprès d’autres instances, toutes les informations utiles (par exemple, de nature financière) sur mon entreprise. 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. L’organisme de paiement du pouvoir adjudicateur payera les sommes dues par virement ou versement sur le com pte n° : IBAN BIC

Pour l’interprétation du contrat, la langue

française/néerlandaise (*)

est choisie.

Toute correspondance concernant l’exécution du marché doit être envoyée à l’adresse suivante : (rue) (code postal et commune) (n° de � et de fax) (adresse e-mail)

Fait : A Le 2015.

Le soumissionnaire ou le fondé de pouvoirs :


Page 132 sur 149

(nom)

(fonction)

(signature)

APPROUVÉ,

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

et des critères d’attribution (voir point 4 du vole t C. Attribution) ; - L’inventaire entièrement complété ;

- Les statuts ainsi que tout autre document utile pro uvant le mandat du (des) signataire(s).

N’oubliez pas de prévoir une numérotation continue de toutes les pages de votre offre, de votre inventaire et des annexes.


Page 133 sur 149

ANNEXE 2 : INVENTAIRE

1) Développements

Prix forfaitaires

Hors TVA, en euros

Prix forfaitaires TVAC, en euros

En lettres En chiffres En lettres En chiffres

Tranche : 1 Intake générique

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _

_ _ _ _ _ _ , _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

_ _ _ _ _ _ , _ _

Tranche 2 : Module perception - comptabilité

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _

_ _ _ _ _ _ , _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

_ _ _ _ _ _ , _ _

Tranche 3 : Module générique d’actions de recouvrement

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _

_ _ _ _ _ _ , _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

_ _ _ _ _ _ , _ _

Total _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

_ _ _ _ _ _ , _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

_ _ _ _ _ _ , _ _

2) Maintenances

Prix forfaitaires Hors TVA, en euros



Tranche 1 : Maintenance (concerne tant le système actuel que les produits à livrer ) préventive, corrective (Bugs Fixing) et évolutive par mois.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _

_ _ _ _ _ _ , _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

_ _ _ _ _ _ , _ _

Tranche 2 : Maintenance (concerne tant


Page 134 sur 149

3) Assistance complémentaire

Prix forfaitaires Hors TVA, en euros



Assistance complémentaire pour UN jours/hommes

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _

_ _ _ _ _ _ , _ _

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _

_ _ _ _ _ _ , _ _

le système actuel que les produits à livrer) préventive, corrective (Bugs Fixing) et évolutive par mois.

Tranche 3 : Maintenance ( concerne tant le système actuel que les produits à livrer ) préventive, corrective (Bugs Fixing) et évolutive par mois.


Page 135 sur 149

ANNEXE 3 STANDARDS ICT DU SPF FINANCES – DIRECTIVES TECHNIQUES (INFORMATIQUES)

1. Remarques concernant la structure du volet techn ique du cahier spécial des charges

1.1. Définition, abréviation et acronymes utilisés ABB : Architecturale Building Blocks Description architecturale complète de l’environnement informatique existant au sein du SPF Finances ACC : Environnement d’acceptation CCFF : Communication Center for Federal Fiscality Plate-forme de communication et de technologies, pour le développement, agissant comme un portail envers le monde extérieur et vers l'intérieur du SPF Finances. DEV : Environnement de développement FEDIam : Federal IAM Système de sécurité et d’autorisations d’accès applicatif, permettant aux citoyens de s’authentifier pour accéder aux applications offertes par le SPF Finances. FUP : Finances Unified Process Méthodologie de gestion des développements s’inspirant de la méthodologie U.P. FUP-ITIL : Finances Unified Process – Information Technology Infrastructure Library Méthodologie standard du SPF Finances pour la gestion de l’intégration continue. HP-ALM : HP Lifecycle Management IAM : Identity and Access Management Système de sécurité et d’autorisations d’accès applicatif pour le personnel du SPF Finances. JEE : Java Enterprise Edition Ensemble de spécifications techniques couvrant tous les domaines de développement d’application web. Pour connaitre la version en cours d’utilisation au SPF Finances, veuillez vous référer au document d’ABB indiqué dans le point 1.3.2 de cette annexe libellé « Contexte technique ». PROD : environnement de production QUAC : Quality Control


Page 136 sur 149

Organe au sein du Service d’encadrement ICT du SPF Finances, ayant notamment pour mission de contrôler, et valider, le respect des standards en vigueur au SPF Finances. SLA : Service Level Agreement XML : Extensible Markup Language

i. 2. Contexte du marché 2.1.Contexte technique

Le SPF Finances souhaite exploiter au maximum les licences acquises dans le passé, et ne pas payer deux fois pour des fonctionnalités comparables. Pour cette raison, le SPF Finances exige la conformité aux standards ICT déjà en usage depuis plusieurs années. Si des développements s'imposent, le soumissionnaire est prié de faire appel aux outils de développement standard existants. Il doit également s'en tenir aux méthodologies standards d'analyse, de support au développement et de gestion de projet (PMFin, la méthodologie de projet exclusive des Finances, basée sur la norme internationale Prince2). L'attention du soumissionnaire est par ailleurs attirée sur l'extrême importance que cette annexe attache aux aspects IAM dans le contexte du marché. La description complète des standards et de FUP est disponible sur HTTP://MINFIN.FGOV.BE/PORTAIL2/NL/MODERNISATION/ICT.HTM#B (rubrique ‘ICT fundamenten (FOD Financiën)’) et

HTTP://MINFIN.FGOV.BE/PORTAIL2/FR/MODERNISATION/ICT.HTM#B (rubrique ‘Fondements ICT (SPF Finances)’)

2.1.1.Respect des standards ICT

Que la solution offerte soit un package/outil ou le résultat de développements spécifiques sur mesure, il convient de maximiser la conformité aux normes et fondements ICT actuels. Le soumissionnaire est invité à décrire clairement comment sa solution s’intègre aux éléments d’architecture sous-jacents. Toute offre qui ne se conforme pas intégralement aux standards ICT qui ont cours au SPF Finances sera considérée comme nulle.

2.1.2. Exigence intégration aux standards

Dans son offre, le soumissionnaire décrit les « connectors » et/ou les intégrations qu'il juge nécessaires pour pouvoir mettre en place les fonctionnalités demandées. Il doit aussi spécifier les services qu'il fournira et les tâches qui devront être exécutées dans le cadre de la mise en place des « connectors » et/ou intégrations. Il est clair que le système devra interagir avec une multiplicité d'autres systèmes, dont certains restent peut-être à définir. Dans sa solution technique, le soumissionnaire prévoira comment les collaborateurs du Service d'encadrement ICT pourront à l'avenir construire des interfaces avec des applications qui ne sont pas encore connues aujourd'hui. Le soumissionnaire doit donc préciser les conditions à remplir pour qu'un système soit connectable.


Page 137 sur 149

L'attention est attirée sur le fait que les messages entrants sont souvent (mais pas toujours) structurés en XML. En conséquence, dans la mesure du possible, cela déclenchera une saisie de données automatique (avec ou sans contrôle par une personne humaine) dans les applications sous-jacentes. On notera par ailleurs que les messages traités peuvent aussi être à la base d'une saisie de données manuelle.

2.1.3.Bonnes pratiques Toute solution logicielle, ou autres choix techniques devra se faire en respectant les bonnes pratiques du développement logiciel. Par exemple, sans être exhaustif, l’utilisation de « design pattern, organisation de l’architecture logicielle en multi-couches (ex. : MVC), TDD, etc…

2.1.4.Environnement matériel

L’ensemble doit être réalisé sur des plates-formes qui seront mises à disposition par le SPF Finances, dans le respect des normes technologiques et des normes de développement définies par le SPF, à l’exception des postes individuels qui eux sont à charges du prestataire. Le soumissionnaire est invité, dès le stade de l'offre, à donner les indications les plus concrètes possibles quant aux composants matériels et à leur capacité. Cette description doit notamment permettre d’évaluer la solution offerte en termes d’impact sur l’infrastructure et de coûts correspondants.

2.1.5.Sécurité/authentification

Avec le système Identity and Access Management (IAM), le SPF Finances dispose de son propre cadre de gestion des identités et des accès. L’intégration à ce système est considérée comme une nécessité absolue! L’intégration concrète avec IAM sera affinée dans la discipline d’analyse. Contrôle d’accès Si l’application revêt la forme d’un développement spécifique sur mesure, les aspects de la gestion de l'accès tels que l'authentification et l'autorisation doivent utiliser entièrement les composants prévus à cette fin dans le système IAM. En revanche, si cette dernière s’appuie sur un produit prêt à l'emploi disponible dans le commerce et ne faisant pas appel aux composants IAM, l’authentification doit être déléguée au serveur LDAP Corporate. La sécurité des échanges entre LDAP et l’application étant un point critique, la compatibilité avec LDAP via SSL (LDAPS) est indispensable. Mise à disposition (provisioning) des données utilisateurs En complément, tout sera fait pour permettre la mise à disposition des données utilisateur à partir de l’environnement IAM. Cela implique que les métadonnées de l’application (profils utilisateurs internes, répartition en groupes, répartition des rôles et permissions) soient dérivées automatiquement de LDAP.

2.1.6.Poste client


Page 138 sur 149

Le SPF Finances attache une importance particulière à l'indépendance des solutions par rapport aux postes clients. Le client doit donc veiller à ce que le raccordement, l'installation des composants et l'intégration au poste client exercent un impact minimum. A cette fin, il proposera obligatoirement une solution reposant sur les standards web et accessible à travers internet. Le soumissionnaire doit également garantir cette indépendance en termes de logiciels, dans le cadre des standards ICT. A titre d'exemple, les installations éventuelles doivent avoir lieu dans le cadre du projet SMS (System Management System, pour la gestion de l'installation des logiciels à distance). Les services correspondants doivent être assurés via le présent marché, sans frais supplémentaires.

2.1.7.Développement spécifique

Les développements spécifiques pouvant être nécessaires pour répondre aux besoins, ou mener à bien la mission de développement, doivent faire parties du prix total final. La réponse doit s'accompagner d'une description des développements en question.

Pour éviter par la suite les problèmes de mise à jour en cas de nouvelle version, le soumissionnaire s'engage à supporter ces développements dans le cadre de la maintenance de toutes les versions à venir.

2.1.8. Paramétrage spécifique Pour tous les paramétrages spécifiques, le soumissionnaire précisera s'ils doivent être réalisés par lui seul ou si le SPF peut s'en charger de façon autonome, moyennant une formation adéquate.

2.1.9. Environnements informatiques

Au sein d’ICT, dans un processus de développement, chaque phase de la réalisation correspond à un environnement déterminé. La répartition exacte des environnements et leur rôle spécifique seront précisés en fonction de l’architecture de l’application. Le choix dépendra notamment de l’approche choisie pour le projet, de la quantité de développement spécifique, des besoins ICT, etc. Nous distinguons 3 types d’environnements : • Développement : un programme ou composant est d’abord développé dans l’environnement de développement. Le besoin d’un environnement de développement dépend étroitement de l’importance des développements spécifiques requis. Si la solution se compose d’un package/outil à configurer, qui ne nécessite guère d’extensions ni de personnalisation, l’environnement de développement ne sera pas forcément nécessaire. • Test / acceptation : cet environnement est destiné aux diverses activités de test (tests d'intégration, tests des systèmes, tests d'acceptation...). Selon le nombre d’itérations au cours desquelles plusieurs releases subissent en parallèle une phase de test distincte, on peut décider de prévoir un environnement séparé pour les tests d’acceptation. • Production : l’acceptation de l'application est suivie du déploiement dans l’environnement de production, où elle est mise à la disposition des utilisateurs finaux.


Page 139 sur 149

2.1.10. Solution logicielle et plan d’installation

Pour tous les logiciels et les composants qui seront mis en œuvre, le soumissionnaire doit inclure dans son offre une description technique de la solution proposée. Cette description doit couvrir les aspects techniques relatifs à la mise en œuvre, ainsi que les interfaces entre les divers systèmes à intégrer dans le cadre du projet. Le soumissionnaire doit proposer un plan d'installation à haut niveau. La création et la tenue du plan incombent au soumissionnaire. Le plan d'installation doit prévoir : 1. Les délais d'installation de l'application 2. Le niveau de participation du personnel du soumissionnaire et

du personnel du SPF Finances à chaque stade du projet 3. Les résultats finaux (livrables) 4. La formation du personnel du SPF Finances à dispenser à

chaque phase du projet (voir aussi ‘Gestion du projet et méthodologie’)

5. Les autres informations éventuelles que le soumissionnaire juge nécessaires.

Durant la phase d'installation qu'il sera appelé à réaliser, l'adjudicataire collaborera directement avec le personnel du SPF Finances. Le personnel du SPF Finances identifiera les principaux stades du processus et organisera une concertation pour analyser et réorienter l'installation. L'adjudicataire doit produire une présentation adéquate pour chacune de ces réunions. L'adjudicataire rédigera un rapport d'activité hebdomadaire durant l'installation (en plus du rapport mensuel complet au comité de pilotage). L'adjudicataire collaborera avec le personnel du SPF Finances pour définir la teneur du rapport.

2.1.11. Plan de test

L’adjudicataire explique l'approche qu'il entend utiliser pour tester le système. Il présentera son plan de test au SPF Finances. Le soumissionnaire propose et documente un système de test (chargé de vérifier le bon fonctionnement du système et le traitement correct des données). Les tests d'efficacité de l'utilisation de l'application seront effectués dans des groupes d'utilisateurs spécifiques pour chaque module. Le soumissionnaire se charge aussi de cet aspect et le documente. Le plan de test doit être cohérent avec la stratégie de test appliqué au SPF Finances. Remarque : Concernant les tests unitaires, ils devront couvrir 80% code source de la solution développée.

2.1.11.1. Internationalisation

Le logiciel doit obligatoirement être accessible simultanément dans les 3 langues nationales, plus précisément en néerlandais, français et allemand.


Page 140 sur 149

Le choix de la langue peut être opéré par l'utilisateur au stade de la connexion. La langue d'accès concerne :

- les mentions dans les masques et formulaires - les listes de choix à la saisie - le stockage de l'information issue des listes de la base de

données. Toute saisie effectuée dans une liste de valeurs doit pouvoir se faire dans la langue de la connexion. Ces informations doivent pouvoir être lues par un autre utilisateur dans sa propre langue si elle est différente, durant une consultation ou une modification.

Le soumissionnaire précisera quelle méthode le logiciel applique et comment l'exigence de multilinguisme est remplie par le projet.

Le soumissionnaire proposera aussi avec le logiciel un outil externe pour la réalisation des traductions et des mises à jour du logiciel. Cet outil aidera les gestionnaires dans le développement, la modification et l'enrichissement de leurs listes ainsi que dans la création de nouvelles listes.

Pour le reste, les exigences sont les suivantes :

• Dans l'interface, il doit être possible de passer rapidement d'une langue à une autre.

• Le changement de langue doit être transparent aux yeux de l'utilisateur.

• Normalement, la langue de l'interface est celle qui figure dans le profil de l'utilisateur.

• Une recherche dans une langue donnée doit produire les documents dans une autre langue s'ils ne sont pas disponibles dans la langue de la recherche.

• L'utilisateur doit pouvoir voir si le document est disponible dans plusieurs langues.

2.1.11.2. Favoriser l’utilisation des standards ouverts Tout au long du processus de développement l’adjudicataire est invité à favoriser ou à utiliser des standards ouverts lorsqu’il aura le choix.

2.1.12. Contexte organisationnel Il convient ici de bien distinguer la méthodologie de gestion de projet, en l’occurrence PMFin pour le SPF Finances, de la méthodologie de gestion de développement, FUP pour le SPF Finances. Ce point concerne la méthodologie de développement. Pour ce qui concerne la méthodologie de gestion de projet, se référer à l’annexe 2 ci-après.

2.1.12.1. Méthodologie de développement logiciel standard au SPF Finances

Le SPF Finances a instauré une méthodologie pour le développement d’applications. Celle-ci a, avant tout, pour but de formaliser et de


Page 141 sur 149

stabiliser le déroulement des projets ICT dans un cadre commun, en uniformisant le contenu des phases d’un projet, les rôles des différents acteurs, et les artéfacts livrés à chaque phase. Le SPF Finances souhaite faire usage de standards ouverts et reconnus. À cet effet, il a choisi une méthodologie fondée sur UP (Unified Process ou « processus unifié »), et adaptée en fonction de ses besoins.

2.1.12.2. Outils

2.1.12.2.1. Outil de versioning Notre outil de gestion centralisée de versionning et de stockage des codes sources est Starteam, mais peut évoluer dans le futur. Les membres de l'équipe de développement, du soumissionnaire et éventuellement le personnel du SPF Finances, du projet sont expressément invités à transférer le plus régulièrement possible leurs changements sur le serveur de versionning géré par le SPF Finances.

2.1.12.2.2. HP-ALM Outil de gestion des exigences métier et de suivi de tests. Le personnel du soumissionnaire devra s'assurer que toutes les exigences métier du projet y sont répertoriés et à défaut devra les introduire, ainsi que les tenir à jour. Le prestataire devra aussi veillé à assurer la traçabilité la plus complète entre les exigences métiers décrit dans cet outil et le code source développé. Le maximum d’informations doit y être ajouté afin de permettre une compréhension claire et sans ambiguïté des exigences décrites.

2.1.12.2.3. Jbuilder ou Eclipse Tout le code source du projet devra être créé, modifié et édité via l’IDE « Jbuilder » ou bien « Eclipse ».

2.1.12.2.4. Together Architect Toutes les illustrations des solutions architecturales et de conceptions logicielles, y compris ceux concernant la base de données, devront être réalisées, modifiées et éditées avec l’outil « Together Architect ».

2.1.12.2.5. Maven Pour la bonne gestion des développements informatiques le SPF impose l’utilisation d’un outil de gestion et d’automatisation de construction logicielle connu : Maven. Il fait partie d’un des 3 outils permettant la mise en œuvre concrète de FUP-ITIL. Sa configuration et son utilisation sont à charge du personnel du soumissionnaire.

2.1.12.2.6. Jenkins Jenkins est l’outil de gestion d’intégration continu utilisé au sein du SPF Finances.

2.1.12.2.7. Repository des dépendances logicielles


Page 142 sur 149

Artifactory est l’application de gestion de dépendances et d’artefacts logiciels utilisés au sein du SPF Fiances. Toute forme de dépendance, ou librairies tierce, de la solution développée doit obligatoirement se trouver dans ce dépôt logiciel. En cas de besoin justifié, une demande peut être faite pour rajouter les éventuelles dépendances ou librairies manquantes. Il intervient également dans FUP-ITIL.

2.1.13. Contrôle et qualité

Les artefacts fournis, ainsi que la méthodologie utilisée, feront l'objet de contrôles par l'équipe du QUAC. Le QUAC a l'autorité de refuser la livraison de tout élément du projet ne respectant pas les standards du SPF Finances! Un contrôle de qualité par des tiers fait également parti des possibilités.

2.1.14. Suivi technique

Au moins une fois par semaine, l’ICT-Coordinator rencontre l’équipe projet qui doit rendre compte de l’état d’avancement des développements. C’est idéalement à ce moment-là que l’équipe projet peut faire part de ses remarques ou besoins.

ii. 3. Encadrement du marché 3.1 Personnel

Il est demandé aux soumissionnaires de reprendre les fonctions reprises dans les points suivant dans la description de leurs offres.

iii. Chef de projet senior

• Est capable de diriger un projet : assume la gestion générale du projet, la

planification, la définition et la répartition des tâches, le contrôle de qualité, la gestion des risques, la gestion des problèmes, la gestion des changements.

• Assure le suivi des réunions fonctionnelles et techniques. • Gère les livrables et rédige les rapports nécessaires. • Motive les membres de l’équipe. • Sait se montrer diplomate. • Possède un diplôme universitaire ou l’expérience nécessaire. • Expérience : au moins 2 ans dans la gestion de projet avec diplôme universitaire, 5

ans sans diplôme universitaire. • Expérience : au moins 5 ans dans l’informatique avec diplôme universitaire, 10 ans

sans diplôme universitaire. • Peut apporter la preuve qu’il a suivi une formation en gestion de projet. • Sait utiliser les outils de gestion de projet. • Possède les connaissances techniques nécessaires pour diriger le projet. • Communique bien, y compris en public. • Activement bilingue français et néerlandais. • Expérience d’un environnement RUP/UP est un plus.


Page 143 sur 149

iv. ApplicationDesigner et Architecte senior

Chargé de garantir la cohérence entre les différentes disciplines. En particulier, il est responsable de la conformité entre l'architecture technique de l'application ICT (en termes de composants principaux et des relations qui les unissent), les besoins fonctionnels et les autres besoins. Il connaît les avantages et les inconvénients des technologies et des standards disponibles ainsi que leurs possibilités. À ce titre, il est à même de faire le meilleur choix technologique pour répondre aux exigences posées.

• Décomposer l'application dans ses éléments principaux • Choisir les solutions techniques et leurs possibilités dans le cadre des standards

du SPF Finances. • Analyse les besoins en termes d'interface utilisateur et de composants de

l'application • Détermine l'impact sur les systèmes existants et identifie les problèmes • Réalise la modélisation suivant la méthodologie standard • Détermine l'impact sur l'exploitation, l'architecture et la fourniture des services • Définit les types de fichiers et les fichiers utilisés • Définit les exigences techniques • Utilisation et évaluation du répertoire des composants et des modules standard • Prépare une étude détaillée de l'application • Élabore un plan de programmation et de test détaillé • Réalise l’étude de l'application en liaison avec Business et ICT • Compare les aspects infrastructure et application de la nouvelle application avec

l'existant • Rassemble les données de test • Élabore un plan détaillé de tests d’intégration • Expérience: au moins 5 ans dans l’informatique, dont au moins 3 ans comme

« application designer » dans un environnement comparable à celui de l’application à livrer.

v. Programmeur Back-end

• Analyse l’étude • Programmation • Contrôle l'intégrité des composants de l'application • Teste les programmes • Documentation et publication des programmes • Maintenance des programmes • Documentation des programmes • Paramétrage des packages • Diagnostic et choix de la méthode de résolution • Construction, évaluation et intégration de la solution • Interaction avec les bases de données • Confirmation de la solution • Expérience senior : au moins 3 ans dans l’informatique, dont au moins 2 ans comme

programmeur dans un environnement comparable à celui de l’application à livrer. • Expérience junior : au moins 1 an dans l’informatique dans un environnement

comparable à celui de l’application à livrer


Page 144 sur 149

vi. Testeur

• Élabore un plan de test détaillé • Rassemble les données de test à utiliser • Teste les composants • Teste les ensembles logiques • Teste l'application complète • Teste l’infrastructure utilisée • Examine les résultats • Rédige un rapport de test • Réalise un plan détaillé pour les tests d'intégration • Utilise activement une des deux langues nationales et au moins passivement l’autre. • Possède au moins 2 ans d’expérience dans l’informatique, dont au moins 1 an en

tant que testeur.

vii. Rédacteur technique

• Assure la finalisation des documents techniques produits par les autres membres de

l’équipe. • Rédige la documentation utilisateur dans une langue nationale ou les deux. • S’il travaille avec un rédacteur technique qui rédige dans l’autre langue nationale, doit

pouvoir transmettre et recevoir les idées correctement afin que les documents soient identiques dans les deux langues nationales.

• Possède des qualités très solides en termes de connaissance écrite des deux langues nationales et de la langue des documents techniques (généralement l’anglais, mais parfois le français ou le néerlandais).

• Possède des qualités très solides en termes de rédaction de documents clairs, cohérents et structurés.

• Possède au moins 2 ans d’expérience dans l’informatique, dont au moins 1 an en tant que rédacteur technique.


Page 145 sur 149

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

Si les diplômes mentionnés ne correspondent pas à l a réalité, le pouvoir adjudicateur se réserve le dr oit 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


Page 146 sur 149

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 4 « 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) ……………………………………………………


Page 147 sur 149


Page 148 sur 149

ANNEXE 5 : MODELE DE REFERENCE PROJETS SIMILAIRES

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

3. Secteur d’activité

……………………………………………………………………. 4. Nom d’une personne de contact ……………………………

5. Coordonnées

……………………………………………………………………. 6. Champ d’application du développement ou projet ……………………………

7. Objectifs visés

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

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

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

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

B. Logiciels ……………………

C. Services ……………………

11. Liste et brève description du rôle et de la part d’éventuels sous-traitants

A. Nom de l’ (des) entreprise(s) ……………………

B. Part du marché ……………………

C. Connaissances techniques ……………………

12. Complexité Nombre d’utilisateurs, nombre de systèmes IT sans PC (nombre de mainframes, de minis et de serveurs) …………………………………………………………………….

13. Liste et brève description des systèmes sources



C. Environnement de développement ……………………

14. Liste et brève description des systèmes pour la réalisation du projet



C. Environnement de développement ……………………

15. Gestion du projet Tool/méthode …………………………………………………………………….


Page 149 sur 149

16. Liste des profils alloués au projet ; nombre (TOTAL) de personnes et de jours-hommes pour tout le projet

Profil 1 ……………………

Profil 2 ……………………

Profil 3 ……………………

Profil 4 ……………………

Profil 5 ……………………

Profil ……………………

La présente déclaration concerne le marché public suivant :