Cahier spécial des charges :

Transcription

1 Cahier des charges S&L/AO/386/2014 1/217 Cahier spécial des charges : Appel d offres ouvert pour la maintenance des applications de l Administration Générale de la Fiscalité (SPF Finances). Publication au niveau européen Cahier spécial des charges n S&L/AO/386/2014 Ouverture des offres : 1 octobre 2015 à 14h30 Errata page 7 et 8

2 Cahier des charges S&L/AO/386/2014 2/217 Contenu A. DEROGATIONS GENERALES... 5 B. DISPOSITIONS GENERALES OBJET ET NATURE DU MARCHE DUREE DU CONTRAT POUVOIR ADJUDICATEUR INFORMATIONS COMPLEMENTAIRES DOCUMENTS REGISSANT LE MARCHE Législation Documents du marché INCOMPATIBILITES - CONFLITS D INTERETS INCOMPATIBILITES CONFLITS D INTERETS SESSION D INFORMATION A. ATTRIBUTION DROIT ET MODALITES D INTRODUCTION ET OUVERTURE DES OFFRES Droit et mode d introduction des offres Offres introduites par des moyens électroniques Documents qui ne peuvent être introduits par des moyens électroniques Modification ou retrait d une offre déjà introduite Ouverture des offres OFFRES Données à mentionner dans l offre Structure de l offre Durée de validité de l offre Documents et attestations à joindre à l offre PRIX DROIT D ACCES SELECTION QUALITATIVE REGULARITE DES OFFRES CRITERES D ATTRIBUTION Droit d accès et sélection qualitative Droit d accès Sélection qualitative Régularité des offres Critères qui seront utilisés lors de l évaluation des offres Liste des critères d attribution B. EXECUTION FONCTIONNAIRE DIRIGEANT REVISION DE PRIX RESPONSABILITE DU PRESTATAIRE DE SERVICES RECEPTION DES SERVICES PRESTES La livraison et l installation Spécifications techniques Suivi de la bonne exécution des livraisons et des services Contrôle et encadrement du marché ACCEPTATIONS PROVISOIRES Garantie Réception définitive Frais de réception CAUTIONNEMENT Constitution du cautionnement Libération du cautionnement Modalités d exécution Clause d exécution Clause d évolution technologique Lieu d exécution du marché et particularités Personnel de l adjudicataire Sous-traitants FACTURATION ET PAIEMENT LITIGES

3 Cahier des charges S&L/AO/386/2014 3/ AMENDES ET PENALITES Pénalités Amendes Imputation des amendes et pénalités C.PRESCRIPTIONS TECHNIQUES PRINCIPES GENERAUX DU MARCHE Introduction Objectifs généraux du marché MODE DE COLLABORATION ENTRE LOTS DE SUPPORT/DEVELOPPEMENT ET LOT DE TESTING INTEGRATION ENTRE LES APPLICATIFS FONCTIONNELLEMENT LIES AMELIORATION DE LA QUALITE DES APPLICATIONS (DISPONIBILITE, PERFORMANCE, OPTIMISATION, DOCUMENTATION, QUALITE DU CODE, CONSOMMATION DE RESSOURCES, ) SOUPLESSE ET REACTIVITE IMPLICATION DU PERSONNEL INTERNE ET RENFORCEMENT DE LA MAITRISE MAITRISE DES COUTS Vision et encadrement Economie générale du marché SEPARATION DES ASPECTS DEVELOPPEMENT/SUPPORT ET TESTING COMPOSITION DES LOTS INCOMPATIBILITE ENTRE LOTS COLLABORATION ENTRE LES EQUIPES DE LA COMPOSANTE «DEVELOPPEMENT ET PRISE D EFFET DE LA MAINTENANCE DESCRIPTION DES APPLICATIONS MODALITES D EXECUTION TRANSFERT DE CONNAISSANCE CO-SOURCING PERSONNEL MOBILISE PAR L ADJUDICATAIRE COMPOSANTE «DEVELOPPEMENT ET SUPPORT» (LOTS 1 A 4) Missions Mode d exécution au sein d un lot ÉVALUATION DES SERVICES EXECUTES SUPPORT TECHNIQUE PAR TELEPHONE SERVICE DESK ITIL Profils COMPOSANTE «TESTING (LOT 5) Missions Contexte ENVIRONNEMENT ORGANISATIONNEL REFERENCE ENVIRONNEMENT TECHNIQUE SPECIFIQUE AUX MISSIONS Méthodologie de travail Test tools arsenal Profils PROFILS TESTEURS ET QUALITY ASSURANCE COORDINATOR Compétences communes Profils spécifiques SLA INTRODUCTION PRINCIPE D ELABORATION DES SLA DANS LE CADRE DE CE MARCHE ET DELIVERABLES CORRESPONDANTS CONCEPT DE MASTER SLA - TEMPLATE SLA SPFFIN PROJET DE «DOSSIER ACCORDS ET PROCEDURES (DAP)» CONTENU PROJET DE TABLEAU DE KPI AVEC CLAUSES D AMENDE SERVICE LEVEL REPORTING (SLR) - RAPPORTAGE SUR LE NIVEAU DE SERVICE SERVICE QUALITY PLAN (SQP) PLAN DE QUALITE DE SERVICE SERVICE IMPROVEMENT PLAN (SIP) PLAN D AMELIORATION SERVICE LEVEL MANAGEMENT DELAIS ET MOYENS D ELABORATION DES DAP, APRES L ATTRIBUTION DU MARCHE ENCADREMENT SLA RELATION ENTRE SLA ET ITIL V GLOSSARY RELATION ENTRE LES SLA ET LES NORMES ET FONDEMENTS ICT DU SPF FINANCES GESTION ET CONTROLE DES SLA PRINCIPE DES QUALITY GATES DANS LES CYCLES DE DEVELOPPEMENT ENVIRONNEMENTS A SUPPORTER DANS LE CADRE DE CES SLA... 90

4 Cahier des charges S&L/AO/386/2014 4/ SERVICE LEVELS ET ENGAGEMENTS DE RESULTATS CORRESPONDANTS DANS LE CADRE DE CE MARCHE SERVICE LEVELS RELATIFS A LA GESTION DE PROJET : DELAI, EXHAUSTIVITE ET PLANIFICATION PI-PROJECT-BID-DELIVERY-PERIOD PI-BID-COMPLETENESS COMPOSITION MINIMALE DU LOT DESCRIPTION PI-PROJECT PLAN-PLANNING NIVEAUX DE SERVICE PHASE DE DEVELOPPEMENT : CONFORMITE A LA METHODOLOGIE FUP, AUX STANDARDS ICT ET QUALITE DU CODE PI-FUP-DELIVERABLES PI-FUP-TOOLS & ICT- STANDARDS PI-QUALITY-OF-CODE PI-SECURITY-INTEGRITY-CODE SERVICE LEVELS MISE EN PRODUCTION PI-CONTINUOUS-INTEGRATION-TOOL-CHAIN PI-RELEASES-IN-PRODUCTION SERVICE LEVELS EXIGENCES NON FONCTIONNELLES PI AVAILIBILITY-7X24X365 ET PI-AVAILIBILITY-5X PERIODES D OUVERTURE DU SERVICE (SERVICE WINDOW) ET PERIODES DE MAINTENANCE DANS LE CADRE DE CES SLA SERVICE WINDOWS PAR CATEGORIE D APPLICATIONS NORMES PI AVAILIBILITY-7X24X365 ET PI-AVAILIBILITY-5X CLAUSES D AMENDE PI AVAILABILITY PI-PERFORMANCE SERVICE LEVELS EN MATIERE DE TRAITEMENT D INCIDENTS, D INTERVENTIONS CORRECTRICES ET REACTIVES PRIORITES DES INCIDENTS MATRICE DE PRIORITES PI-INCIDENT-RESPONSE-TIME PI-INCIDENT-RESOLUTION-TIME SERVICE LEVELS CONCERNANT LES SERVICES DU PERSONNEL MIS A DISPOSITION PAR L ENTREPRENEUR PI-BID-REACTIVENESS PI-STAFF-TIMESHEET SERVICE LEVELS CONCERNANT LE LOT 5 TESTING APERÇU KPI TEST PROJECT PI-TEST-EXECUTION-RATIO PI-ACTUALIZED-TESTING-EFFORT- BURN- DOWN-RATE (MANAGEMENT KPI) KPI S TEST QUALITY PI-TEST-EXECUTION-COVERAGE PI-TEST-BUILD-COVERAGE PI-DEFECT-DETECTION-RATIO KPI TESTING PROCESS PERFORMANCE PI-TEST-EFFICIENCY PI-TEST-CASE-AUTOMATION PERIODES D APPLICATION DES DIFFERENTS SLA SANCTIONS PRINCIPE DES PROPOSITIONS D AMENDES TABLEAU DES CLAUSES DE PENALITE SLA MONITORING, RAPPORTAGE ET ANALYSE, CONCERTATION DU SERVICE MANAGEMENT SLA-MONITORING MONITORING DE BASE AU SEIN DU SPF FINANCES ASSISTANCE DANS LE CADRE DU MONITORING PAR L ADJUDICATAIRE RAPPORTAGE SLA, REVIEWS, IP-SLR RAPPORTAGE SERVICE LEVEL (SLR) GENERAL PI-SLR CONCERTATION SERVICE MANAGEMENT AUTRES SERVICE LEVELS, OBLIGATIONS DE RESULTATS ET CONCLUSION C. ANNEXES ANNEXE 1 : FORMULAIRE D offre ANNEXE 2: Modèle de référence ANNEXE 3.a.: Curriculum vitae - INDIVIDUEL ANNEXE 3.B.: Curriculum vitae - SYNTHESE

5 Cahier des charges S&L/AO/386/2014 5/217 ANNEXE 4: SLA a completer ANNEXE 5 DESCRIPTIF DES APPLICATIONS ANNEXE 6 : SLA TEMPLATE ANNEXE 7 : CYCLE DE MAINTENANCE 215 SERVICE PUBLIC FEDERAL Finances Service d Encadrement Logistique Division Achats North Galaxy Tour B4 bte 961 Boulevard du Roi Albert II, BRUXELLES CAHIER SPÉCIAL DES CHARGES n S&L/AO/386/2014 APPEL D OFFRES OUVERT POUR LA MAINTENANCE DES APPLICATIONS DE L ADMINISTRATION GENERALE DE LA FISCALITE (SPF FINANCES). A. DEROGATIONS GENERALES IMPORTANT En application de l article 9, paragraphe 4, de l AR du 14 janvier 2013 établissant les règles générales d'exécution des marchés publics et des concessions de travaux publics, l attention des soumissionnaires est attirée sur le fait que, dans le présent cahier spécial des charges, il a été dérogé aux articles : de l arrêté royal du 14 janvier 2013 relatifs aux amendes ; - 25 de l arrêté royal du 14 janvier 2013 relatifs au cautionnement. 1. Objet et nature du marché. B. DISPOSITIONS GENERALES Le présent appel d offres ouvert a pour but de réaliser la maintenance des applications de l Administration Générale de la Fiscalité (SPF Finances). La procédure de l appel d offres ouvert avec publicité européenne est choisie. Le présent marché comporte 5 (cinq) lots : - Lot 1 : Développement/support opérationnel des applications de l'administration Générale de la Fiscalité - Domaine TVA - Lot 2 : Développement/support opérationnel des applications de l'administration Générale de la Fiscalité - Domaine Impôts des Personnes Physiques (Impôts des personnes physiques et des non-résidents) - Lot 3 : Développement/support opérationnel des applications de l'administration Générale de la Fiscalité - Domaine Impôts des Personnes Morales (Impôt des Sociétés, Impôt des Personnes morales et Impôt des Sociétés non résidentes) et domaine transversal (par exemple Précompte mobilier et épargne à long terme)

6 Cahier des charges S&L/AO/386/2014 6/217 - Lot 4 : Développement/support opérationnel des applications de l'administration Générale de la Fiscalité - Domaine STIRINT - Lot 5 : Test des applications de l Administration Générale de la Fiscalité Le lot 5 ne pourra pas être attribué à un adjudicataire des lots 1, 2, 3 et 4. Le contenu applicatif de chacun des lots 1 à 4 est déterminé par le domaine d activité précisé notamment dans sa dénomination (objet du marché). L attention est attirée sur le fait que la liste (applications par lot) communiquée au présent document est ouverte. La maintenance d une application non listée sera rattachée par le SPF à l un des 4 lots, tenant compte de la même règle. En cas de situation indécise (application à la frontière entre plusieurs lots), le SPF Finances reste seul décisionnaire en la matière. Il s agit d un marché à bordereau de prix (A.R. 15 juillet 2011, art. 2, 5 ). Les variantes ne sont pas autorisées. Ce marché est composé de cinq lots. L estimation budgétaire annuelle (TVAC) pour ces lots est la suivante : lot 1 : lot 2 : lot 3 : lot 4 : lot 5 : Ces montants sont donnés à titre indicatif, ils ne constituent pas un engagement pour le SPF FINANCES. 2. Durée du contrat. Le contrat prend cours le 1 er jour qui suit la date de la notification de l attribution du marché et est conclu pour une durée de sept (7) ans. Cette durée de sept (7) ans est la période au cours de laquelle les commandes peuvent être remises au prestataire de services. Chaque partie peut mettre fin au contrat à la fin de la première, de la deuxième de la troisième, de la quatrième, de la cinquième ou de la sixième année à condition que la notification à l autre partie soit faite par lettre recommandée: - au moins (3) trois mois avant la fin de l année en cours si le pouvoir adjudicateur met fin au contrat, - au moins (6) six mois avant la fin de l année en cours si l adjudicataire met fin au contrat. Par ailleurs, le pouvoir adjudicateur se réserve le droit, moyennant un préavis de 30 jours de calendrier à signifier par lettre recommandée, de mettre fin à tout ou une partie de chacun

7 Cahier des charges S&L/AO/386/2014 7/217 des contrats en cas d abandon d un lot, en tout temps, de plein droit et sans indemnité pour le prestataire. Dans ces deux cas, la partie qui subit la résiliation du contrat ne peut réclamer de dommages et intérêts. 3. Pouvoir adjudicateur Informations complémentaires. Le pouvoir adjudicateur est l Etat belge, représenté par le Ministre des Finances. Pour des renseignements complémentaires sur le cahier spécial des charges ou pour toute remarque, les candidats-soumissionnaires peuvent prendre contact via l adresse log.daa.t2@minfin.fed.be. 4. Documents régissant le marché 4.1. Législation - La loi du 15 juin 2006 relative aux marchés publics et à certains marchés de travaux, de fournitures et de services - La loi du 17 juin 2013 relative à la motivation, à l information et aux voies de recours en matière de marchés publics et de certains marchés de travaux, de fournitures et de services - L arrêté royal du 15 juillet arrêté royal relatif à la passation des marchés publics dans les secteurs classiques - L arrêté royal du 14 janvier arrêté royal établissant les règles générales d'exécution des marchés publics et des concessions de travaux publics - Le Règlement Général sur la Protection du Travail (RGPT) et le Code sur le bien-être au travail; - La réglementation de l Union européenne relative aux marchés publics de services; - La loi du 4 août 1996 relative au bien-être des travailleurs lors de l exécution de leur travail; - Toutes les modifications à la loi et aux arrêtés précités, en vigueur au jour de l ouverture des offres Documents du marché - Les avis de marché et avis rectificatifs publiés au Bulletin des Adjudications ou au Journal Officiel de l'union européenne qui ont trait à ce marché, font partie intégrante du présent marché. Le soumissionnaire est censé en avoir pris connaissance et en avoir tenu compte lors de l établissement de son offre; - Le présent cahier spécial des charges n S&L/AO/3 86/ Les offres approuvées des soumissionnaires. 5. Incompatibilités - conflits d intérêts 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.

8 Cahier des charges S&L/AO/386/2014 8/ Conflits d intérêts Dans le cadre de la lutte contre les conflits d'intérêts, en particulier afin d'éviter le mécanisme du tourniquet (`revolving doors'), tel que défini dans la loi du 8 mai 2007 portant assentiment à la Convention des Nations unies contre la corruption, faite à New York le 31 octobre 2003, le soumissionnaire s'abstient de faire appel à un ou plusieurs anciens collaborateurs (internes ou externes) du SPF Finances, dans les deux ans qui suivent son/leur démission, départ à la retraite ou tout autre type de départ du SPF Finances, d'une quelconque manière, directement ou indirectement, pour l'élaboration et/ou l'introduction de son offre ou toute autre intervention dans le cadre de la procédure de passation, ainsi que pour certaines tâches à réaliser dans le cadre de l'exécution du présent marché. La disposition qui précède ne s'applique toutefois que lorsqu'un lien direct existe entre les précédentes activités prestées pour le pouvoir adjudicateur par la ou les personnes concernées et ses/leurs activités dans le cadre du présent marché. Toute infraction à cette mesure pouvant être de nature à fausser les conditions normales de la concurrence est passible d'une sanction conformément aux dispositions de l'article 9 de la loi du 15 juin 2006 relative aux marchés publics et à certains marchés de travaux, de fournitures et de services (ou, pour un marché dans les domaines de la défense et de la sécurité, de l'article 10 de la loi du 13 août 2011 relative aux marchés publics et à certains marchés de travaux, de fournitures et de services dans les domaines de la défense et de la sécurité). Concrètement, cette sanction consiste, selon le cas, soit à écarter l'offre, soit à résilier le marché. 6. Session d information. Pour le présent marché, le pouvoir adjudicateur organisera une session d information à l intention des soumissionnaires. Cette session d information se déroulera le 2 septembre 2015 dans l une des salles du bâtiment «North Galaxy» situé Boulevard du Roi Albert II, 33 à 1030 Bruxelles. Il sera répondu aux questions posées préalablement. Afin de permettre un déroulement correct de la session d information, les candidats potentiels qui souhaitent y assister sont priés de faire parvenir leurs questions au pouvoir adjudicateur par courrier électronique à l adresse suivante : log.daa.t2@minfin.fed.be. en mentionnant la référence et l objet du marché. Seules les questions qui seront parvenues au pouvoir adjudicateur au plus tard le 24 août 2015 à 17 h.00 avant la session d information seront traitées pendant cette session. A l entrée de la salle de réunion, il sera demandé aux participants d indiquer l identité de l entreprise qu ils représentent ainsi que leur adresse complète sur une liste de présence. Un participant ne pourra être représenté par plus de deux personnes lors de la session d information.

9 Cahier des charges S&L/AO/386/2014 9/217 C.ATTRIBUTION 1. Droit et modalités d introduction et ouverture des offres 1.1. Droit et mode d introduction des offres En application de l article 52, 2, de l arrêté royal du 15 juillet 2011, le pouvoir adjudicateur impose l utilisation de moyens électroniques pour l introduction des offres. Par conséquent, les offres doivent être introduites électroniquement via l application e- tendering (voir ci-dessous pour plus d informations) Offres introduites par des moyens électroniques Lorsque des moyens électroniques sont utilisés pour l introduction de l offre, la signature électronique doit être conforme aux règles du droit européen et du droit national y correspondant relatives à la signature électronique avancée accompagnée d un certificat qualifié et valide, et réalisée au moyen d un dispositif sécurisé de création de signature (article 52, 1er, 1 de l arrêté royal du 15 juil let 2011). Les offres qui sont introduites par des moyens électroniques, doivent être envoyées via le site internet e-tendering qui garantit le respect des conditions de l article 52 de l arrêté royal du 15 juillet Vu que l envoi d une offre par ne correspond pas aux conditions de l article 52 de l arrêté royal du 15 juillet 2011, il n est pas admis d introduire une offre de cette manière. Si nécessaire, les attestations comme demandées dans les documents du marché, sont scannées en PDF, afin de les joindre à l offre. Certains documents à joindre qui ne peuvent pas être produits ou qui peuvent être difficilement produits par des moyens électroniques, peuvent être délivrés sur papier avant la date limite d ouverture des offres. En introduisant son offre entièrement ou partiellement via des moyens électroniques, le soumissionnaire accepte que les données qui résultent du fonctionnement du système de réception de son offre, soient enregistrées. Plus d'informations peuvent être obtenues sur le site: ou via le numéro de téléphone du helpdesk du service e-procurement: +32 (0) 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 2. Il doit être tenu compte de la taille du fichier introduite par voie électronique ; celui-ci ne doit pas dépasser 350 Mo.

10 Cahier des charges S&L/AO/386/ / Documents qui ne peuvent être introduits par des moyens électroniques Les documents qui ne peuvent être introduits par des moyens électroniques sont glissés dans une enveloppe fermée. L enveloppe fermée sera déposée par le soumissionnaire ou son représentant soit: - le jour de la séance d ouverture, en mains propres au président, avant que celui-ci n ouvre la séance; - en mains propres à un fonctionnaire de la Division Achats, au plus tard le jour ouvrable précédant la date de l ouverture des offres; - à la poste. Toute autre modalité d expédition (comme Taxipost, courrier exprès, etc.) se fera sous l entière responsabilité du soumissionnaire. Les documents sont acceptés pour autant que la séance d ouverture des offres n ait pas été déclarée ouverte. Toutefois, une enveloppe arrivée tardivement est prise en considération pour autant: - que le pouvoir adjudicateur n'ait pas encore notifié sa décision à l'adjudicataire, - et que l enveloppe ait été déposée à la poste sous pli recommandé, au plus tard le quatrième jour de calendrier précédant le jour fixé pour la réception des offres. Les documents seront déposés en deux exemplaires sur papier dont un original. Les documents seront glissés dans une enveloppe fermée portant les deux indications suivantes - la référence du cahier spécial des charges : S&L/AO/386/ a date et l heure de l ouverture des offres : le 1 octobre 2015 à 14u30 Ce pli scellé est glissé dans une seconde enveloppe portant les mentions suivantes: - dans le coin supérieur gauche: - le mot «OFFRE» - la référence du cahier spécial des charges : S&L/AO/386/ si la soumission est déposée par porteur, les données relatives aux personnes de contact chargées de la réception des offres: OPDECAM Christine 0257/63482 VAN OVERWAELLE Wendy 0257/68347 AUBRY Céline 0257/89634 DEBANDE Michaël 0257/79775 DE PROOST Patricia 0257/ à l endroit prévu à cet effet l adresse du destinataire. Le soumissionnaire qui remet son enveloppe par porteur doit savoir que le North Galaxy n est accessible que par l entrée «visiteurs» située au rez-de-chaussée, boulevard du Roi Albert II, 33 à 1030 BRUXELLES et ce, uniquement pendant les heures de bureau soit de 9 à 11h45 et de 14 à 16 heures. Si l enveloppe est déposée par porteur, un accusé de réception ne sera délivré que si la demande en est faite expressément. Il est important de noter que seul cet accusé de réception peut servir de preuve du dépôt de l enveloppe.

11 Cahier des charges S&L/AO/386/ /217 Le soumissionnaire assume l entière responsabilité des modalités d envoi et de réception de son enveloppe dans les délais impartis. Les enveloppes doivent être expédiées ou déposées à l adresse suivante: Service Public Fédéral FINANCES Service d Encadrement Logistique Division Achats A l attention de Monsieur Pierre THONON, Conseiller North Galaxy - Tour B4 Boulevard du Roi Albert II, 33 - Boîte BRUXELLES 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 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 Ouverture des offres La séance d ouverture des offres aura lieu le 1 octobre 2015 à 14h30, dans une des salles de réunion du North Galaxy, accessible via l entrée «visiteurs», boulevard du Roi Albert II, 33 à 1030 BRUXELLES. Chaque offre doit parvenir au président de la séance avant qu il ne déclare la séance ouverte. Seules les offres qui parviennent au président de la séance avant qu il ne déclare la séance ouverte, peuvent être acceptées. Toutefois, une offre tardive est acceptée pour autant que le pouvoir adjudicateur n ait pas encore conclu le marché et que l offre ait été envoyée sous pli recommandé au plus tard quatre jours calendrier avant la date de la séance d ouverture.

12 Cahier des charges S&L/AO/386/ / Offres 2.1. Données à mentionner dans l offre Il est fortement recommandé au soumissionnaire d utiliser le formulaire d offre. Dans cette optique, l attention du soumissionnaire est attirée sur l article 80 de l arrêté royal du 15 juillet 2011, qui stipule: "Lorsqu aux documents du marché est joint un formulaire destiné à établir l offre et à compléter le métré récapitulatif ou l inventaire, le soumissionnaire en fait usage. A défaut d utiliser ce formulaire, il supporte l entière responsabilité de la parfaite concordance entre les documents qu il a utilisés et le formulaire". L offre et les annexes jointes au formulaire d offre sont rédigées en français ou en néerlandais. Par le dépôt de son offre, le soumissionnaire renonce automatiquement à ses conditions générales ou particulières de vente, même si celles-ci sont mentionnées dans l une ou l autre annexe à son offre. Le soumissionnaire indique clairement dans son offre quelle information est confidentielle et/ou se rapporte à des secrets techniques ou commerciaux et ne peut donc pas être divulguée par le pouvoir adjudicateur. Les renseignements suivants seront mentionnés dans l offre : - les montants unitaires de l offre en lettres et en chiffres (hors TVA) ; - les montants unitaires de l offre en lettres et en chiffres (TVA incluse) ; - l ordre de priorité des lots ; - la signature de la personne ou les personnes, selon le cas, ayant mandat pour signer l offre ; - la qualité de la personne ou des personnes, selon le cas, qui signe(nt) l offre ; - la date à laquelle la personne ou les personnes précitée(s), selon le cas, a/ont signé l offre ; - le numéro d immatriculation complet du soumissionnaire auprès de la Banque Carrefour des Entreprises (pour les soumissionnaires belges) ; - le numéro d inscription à l ONSS ; - le numéro et le libellé du compte du soumissionnaire ouvert auprès de la Banque de la Poste ou d un autre établissement financier ; - les nom, prénoms, la qualité ou profession, la nationalité et le domicile du soumissionnaire ou lorsque celui-ci est une société, sa raison sociale ou dénomination, sa forme juridique, sa nationalité et son siège social ; - tous les éléments et documents nécessaires pour l évaluation des offres Structure de l offre L offre du soumissionnaire se compose obligatoirement de trois volets distincts, pour chaque lot auquel il soumissionne : Volet A «Volet administratif» Ce volet se compose des éléments suivants : I. Formulaire d offre Le soumissionnaire présente dans ce chapitre les pièces suivantes dans l ordre imposé :

13 Cahier des charges S&L/AO/386/ / Le formulaire d offre complété, daté et signé ; 2. Pour toute offre introduite par un mandataire, l acte authentique ou sous seing privé (ou une copie de cet acte) joint par le mandataire prouvant qu il est habilité à engager l entité pour laquelle il soumissionne. Le mandataire peut également mentionner le numéro de l'annexe au Moniteur belge à laquelle est publié le mandat. II. Documents relatifs aux critères de sélection Le soumissionnaire présente dans ce chapitre les pièces suivantes : 1. Documents relatifs aux critères de sélection permettant d évaluer la capacité financière et économique du soumissionnaire : - La déclaration quant aux chiffres d affaires concernant les services auxquels se réfère le marché et réalisés au cours des trois dernières années. 2. Documents relatifs aux critères de sélection permettant d évaluer la capacité technique du soumissionnaire : - Les références relatives à des prestations d un niveau au moins équivalent exigées au point «sélection qualitative» du volet C. Attribution du cahier spécial des charges. Pour communiquer ces références, le soumissionnaire fait usage du modèle joint en annexe 2 de ce cahier spécial des charges. Volet B «Volet technique» Dans ce volet, le soumissionnaire joint tous les éléments et documents techniques pour l évaluation de l offre. Volet C «Annexes» Dans ce volet, le soumissionnaire joint l ensemble des annexes et des documents utiles non exigés dans les volets précédents Durée de validité de l offre Les soumissionnaires restent liés pendant un délai de 240 jours à compter du premier jour calendrier qui suit le jour de l ouverture des offres déposées Documents et attestations à joindre à l offre Les soumissionnaires joignent à leur offre: - tous les documents demandés dans le cadre des critères de sélection et des critères d attribution (voir rubrique 5 du volet C. Attribution) ; - les statuts ainsi que tout autre document utile prouvant le mandat du (des) signataire(s). 3. Prix. Le présent marché est un marché à bordereau de prix. Le prestataire de services est censé avoir inclus dans son prix global tous les frais possibles grevant les services, à l exception de la TVA.

14 Cahier des charges S&L/AO/386/ /217 Le prix proposé constituera un montant forfaitaire avec possibilité de révision de prix pendant la durée totale du marché telle qu elle résulte du point 2. Révision de prix, du volet «D. Exécution». L inventaire ainsi que le formulaire d offre, joint au modèle de soumission (en annexe 1), doit, sous peine de nullité, être entièrement et correctement rempli. Tous les prix seront obligatoirement mentionnés en euros. 4. Droit d accès Sélection qualitative Régularité des offres Critères d attribution 4.1. Droit d accès et sélection qualitative Les soumissionnaires sont évalués sur base du droit d accès et de la sélection qualitative repris ci-après. Seules les offres des soumissionnaires qui satisfont au droit d accès et à la sélection qualitative sont prises en considération pour participer à la comparaison des offres sur la base des critères d attribution repris au point 5.3.du volet C. Attribution du présent cahier spécial des charges, dans la mesure où ces offres sont régulières sur le plan formel et matériel Droit d accès Par le dépôt de son offre, le soumissionnaire atteste qu il ne se trouve pas dans un des cas d exclusion figurant ci-dessous. Le pouvoir adjudicateur vérifiera l exactitude de cette déclaration sur l honneur implicite dans le chef du soumissionnaire dont l offre est la mieux classée. A cette fin, il demandera au soumissionnaire concerné par les moyens les plus rapides, et dans le délai qu il détermine, de fournir les renseignements ou documents permettant de vérifier sa situation personnelle. Le pouvoir adjudicateur demandera lui-même les renseignements ou documents qu il peut obtenir gratuitement par des moyens électroniques auprès des services qui en sont gestionnaires. Premier critère d exclusion 1er Le soumissionnaire belge qui emploie du personnel assujetti à la loi du 27 juin 1969 révisant l arrêté-loi du 28 décembre 1944 concernant la sécurité sociale des travailleurs, doit être en ordre en ce qui concerne ses obligations vis-à-vis de l Office National de Sécurité Sociale. Il est considéré comme étant en ordre en ce qui concerne les obligations précitées, s il apparaît, qu au plus tard la veille de la date limite de réception des offres, il: 1 a transmis à l Office National de Sécurité Socia le toutes les déclarations requises jusque et y compris celles relatives à l avant-dernier trimestre civil écoulé par rapport à la date limite de réception des offres et 2 n a pas pour ces déclarations une dette en coti sations supérieure à EUROS, à moins qu il n ait obtenu pour cette dette des délais de paiement qu il respecte strictement. Toutefois, même si la dette en cotisations est supérieure à EUROS, le soumissionnaire sera considéré comme étant en règle s il établit, avant la décision d attribuer le marché, qu il possède, à la fin du trimestre civil visé à l alinéa 2, à

15 Cahier des charges S&L/AO/386/ /217 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, à EUROS près, à celui pour lequel il est en retard de paiement de cotisations. 2. Le soumissionnaire étranger doit, au plus tard la veille de la date limite de réception des offres: 1 être en règle avec ses obligations relatives au paiement des cotisations de sécurité sociale selon les dispositions légales du pays où il est établi 2 être en ordre avec les dispositions du 1er, s il emploie du personnel assujetti à la loi du 27 juin 1969 révisant l arrêté-loi du 28 décembre 1944 concernant la sécurité sociale des travailleurs. 3. A quelque stade de la procédure que ce soit, le pouvoir adjudicateur peut s informer, par tous moyens qu il juge utiles, de la situation en matière de paiement des cotisations de sécurité sociale de tout soumissionnaire. Deuxième critère d exclusion Conformément à l article 20 de la loi du 15 juin 2006, est exclu de l accès au marché, à quelque stade que ce soit de la procédure, le soumissionnaire qui a fait l objet d une condamnation prononcée par une décision judiciaire ayant force de chose jugée dont le pouvoir adjudicateur a connaissance pour: 1 participation à une organisation criminelle tell e que définie à l article 324bis du Code pénal 2 corruption, telle que définie aux articles 246 e t 250 du Code pénal 3 fraude au sens de l article 1er de la convention relative à la protection des intérêts financiers des communautés européennes, approuvée par la loi du 17 février blanchiment de capitaux tel que défini à l artic le 5 de la loi du 11 janvier 1993 relative à la prévention de l utilisation du système financier aux fins du blanchiment de capitaux et du financement du terrorisme. En vue de l application du présent paragraphe, le pouvoir adjudicateur a le droit de demander aux soumissionnaires de fournir les renseignements ou documents nécessaires. Lorsqu il a des doutes sur la situation personnelle de ces candidats ou soumissionnaires, il peut s adresser aux autorités compétentes belges ou étrangères pour obtenir les informations qu il estime nécessaires à ce propos. Troisième critère d exclusion Sera exclu de l accès au marché, à quelque stade que ce soit de la procédure, le soumissionnaire: 1 qui est en état de faillite, de liquidation, de cessation d activités, de réorganisation judiciaire ou dans toute situation analogue résultant d une procédure de même nature existant dans d autres réglementations nationales

16 Cahier des charges S&L/AO/386/ /217 2 qui a fait l aveu de sa faillite ou fait l objet d une procédure de liquidation, de réorganisation judiciaire ou de toute autre procédure de même nature existant dans d autres réglementations nationales. Quatrième critère d exclusion Sera exclu de la participation au marché public, le soumissionnaire qui a fait l objet d une condamnation prononcée par une décision judiciaire ayant force de chose jugée pour tout délit affectant sa moralité professionnelle. Cinquième critère d exclusion Le soumissionnaire ne peut pas, en matière professionnelle, avoir commis une faute grave, constatée par tout moyen dont le pouvoir adjudicateur pourra justifier. En outre, le soumissionnaire, par la signature de son offre, s engage à respecter les normes définies dans les conventions de base de l Organisation Internationale du Travail (OIT) et, en particulier: 1 l interdiction du travail forcé (conventions n 29 concernant le travail forcé ou obligatoire, 1930, et n 105 sur l abolition du travail forcé, 1 957) 2 le droit à la liberté syndicale (convention n 8 7 sur la liberté syndicale et la protection du droit syndical, 1948) 3 le droit d organisation et de négociation collec tive (convention n 98 sur le droit d organisation et de négociation collective, 1949) 4 l interdiction de toute discrimination en matièr e de travail et de rémunération (conventions n 100 sur l égalité de rémunération, 1951 et n 11 1 concernant la discrimination (emploi et profession), 1958) 5 l âge minimum fixé pour le travail des enfants ( convention n 138 sur l âge minimum, 1973), ainsi que l interdiction des pires formes du travail des enfants (convention n 182 sur les pires formes du travail des enfants, 1999). Le non-respect des conventions susmentionnées sera donc considéré comme faute grave en matière professionnelle au sens de l article 61, 2, 4 de l arrêté royal du 15 juillet Les dispositions qui précèdent s appliquent sans préjudice des autres dispositions reprises à l article 61 de l arrêté précité. Sixième critère d exclusion Le soumissionnaire doit être en règle avec ses obligations relatives au paiement de ses impôts et taxes selon la législation belge ou celle du pays dans lequel il est établi. Est en règle par rapport aux obligations susmentionnées applicables en Belgique, le candidat ou le soumissionnaire qui n'a pas pour l'ensemble de ses obligations fiscales professionnelles une dette supérieure à 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 à euros, le candidat ou le soumissionnaire est considéré comme étant en règle s'il établit, avant la décision de sélection ou d'attribution du marché, selon le cas, qu'il possède à l égard d un pouvoir adjudicateur au sens de l article 2,1, de la loi o u d une entreprise publique au sens de

17 Cahier des charges S&L/AO/386/ /217 l article 2,2, de la loi, à la fin de la période f iscale visée précédemment, une ou des créances certaines, exigibles et libres de tout engagement à l'égard de tiers pour un montant au moins égal, à euros près, à celui pour lequel il est en retard de paiement de ses dettes fiscales professionnelles. Pour le soumissionnaire ou le candidat belge, le pouvoir adjudicateur procèdera lui-même à la vérification des obligations en matière d impôts et taxes. Pour que le soumissionnaire étranger ou le candidat étranger soit considéré comme étant en règle celui-ci joint à sa demande de participation ou à son offre, selon le cas, une attestation dont il résulte qu'il est en règle par rapport à ses obligations fiscales professionnelles selon les dispositions légales du pays où il est établi. Cette attestation doit porter sur la dernière période fiscale écoulée avant la date limite de réception des demandes de participation ou des offres, selon le cas. Septième critère d exclusion Sera exclu de la participation au marché public, le soumissionnaire qui s est rendu gravement coupable de fausses déclarations en fournissant des renseignements exigibles en application du présent chapitre ou qui n a pas fourni ces renseignements Sélection qualitative Critères de sélection relatifs aux moyens financiers du soumissionnaire (article 67, 3 de l arrêté royal du 15 juillet 2011) IMPORTANT Pour les soumissionnaires introduisant une offre pour plusieurs lots, les exigences imposées dans les critères de sélection relatifs aux moyens financiers sont cumulatives. En d autres termes, s il remet une offre pour plusieurs lots, le soumissionnaire doit avoir réalisé un chiffre d affaires annuel au moins égal à la somme des chiffres d affaires annuels exigés par lot pour lequel il soumissionne. A défaut de justifier un chiffre d affaires suffisant pour l ensemble des lots pour lesquels il remet une offre mais suffisant pour soumissionner pour un ou plusieurs lots parmi ceux qu il a choisis, le soumissionnaire indique dans le formulaire d offre l ordre de priorité des lots pour lesquels il soumissionne. En l absence d une indication de cette priorité, le pouvoir adjudicateur procèdera par tirage au sort. Un soumissionnaire peut, le cas échéant et pour des marchés déterminés, faire valoir les capacités d autres entités, quelle que soit la nature juridique de son lien avec ces entités (un sous-traitant par exemple). Il doit, dans ce cas, prouver au pouvoir adjudicateur que, pour l'exécution du marché, il disposera des moyens nécessaires par la production de l'engagement de ces entités de mettre de tels moyens à la disposition de l adjudicataire. Le soumissionnaire doit avoir réalisé au cours de chacun des trois derniers exercices comptables un chiffre d affaires annuel relatif aux activités directement liées aux services décrits dans le présent cahier spécial des charges, d au moins : Pour le lot 1 : ,00 EUR Pour le lot 2 : ,00 EUR

18 Cahier des charges S&L/AO/386/ /217 Pour le lot 3 : ,00 EUR Pour le lot 4 : ,00 EUR Pour le lot 5 : ,00 EUR. Il joindra à son offre une déclaration relative à ces chiffres d affaires réalisés pendant les trois derniers exercices. Les entreprises étrangères doivent joindre également à leur offre les comptes annuels approuvés des trois dernières années ou un document reprenant tous les actifs et tous les passifs de l entreprise. Au cas où l entreprise n a pas encore publié de compte annuel, un bilan intermédiaire certifié conforme par le comptable ou par le réviseur d entreprise ou par la personne ou l organisme qui exerce ce type de fonction dans le pays concerné suffit. Critère de sélection se rapportant à la compétence technique du soumissionnaire (article 72, 7 de l arrêté royal d u 15 juillet 2011) IMPORTANT Pour les lots 1, 2, 3, 4 et 5, un dossier incomplet ne sera pas pris en considération comme une référence valable. Pour les lots 1 à 4 : Le soumissionnaire doit disposer, au cours des trois dernières années, au minimum de 3 références similaires, d une charge annuelle d au moins : Pour le lot 1 : 1000 jours/homme. Pour le lot 2 : 1000 jours/homme. Pour le lot 3 : 1000 jours/homme. Pour le lot 4 : 1000 jours/homme. Pour démontrer le caractère similaire, le soumissionnaire remplit le tableau en annexe du présent marché autant de fois que de références présentées, en indiquant au minimum l objet de la référence, le montant, la charge jours/hommes la date d exécution des prestations et le destinataire public ou privé. Ces références sont en outre accompagnées : - pour ce qui concerne les références publiques : d une attestation de bonne exécution établie ou contresignée par l autorité concernée ; - pour ce qui concerne les références privées : d une déclaration sur l honneur du candidat attestant que lesdites références ont été dûment exécutées, conformément aux exigences reprises ci-dessus. Parmi ces références, une devra être présentée sous la forme d un dossier complet. Ce dossier mentionnera les informations suivantes : - Nom et adresse de la société ainsi que le nom, le numéro de téléphone et adresse mail d'une personne de contact chez le client (par exemple le chef de projet ou le sponsor du projet) ; - Date de début et de fin du projet ;

19 Cahier des charges S&L/AO/386/ /217 - Objet du projet. Celui-ci devra être pertinent à l égard des objectifs prévus pour chacun des lots dans la partie «dispositions techniques et fonctionnelles» du présent cahier spécial des charges ; - Budget du projet ; - Synopsis complet du projet ; - Complexité (nombre d entités, nombre d'utilisateurs clés, nombre d utilisateurs finaux,.) ; - Outils/méthode pour la gestion du projet ; - Outils/méthode pour l analyse ; - Outils/méthode pour le développement ; - Outils/méthode pour les tests ; - Outils/méthode pour la documentation ; - Outils/méthode visant à garantir un haut niveau de qualité des délivrables produits ; - Outils/méthodes pour garantir la communication et la coopération des autres équipes parties prenantes au projet (testing, production, Business ) ; - Listes des profils, nombre de personnes et d hommes/jours pour l ensemble du projet. Pour le lot 5 : Le soumissionnaire doit disposer, au minimum de 3 références de services exécutés, au cours des 3 dernières années satisfaisant aux conditions cumulatives suivantes : Sur les marchés informatiques où le contenu est similaire à celui du présent marché Software testing d'application d'au moins lignes de codes Comprenant au minimum des activités d assurance qualité et de tests de performance et fonctionnel (system testing) Pour démontrer cela, le soumissionnaire remplit le tableau en annexe 2 du présent marché autant de fois que de références présentées, en indiquant au minimum l objet de la référence, le montant, la charge jours/hommes la date d exécution des prestations et le destinataire public ou privé. Ces références sont en outre accompagnées : - pour ce qui concerne les références publiques : d une attestation de bonne exécution établie ou contresignée par l autorité concernée ; - pour ce qui concerne les références privées : d une déclaration sur l honneur du candidat attestant que les dites références ont été dûment exécutées, conformément aux exigences reprises ci-dessus. Parmi ces références, une devra être présentée sous la forme d un dossier complet. Ce dossier mentionnera les informations suivantes : - Nom et adresse de la société ainsi que le nom, le numéro de téléphone et adresse mail d'une personne de contact chez le client (par exemple le chef de projet ou le sponsor du projet) ; - Date de début et de fin du projet. - Objet du projet. Celui-ci devra être pertinent à l égard des objectifs prévus pour chacun des lots dans la partie «dispositions techniques et fonctionnelles» du présent cahier spécial des charges ; - Budget du projet. ; - Synopsis complet du projet ; - Complexité (nombre d entités, nombre d'utilisateurs clés, nombre d utilisateurs finaux,.) ; - Outils/méthode pour la gestion du projet ;

20 Cahier des charges S&L/AO/386/ /217 - Outils/méthode pour l analyse ; - Outils/méthode pour le développement ; - Outils/méthode pour les tests ; - Outils/méthode pour la documentation ; - Outils/méthodes pour garantir la communication et la coopération des autres équipes parties prenantes au projet (testing, production, Business ) ; - Listes des profils, nombre de personnes et d hommes/jours pour l ensemble du projet 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 Critères qui seront utilisés lors de l évaluation des offres Les offres régulières des soumissionnaires sélectionnés seront examinées dans le cadre d un certain nombre de critères. Ces critères seront pondérés afin d obtenir un classement final. IMPORTANT Pour les lots 1, 2, 3, 4 et 5, Une commission d évaluation attribue les points pour les critères d attribution. Le pouvoir adjudicateur se réserve le droit de faire appel pour l analyse des offres à un ou plusieurs expert(s) externe(s) au SPF Finances Liste des critères d attribution Pour les lots 1, 2, 3 et 4 : Par lot, le soumissionnaire retenu sera celui qui a introduit l offre la meilleure compte tenu des critères d attribution suivants : Critères Points I Prix 30 II Mode d exécution 50 (min 30) III SLA, garantie, maintenance 20 (min 12) Sous peine d exclusion, le soumissionnaire doit obtenir au moins 60% des points pour les critères II et III.

21 Cahier des charges S&L/AO/386/ /217 Pour le lot 5 : Pour ce lot, le soumissionnaire retenu sera celui qui a introduit l offre la meilleure compte tenu des critères d attribution suivants : Critères Points I Prix 30 II Mode d exécution Compréhension de la méthodologie de test 15 (min 10) 50 (min 30) Organisation équipe test par rapport à l environnement organisationnel du SPF Finances Partenariat garantie expertise sur nos standards 15 (min 10) 5 Capacité de mobilisation du personnel 15 (min 10) III SLA 20 (min 12) Pour le lot 5 : Sous peine d exclusion, le soumissionnaire doit obtenir au moins le minimum repris entre parenthèses pour chacun des sous-critères et 60 % pour les critères principaux II et III à l exception du troisième sous-critère «Partenariat garantie expertise sur nos standards» dans le deuxième critère «mode d exécution» Méthode de détermination de l offre la plus intéressante L évaluation des critères se fera comme suit : Pour les lots 1, 2, 3 et 4 I.Le prix 30 points Concernant l évaluation du critère d attribution «Prix», la formule suivante sera appliquée pour calculer les points : Mo = P x 30/100 Où Mo est le nombre de points obtenus par le soumissionnaire pour le critère «Prix» ; P est le résultat obtenu après l addition des différents profils pour l offre analysée ;

22 Cahier des charges S&L/AO/386/ /217 Prix profils Task Manager Senior Lead Technical Architect / Methodologist Senior Analyste Business / Métier expert Designer / Data Architect expert Développeur senior Total intermédiaire (P1+P2+P3+P4+P5) Points P1 (sur 10 points) P2 (sur 10 points) P3 (sur 25 points) P4 (sur 25 points) P5 (sur 30 points) P (100 points) Tous les prix doivent être exprimés en euro, TVAC et pour une journée de 8h. Prix profil Task Manager (10 points) Le critère Prix est pondéré de la façon suivante : Pr min P1 = 10 Pr offre où : Proffre = prix de l offre pour ce profil, Prmin = le prix de l offre la moins chère dans les offres régulières pour ce profil. P1 = points attribués au critère Prix profil Task Manager Les prix sont exprimés TVAC Prix profil Lead Technical Architect (10 points) Le critère Prix est pondéré de la façon suivante : Pr min P2 = 10 Pr offre où : Proffre = prix de l offre pour ce profil, Prmin = le prix de l offre la moins chère dans les offres régulières pour ce profil. P2 = points attribués au critère Prix profil Lead Technical Architect Les prix sont exprimés TVAC Prix profil Analyste Business / Métier Expert (25 points) Le critère Prix est pondéré de la façon suivante : Pr min P3 = 25 Pr offre où : Proffre = prix de l offre pour ce profil, Prmin = le prix de l offre la moins chère dans les offres régulières pour ce profil. P3 = points attribués au critère Prix profil Analyste Business / Métier Expert Les prix sont exprimés TVAC Prix profil Designer / Data Architect expert (25 points) Le critère Prix est pondéré de la façon suivante : Pr min P4 = 25 Pr offre où : Proffre = prix de l offre pour ce profil,

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

24 Cahier des charges S&L/AO/386/ /217 - B) points attribués à la clarté et à l évidence de l argumentaire et de la démonstration (en se basant essentiellement sur les standards et pratiques réputés du marché IT). - C) points attribués à l adéquation de la proposition aux besoins réels de l organisation (en se basant essentiellement sur l organisation, les standards et les fondements du SPF Finances, notamment les ABB Architecture Building Blocks). - D) points attribués sur la cohérence des propositions entre elles. Expression de la pondération des points pour chacun des 4 postes de chaque souscritère - Très bien : 100 % des points attribués au poste du sous-critère analysé - Bien : 75% des points attribués au poste du sous-critère analysé - Suffisant : 50% des points attribués au poste du sous-critère analysé - Faible : 20% des points attribués au poste du sous-critère analysé - Impossible à analyser : 0% des points attribués au poste du sous-critère analysé Au maximum 4 postes pour l ensemble des sous-critères, et au maximum un poste par souscritère, peuvent présenter une évaluation inférieure à la mention «suffisant», sous peine d exclusion de l offre. Chaque sous-critère doit au moins présenter un total pondéré de 50% des points (somme A+B+C+D par rapport au maximum attribuable), sous peine d exclusion de l offre. L exclusion d un seul sous-critère amène à l exclusion complète de l offre. Table des sous-critères Les sous-critères sont répartis en quatre parties, selon la pondération des postes pour chaque critère. Partie 1 Poste A 2.5 pts max Sous-critère Score % Score points II.1.Garantie continue des profils et de l expertise Poste B 2.5 pts max Score % Score points Poste C 2.5 pts max Score % Score points Poste D 2.5 pts max Score % Score points Maximum par ligne = A+B+C+D = 10 Total pondéré des points Partie 2 Poste A 3 pts max Sous-critères Score % Score points II.2.Mode d exécution Organisation de l équipe II.3.Mode d exécution Coopération avec le SPF Finances Poste B 3 pts max Score % Score points Poste C 3 pts max Score % Score points Poste D 1 pt max Score % Score points Maximum par ligne = A+B+C+D = 10 Total pondéré des points

25 Cahier des charges S&L/AO/386/ /217 II.4.Mode d exécution Coopération test ICT II.5.Mode d exécution Coopération requirements Business II.6.Mode d exécution Coopération test Business II.8.Mode d exécution Reporting régulier II.9. Compréhension et engagement quant aux standards II.10. Gestion de la configuration II.11.Documentation Partie 3 Poste A 2 pts max Sous-critère Score % Score points II.7.Mode d exécution Méthodologie pour les offres Poste B 2 pts max Score % Score points Poste C 3 pts max Score % Score points Poste D 3 pts max Score % Score points Maximum par ligne = A+B+C+D = 10 Total pondéré des points Partie 4 Poste A 3 pts max Sous-critères Score % Score points II.12.Coopération des rôles Poste B 3 pts max Score % Score points Poste C 2 pts max Score % Score points Poste D 2 pts max Score % Score points Maximum par ligne = A+B+C+D = 10 Total pondéré des points II.13. Gestion de programme Quelques exemples : Les exemples proposés sont fournis à titre d illustration et ne peuvent en aucun cas être opposables. Exemples chiffrés Poste A 2 pts max Poste B 2 pts max Poste C 3 pts max Poste D 3 pts max Maximum par ligne = A+B+C+D = 10 Sous-critères Score % Score points Score % Score points Score % Score points Score % Score points Total pondéré des points II.8.Mode 50% 1 75% % 3 20% d exécution Méthodologie pour les offres Le sous-critère n est pas exclu et reçoit la cote 6.1.

26 Cahier des charges S&L/AO/386/ /217 II.8.Mode d exécution Méthodologie pour les offres 20% % % % Le sous-critère est exclu en raison d un total insuffisant. Exclusion de l offre. II.8.Mode d exécution Méthodologie pour les offres 100% 20% (<50%) : 1 100% 0% (<50%): 2 EXCL. EXCL. (<50%) EXCLUSION EXCLUSION Deux postes ont une note inférieure à 50% pour unsous- critère donné Exclusion du sous-critère et exclusion de l offre. II.2.2.Mode d exécution Organisation de l équipe II.2.3.Mode d exécution Coopération avec le SPF Finances II.8.Mode d exécution Méthodologie pour les offres 100% 75% 20% 50% (<50%): 1 100% 100% 100% 20% 20% (<50%) : 3 (<50%) : 2 75% 100% 75% II Gestion de la configuration II.2.11.Documentatio n 50% 75% 100% 20% 100% 20% (<50%): 5 EXCL. (<50%): 4 EXCL 100% 50% EXCLUSION Plus de quatre postes ont une note inférieure à 50% pour l ensemble des sous-critères Exclusion de l offre. Sous-critère d attribution 1 : Garantie continue des profils et de l expertise Outre l engagement écrit relatif à la capacité de mobilisation et la stabilité de l équipe, la firme doit démontrer qu elle peut assurer la qualité des profils, et garantir la stabilité des profils, des équipes, des compétences et de l'expertise, notamment en cas de turnover du personnel, et ce, dans tous les types de profil. A cette fin, la firme décrit, dans son offre, une stratégie complète de staff management, de continuité, de gestion et de transfert de la connaissance et de la compétence, composée notamment de rôles et responsabilités (RACI) et des processus nécessaires. Sous-critère d attribution 2 : Mode d exécution Organisation de l équipe La firme doit démontrer qu elle peut assurer l organisation de l équipe quant à ses travaux de développement et de support, en ce compris les prestations réalisées en co-sourcing. Elle expose et démontre sa stratégie détaillée à ce sujet, et les bonnes pratiques précises qu elle mettra en œuvre. Elle détaille en outre un OBS où sont décrits rôles et responsabilité, en cohérence avec la structure organisationnelle actuelle du SPF Finances et son SE ICT. Elle expose comment elle pourrait, le cas échéant, s adapter à un changement structurel de l organisation. La firme s engage enfin à utiliser l outil Redmine (ou son remplaçant) du département ICT-Development pour la distribution et le suivi des tâches/activités des membres des équipes.

27 Cahier des charges S&L/AO/386/ /217 Sous-critère d attribution 3 : Mode d exécution Coopération avec le SPF Finances La firme doit démontrer sa coopération active avec les membres du personnel SPF Finances (avec au minimum le business et l ICT). A cette fin, elle expose et démontre dans l offre la manière dont elle compte agréger et faire circuler, de façon organisée, la connaissance et l information relative aux connaissances des projets et de leur contenu, et assurer la transparence nécessaire avec le personnel ICT et l implication satisfaisante de ce dernier à tout moment de la vie des projets. La participation occasionnelle à l élaboration de contenu en elearning est une piste d approche à prendre en considération. La firme s engage à assurer cette coopération de manière continue, implicite et intégrée sans supplément de prestation. Elle doit démonter dans sa stratégie sa méthodologie et sa responsabilisation dans le transfert de son savoir et quant à la garantie que ce savoir sera acquis par les membres du SPF Finances. Sous-critère d attribution 4 : Mode d exécution Coopération test ICT La firme doit s assurer d une coopération avec la ou les équipes de test ICT (internes, externes et notamment le lot 4 de ce cahier des charges), selon leurs méthodologies, dès le début du projet. La firme expose et démontre, de manière détaillée, comment elle compte intégrer cette coopération dans ses plans de projet et leur exécution. Sous-critère d attribution 5 : Mode d exécution Coopération requirements Business La firme doit s assurer d une coopération avec la ou les équipes d analyse business, dès le début du projet, conformément aux standards du SPF Finances. La firme expose et démontre, de manière détaillée, comment elle compte effectuer la capture des réquirements et la gestion des requirements, et intégrer la coopération et le support et l éventuelle guidance vers une professionnalisation du pouvoir adjudicateur à ce sujet dans ses plans de projet et leur exécution. Sous-critère d attribution 6 : Mode d exécution Coopération test Business La firme doit s assurer d une coopération avec la ou les équipes de test acceptance business, dès le début du projet, conformément aux standards du SPF Finances. La firme expose et démontre, de manière détaillée, comment elle compte intégrer cette coopération et le support et l éventuelle guidance vers une professionnalisation du pouvoir adjudicateur à ce sujet dans ses plans de projet et leur exécution. Sous-critère d attribution 7 : Mode d exécution Méthodologie pour les offres La firme doit démontrer une totale transparence quant à la méthodologie de pré-analyse et d évaluation qu elle emploie pour estimer et confirmer la charge de travail pour la remise d une offre ou pendant l exécution d un projet. A cette fin, elle expose et démontre de manière détaillée les modèles de calcul, les outils et les processus qu elle s engage à appliquer pendant l exécution du marché. Sous-critère d attribution 8 : Mode d exécution Reporting régulier La firme doit assurer des comptes rendus détaillés des activités de son personnel, quel que soit son mode de prestation (régie, fixed-price, ). Cela doit obligatoirement se faire au moyen de l outil Redmine (ou son éventuel équivalent) du département ICT-Development, en respectant les guidelines (et leurs mises à jour) développées par le département ICT- Development, et ce, afin d objectiver les prestations et d affiner les estimations par un

28 Cahier des charges S&L/AO/386/ /217 processus d amélioration continue. En complément, la firme expose et démontre, de manière détaillée, les processus et artefacts de reporting qu elle compte utiliser pour rendre compte de ses tâches/activités au SPF Finances, entre autres, l équipe Intake du département ICT- Development et le client Business. Sous-critère d attribution 9 : Compréhension et engagement quant aux standards De manière générale, la firme doit montrer sa compréhension des standards et fondements actuels et futurs du SPF Finances, et s engager à les appliquer pendant toute la durée du contrat. Les standards comprennent notamment les méthodologies, les techniques et technologies, les outils et les processus, du SPF Finances, de ses partenaires reconnus, du Service d Encadrement ICT et de ses départements. Les standards techniques incluent, sans que cette liste soit exhaustive, les aspects de design et d architecture conformes, de qualité du code, de sécurité du code, de maintenabilité, d intégration, de couverture des tests et de documentation. La firme doit exposer et démontrer dans son offre de manière précise comment elle entend respecter les standards, s y adapter pour des applications qui son issue d ancien standards, ou intégrer des changements ou des nouveautés dans le panel de standards existants. Elle doit montrer comment elle peut s accommoder à des processus et standards incomplets, en construction ou en mutation. Sous-critère d attribution 10 : Gestion de la configuration La firme doit gérer tous les configurations items qu elle manipule de manière conforme aux standards du SPF Finances notamment en termes de documentation management et de release management, sous contrôle de versionning. Ceci inclut l intrégration à la chaine de build (actuellement nommée FUP-ITIL) et la conformité attendue que cela implique aux différentes étapes de cette chaîne. On attend de la firme qu elle expose et démontre les pratiques qu elle compte mettre en œuvre à cette fin, de manière conforme aux standards du SPF Finances, en ce compris les aspects de build, de test et de déploiement continus et automatisés, le contrôle de la qualité inhérent, et la gestion des données nécessaires. Sous-critères d attribution 11 : Documentation produits et projets La firme doit documenter les projets (inclus : le reporting) et les produits et artefacts des projets selon standards documentaires (en ce compris les templates) et de processus du SPF Finances (les méthodologies PMFIN et FUP). On attend de la firme qu elle expose et démontre toutes les pratiques qu elle compte mettre en œuvre à cette fin. Sous-critère d attribution 12 : Coopération des rôles La firme doit fonctionner de manière homogène dans les différents métiers IT qui la composent. Dans l offre, elle doit exposer les rôles, les responsabilités et les processus qui démontrent une gestion disciplinée des interactions et du fonctionnement de l équipe, y compris en y intégrant les aspects de co-sourcing. Sous-critère d attribution 13 : Gestion de programme La firme doit gérer son portfolio de projet et ses programmes de manière intégrée et transparente. Dans l offre, elle doit démontrer comment elle compte s y prendre pour répondre à ces exigences.

29 Cahier des charges S&L/AO/386/ /217 III. SLA61, garantie, maintenance 20 points IMPORTANT Pour entrer en ligne de compte pour l attribution du marché, le soumissionnaire doit obtenir une cote d au moins 60% pour le critère d attribution «SLA, garantie, maintenance. En cas de non-respect de cette condition, l offre sera considérée comme substantiellement irrégulière. Répartition des points sur 100 points à ensuite ramener à un score de 20 points 1. Pondération pour le SQP : 5 points 2. Pondération pour le SIP : 5 points 3. Pondération pour le Master SLA: 40 points 4. Pondération pour le DAP: 15 points 5. Pondération pour le modèle de reporting : 10 points 6. Pondération pour les pénalités : 25 points Formule pour le calcul des pénalités : Les points pour ce critère d attribution sont attribués sur la base de la formule suivante : Où : B est le nombre de points qui est attribué au soumissionnaire pour le sous-critère pénalités du SLA ; B_w représente le score pondéré pour le sous-critère pénalités ; n représente le nombre de KPI frappés d une pénalité ; x fait référence au numéro dans le tableau KPI ; B_(x_o) représente la pénalité de base minimum ou la pénalité supérieure proposée dans l offre du soumissionnaire pour KPI x ; B_(x_max) représente la pénalité maximum proposée pour KPI x dans les offres de tous les soumissionnaires retenus ou la pénalité de base minimum proposée si aucune pénalité plus élevée n a été proposée. Pour le lot 5 I. Le prix 30 points Concernant l évaluation du critère d attribution «Prix», la formule suivante sera appliquée pour calculer les points : Mo = P x 30/100 Où

30 Cahier des charges S&L/AO/386/ /217 Mo est le nombre de points obtenus par le soumissionnaire pour le critère «Prix» ; P est le résultat obtenu après l addition des différents profils pour l offre analysée ; Prix profils Prix profil Testeur Prix profil Coordinateur de test Prix profil Spécialiste en test tools Prix profil Spécialiste en méthodologie de test Prix profil Quality Assurance Coordinator Total intermédiaire (P1+P2+P3+P4+P5) Points P1 (40 points) P2 (20 points) P3 (10 points) P4 (15 points) P5 (15 points) P (100 points) Tous les prix doivent être exprimés en euro, TVAC et pour une journée de 8h. Prix profil Testeur (40 points) Le critère Prix est pondéré de la façon suivante : Pr min P1 = 40 Pr offre où : Proffre = prix de l offre pour ce profil, Prmin = le prix de l offre la moins chère dans les offres régulières pour ce profil. P1 = points attribués au critère Prix profil testeur Les prix sont exprimés TVAC Prix profil Coordinateur de test (20 points) Le critère Prix est pondéré de la façon suivante : Pr min P2 = 20 Pr offre où : Proffre = prix de l offre pour ce profil, Prmin = le prix de l offre la moins chère dans les offres régulières pour ce profil. P2 = points attribués au critère Prix profil coordinateur de test Les prix sont exprimés TVAC Prix profil Spécialiste en test tools (10 points) Le critère Prix est pondéré de la façon suivante : Pr min P3 = 10 Pr offre où : Proffre = prix de l offre pour ce profil, Prmin = le prix de l offre la moins chère dans les offres régulières pour ce profil. P3 = points attribués au critère Prix profil spécialiste en test tools Les prix sont exprimés TVAC Prix profil Spécialiste en méthodologie de test (15 points) Le critère Prix est pondéré de la façon suivante :

31 Cahier des charges S&L/AO/386/ /217 P4 = 15 Pr min Pr offre où : Proffre = prix de l offre pour ce profil, Prmin = le prix de l offre la moins chère dans les offres régulières pour ce profil. P4 = points attribués au critère Prix profil spécialiste en méthodologie de test Les prix sont exprimés TVAC Prix profil Quality Assurance Coordinator (15 points) Le critère Prix est pondéré de la façon suivante : Pr min P5 = 15 Pr offre où : Proffre = prix de l offre pour ce profil, Prmin = le prix de l offre la moins chère dans les offres régulières pour ce profil. P5 = points attribués au critère Prix profil Quality Assurance Coordinator Les prix sont exprimés TVAC II. Le mode d exécution 50 points IMPORTANT Pour entrer en ligne de compte pour l attribution du marché, le soumissionnaire doit obtenir une cote d au moins 60% pour le critère d attribution «mode d exécution» et 50% à chacun des sous-critères à l exception du sous-critère «Partenariat garantie expertise sur nos standards» composant le critère d attribution «mode d exécution». Le soumissionnaire qui ne répondrait pas à ces deux conditions cumulatives n entrerait pas en compte pour l attribution du marché et l offre sera dès lors considérée comme substantiellement irrégulière. Une attention particulière est apportée à l organisation mise en place par le soumissionnaire pour répondre de manière optimale aux besoins exprimés, ce dans le cadre organisationnel et technique du SPF Finances, ce qui justifie du poids important donné à ce critère. Quatre sous-critères précisent ce critère : 1. Compréhension de la méthodologie de test (15 points) Afin de vérifier la compréhension et la capacité technique du soumissionnaire de travailler sur base d'une méthodologie de test prédéfinie et actuellement utilisée au SPF Finances, il est demandé au soumissionnaire de faire une représentation textuelle en 5 pages maximum faisant une rapide présentation de sa compréhension de la méthodologie. Une description de la méthodologie propre au SPF Finances peut être consultée à l adresse suivante : Cotation :

32 Cahier des charges S&L/AO/386/ /217 Afin de vérifier la documentation fournie, celle-ci sera relue par nos experts internes, celle-ci devra être correctement décrite, complète et cohérente par rapport à l objet du lot 4 «Test des applications de l Administration Générale de la Fiscalité» et devra couvrir au moins les points suivants : Aperçu et phases (les phases et activités) Organisation (différents rôles et équipes) Outils (outils par phase) TCC Modèle opérationnel Formation et Coaching Communication Amélioration et révision TMv4 : alignement avec FUP-D5 Excellent : Le soumissionnaire a couvert les 8 aspects repris ci-dessus de la méthodologie dans sa documentation de manière correcte, claire et précise. Très bien : Le soumissionnaire a couvert 7 des 8 aspects de la méthodologie dans sa documentation de manière correcte, claire et précise. Bien + : Le soumissionnaire a couvert 6 des 8 aspects de la méthodologie dans sa documentation de manière correcte, claire et précise. Bien : Le soumissionnaire a couvert 5 des 8 aspects de la méthodologie dans sa documentation de manière correcte, claire et précise. Suffisant : Le soumissionnaire a couvert 4 des 8 aspects de la méthodologie dans sa documentation de manière correcte, claire et précise. Impossible à analyser/inexistant : Le soumissionnaire a couvert moins de 4 des 8 aspects de la méthodologie dans sa documentation de manière correcte, claire et précise. 15 points 13,15 points 11,25 points 9,30 points 7,5 points Exclu 2. Organisation équipe test par rapport à l environnement organisationnel du SPF Finances (15 points) Sur base de la méthodologie et également des informations remises au soumissionnaire, il est demandé de fournir un document décrivant et expliquant l organisation d une équipe de test fournie par le soumissionnaire en collaboration avec les différents intervenants du SPF finances. Ce document doit : être précisément décrit comprendre une timeline reprenant les phases opérationnelles de la méthodologie avec les intervenants (équipes) par phase s appuyer sur les structures organisationnelles ( et techniques

33 Cahier des charges S&L/AO/386/ /217 (ABB menten/) mises en place au sein du SPF. comprendre les flux de communication et de collaboration entre les différents stakeholders du SPF Finances. Cotation : Le document sera relu par nos experts internes et devra comprendre au minimum les informations suivantes en termes de relation/communication : Business (Client) Equipe de projet Management (ICT, ICT QA&ITPS, Test Management) Equipe de Test interne (ICT Test Management) Equipe d ICT Développement Equipe d ICT Operations Equipe d ICT Quality Assurance & IT Process support La timeline du document devra couvrir au minimum les phases suivantes : o Intake o Préparation o Planification o Scripting o Exécution et reporting Excellent : Le soumissionnaire a couvert les 8 aspects de l organisation dans sa documentation de manière correcte, claire et précise. Très bien : Le soumissionnaire a couvert 7 des 8 aspects de l organisation dans sa documentation de manière correcte, claire et précise. Bien +: Le soumissionnaire a couvert 6 des 8 aspects de l organisation dans sa documentation de manière correcte, claire et précise. Bien : Le soumissionnaire a couvert 5 des 8 aspects de l organisation dans sa documentation de manière correcte, claire et précise. Suffisant : Le soumissionnaire a couvert 4 des 8 aspects de l organisation dans sa documentation de manière correcte, claire et précise. Impossible à analyser/inexistant : Le soumissionnaire a couvert moins de 4 des 8 aspects de l organisation dans sa documentation de manière correcte, claire et précise. 15 points 13,15 points 11,25 points 9,30 points 7,5 points Exclu 3. Partenariat garantie expertise sur nos standards. (5 points) Sans exclure les candidats ne possédant pas de partenariat mais afin de donner une garantie supplémentaire au SPF Finances sur l expertise apportée par le soumissionnaire, il est demandé de fournir une preuve et le niveau de partenariat portant sur les softwares standards suivants utilisés au SPF finances suivants: HP ALM HP UFT HP Performance Center HP Fortify Cast

34 Cahier des charges S&L/AO/386/ /217 Cotation : Il existe différents niveaux de partenariat sur les softwares HP : silver, gold et platinium. (1) La firme possède un partenariat pour les 4 softwares HP de type : Silver : 2.5 points Gold : 3,5 points Platinium : 4,5 points (2) La firme possède un partenariat avec Cast software : 0,5 point La cotation finale de ce critère sera égale à la somme du partenariat HP et du partenariat Cast. Partenariat HP (1) 0 point 2.5 points 3,5 points 4,5 points Partenariat CAST (2) 0 point 0,5 point Total (1) + (2) 4. Capacité de mobilisation du personnel (15 points) Le candidat doit disposer, d au minimum un nombre de profils techniques correspondant au nombre de profils de compétences minimal tel que décrit dans les prescriptions techniques pour le lot 4. Pour démontrer cela, il annexe à son offre au minimum un CV correspondant au profil de compétence proposé. Le CV devra impérativement, pour le lot 5, respecter le modèle fourni par le pouvoir adjudicateur. Cotation : Il est demandé au minimum : 4 testeurs 2 coordinateurs de test 2 spécialistes en méthodologie de test 2 spécialistes en outils de test 2 quality assurance coordinators Nombre de profil Testeur (P1) Le soumissionnaire a proposé 8 testeurs ou plus qui 40 points correspondent au profil recherché Le soumissionnaire a proposé 7 testeurs qui 35 points correspondent au profil recherché Le soumissionnaire a proposé 6 testeurs qui 30 points correspondent au profil recherché Le soumissionnaire a proposé 5 testeurs qui 25 points correspondent au profil recherché Le soumissionnaire a proposé 4 testeurs qui 20 points correspondent au profil recherché Exclusion : Le soumissionnaire a proposé moins de Exclusion

35 Cahier des charges S&L/AO/386/ /217 4 testeurs qui correspondent au profil recherché. Nombre de profil Coordinateur de test (P2) Le soumissionnaire a proposé 4 ou plus coordinateurs de test qui correspondent au profil recherché Le soumissionnaire a proposé 3 coordinateurs de test qui correspondent au profil recherché Le soumissionnaire a proposé 2 coordinateurs de test qui correspondent au profil recherché Exclusion : Le soumissionnaire a proposé moins de 2 coordinateurs de test qui correspondent au profil recherché. 20 points 15 points 10 points Exclusion Nombre de profil spécialistes en méthodologie de test (P3) Le soumissionnaire a proposé 4 ou plus spécialistes en méthodologie de test qui correspondent au profil recherché Le soumissionnaire a proposé 3 spécialistes en méthodologie de test qui correspondent au profil recherché Le soumissionnaire a proposé 2 spécialistes en méthodologie de test qui correspondent au profil recherché Exclusion : Le soumissionnaire a proposé moins de 2 spécialistes en méthodologie de test qui correspondent au profil recherché. 10 points 7,5 points 5 points Exclusion Nombre de profil spécialistes en outils de test (P4) Le soumissionnaire a proposé 4 ou plus spécialistes en outils de test qui correspondent au profil recherché Le soumissionnaire a proposé 3 spécialistes en outils de test qui correspondent au profil recherché Le soumissionnaire a proposé 2 spécialistes en outils de test qui correspondent au profil recherché Exclusion : Le soumissionnaire a proposé moins de 2 spécialistes en outils de test qui correspondent au profil recherché. 15 points 11,25 points 7,5 points Exclusion Nombre de profil quality assurance coordinator (P5) Le soumissionnaire a proposé 4 ou plus spécialistes en quality assurance coordinator qui correspondent au profil recherché Le soumissionnaire a proposé 3 spécialistes en quality assurance coordinator qui correspondent au profil recherché Le soumissionnaire a proposé 2 spécialistes en quality assurance coordinator qui correspondent au profil recherché 15 points 11,25 points 7,5 points

36 Cahier des charges S&L/AO/386/ /217 Exclusion : Le soumissionnaire a proposé moins de 2 spécialistes en quality assurance coordinator qui correspondent au profil recherché. Exclusion Nombre profils Nombre profil Testeur Nombre profil Coordinateur de test Nombre profil Spécialiste en outils de test Nombre profil Spécialiste en méthodologie de test Nombre profils Quality Assurance Coordinator Total intermédiaire (P1+P2+P3+P4+P5) Total pour la capacité de mobilisation du personnel Points P1 (40 points) P2 (20 points) P3 (10 points) P4 (15 points) P5 (15 points) P (100 points) P*10/100 III. SLA 20 points IMPORTANT Pour entrer en ligne de compte pour l attribution du marché, le soumissionnaire doit obtenir une cote d au moins 60% pour le critère d attribution «SLA». En cas de non-respect de cette condition, l offre sera considérée comme substantiellement irrégulière. Répartition des points sur 100 points à ensuite ramener à un score de 20 points 7. Pondération pour le SQP: 5 points 8. Pondération pour le SIP: 5 points 9. Pondération pour le Master SLA: 40 points 10. Pondération pour le DAP: 15 points 11. Pondération pour le reporting type : 10 points 12. Pondération pour les pénalités : 25 points Formule pour le calcul des pénalités : Les points pour ce critère d attribution sont attribués sur la base de la formule suivante : Où : B est le nombre de points qui est attribué au soumissionnaire pour le sous-critère pénalités du SLA ; B_w représente le score pondéré pour le sous-critère pénalités ; n représente le nombre de KPI frappés d une pénalité ; x fait référence au numéro dans le tableau KPI ;

37 Cahier des charges S&L/AO/386/ /217 B_(x_o) représente la pénalité de base minimum ou la pénalité supérieure proposée dans l offre du soumissionnaire pour KPI x ; B_(x_max) représente la pénalité maximum proposée pour KPI x dans les offres de tous les soumissionnaires retenus ou la pénalité de base minimum proposée si aucune pénalité plus élevée n a été proposée Cote finale Par lot, la cote finale est attribuée à chaque offre en additionnant les points obtenus pour les 3 critères susmentionnés. L offre la plus intéressante obtient la cote finale la plus élevée. L adjudicataire garantit que tous les services qui devront être exécutés dans le cadre ce marché seront exécutés, par un personnel suffisamment formé et compétent, en respectant les délais et budget prévus. Aucun dépassement de délai ou de budget ne sera accepté. L adjudicataire a donc une obligation de résultat.

38 Cahier des charges S&L/AO/386/ /217 D. EXECUTION 1. Fonctionnaire dirigeant. Pour chaque lot qui sera conclu sur base du présent marché, le fonctionnaire dans le sens de l article 11 de l arrêté royal du 14 janvier 2013 arrêté royal établissant les règles générales d exécution des marchés publics et des concessions de travaux publics sera désigné dans la notification de la conclusion du marché. Le fonctionnaire dirigeant est le seul compétent pour la surveillance du marché ainsi que pour son contrôle. Le fonctionnaire dirigeant qui sera un fonctionnaire du Pouvoir Adjudicateur sera désigné dans la notification de la conclusion du marché. Les limites de ses compétences y seront indiquées. Le fonctionnaire dirigeant peut déléguer partie de ses compétences. 2. Révision de prix. La révision des prix des services est possible. Les règles de révision sont les suivantes : Les prix peuvent être revus annuellement. Chaque année, le prestataire demande la révision du prix par lettre recommandée adressée au Pouvoir Adjudicateur, Service d'encadrement B&CG, Division Engagements, bd Roi Albert II 33 bte 785, 1030 Bruxelles. La révision des prix entre en vigueur : o o le jour anniversaire de l'avis d'attribution du marché si le prestataire a introduit sa demande de révision avant cette date. La révision des prix ne concerne que les services effectivement prestés après l'anniversaire de l'attribution du marché. le 1er jour du mois qui suit l'envoi de la lettre recommandée si le prestataire a laissé passer un ou plusieurs anniversaires. La révision des prix ne concerne que les services effectivement prestés après la date visée cidessus (attention : l adjudicataire doit introduire une nouvelle demande pour la révision des prix des services à prester après l'anniversaire suivant). La révision des prix se calcule suivant la formule : S P = P * 0,8* S0 où : P = prix revu P 0 = prix initial S 0 = indice salarial AGORIA (seulement pour les prestataires belges ; les prestataires étrangers doivent proposer un indice analogue) - moyenne nationale, charges sociales comprises, valable le mois qui précède l'ouverture des offres. S = comme S 0 ci-dessus, mais valable le mois qui précède le jour anniversaire de la notification de l'attribution du marché.

39 Cahier des charges S&L/AO/386/ /217 Pour les indices, voir : Le pouvoir adjudicateur se réserve le droit de revoir les prix en cas de baisse de l'indice. Dans ce cas, la révision suit les règles ci-dessus, sauf que la lettre recommandée émane du pouvoir adjudicateur. 3. Responsabilité du prestataire de services. L adjudicataire assume la pleine responsabilité des fautes et manquements commis dans le cadre des prestations de services. Le pouvoir adjudicateur n est en aucun cas responsable des dommages causés à des personnes ou à des biens qui sont la conséquence directe ou indirecte des activités nécessaires à l exécution du présent marché. L adjudicataire garantit le pouvoir adjudicateur contre toute action en dommages et intérêts par des tiers et notamment aux membres de l Administration à cet égard. Par ailleurs, l adjudicataire garantit le pouvoir adjudicateur des dommages et intérêts dont celui-ci est redevable à des tiers du fait du retard dans l exécution des services ou de la défaillance du prestataire de services. Toute dégradation ou vol résultant d un abandon ou d une négligence, fût-ce consécutif aux intempéries ou à d autres risques sera de la responsabilité de l adjudicataire. 4. Réception des services prestés La livraison et l installation L adjudicataire doit mettre à la disposition du SPF Finances tous les renseignements et facilités nécessaires pour le contrôle de la préparation et de l exécution des prestations. Sauf avis contraire du pouvoir adjudicateur, aucune prestation ne peut avoir lieu sans que le service destinataire n ait été averti par écrit au moins cinq jours ouvrables avant la date d envoi des biens ou d installation des logiciels Spécifications techniques Les services doivent correspondre sous tous rapports avec les plans, documents et thèmes applicables à ce marché. Même à défaut de spécification technique contractuelle, les services doivent être conformes à toutes les exigences et règles de bonne exécution Suivi de la bonne exécution des livraisons et des services Le SPF Finances a le droit d exercer une surveillance permanente sur les services réalisés par l équipe chargée de l exécution du marché. L équipe chargée de l exécution doit remettre aux représentants du pouvoir adjudicateur tous les renseignements et facilités nécessaires à l accomplissement des tâches de supervision. Les plans, spécifications, dossiers, etc, établis dans le cadre de ce marché par le personnel des adjudicataires, y compris les normes appliquées, doivent être approuvés avant l exécution par le pouvoir adjudicateur. Le SPF Finances dispose d un délai de 15 jours calendrier pour approuver ces documents ou pour formuler des remarques. En cas de

40 Cahier des charges S&L/AO/386/ /217 remarques, les documents concernés doivent être adéquatement corrigés avant l exécution, sans que les corrections n entraînent la révision du délai d exécution prévu, sauf si les remarques résultent d une nouvelle exigence de la part du pouvoir adjudicateur. Tout dépassement du délai d acceptation d un document entraîne, à la demande de l adjudicataire concerné, la prolongation du délai d exécution. Le fait qu un retard soit imputable au SPF Finances ne dispense pas l adjudicataire de veiller à limiter les conséquences du retard. L adjudicataire ne peut invoquer ce contrôle pour se soustraire à sa responsabilité lorsque les services sont refusés en raison de défauts de nature quelconque et qu il en résulte une prolongation du délai d exécution. Si, pendant l exécution des services, des anomalies sont constatées, elles seront immédiatement signalées à l adjudicataire par fax ou 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 adjudicataire est tenu de collaborer avec ce tiers et de lui fournir toute l information nécessaire au bon accomplissement des opérations de contrôle. Dans ce cadre, le SPF Finances souhaite mettre l offre de l adjudicataire à la disposition de collaborateurs internes et externes du SPF Finances chargés de l évaluation et du contrôle des services. Le soumissionnaire doit indiquer clairement les parties de son offre qui ne peuvent être mises à la disposition de personnes étrangères au SPF Finances chargées de l évaluation et du contrôle des services Contrôle et encadrement du marché Dans les 30 jours suivant l annonce de leur achèvement par l adjudicataire, le SPF Finances commencera un contrôle complet des éléments constitutifs de chaque commande. Les contrôles porteront sur l adéquation et le bon fonctionnement de l application. Le contrôle de l adéquation a pour but de vérifier que les applications sont conformes aux spécifications imposées par le SPF Finances. Le contrôle du bon fonctionnement a pour but de vérifier que les services livrés peuvent fonctionner correctement dans des conditions normales (autrement dit, que les installations sont aptes aux services préalablement définis). Les opérations de contrôle concernent notamment : - La bonne exécution des services correspondants ; - L opérationnalité et la programmation de toutes les fonctions ; - La capacité en termes de performances, de sécurité, de robustesse, de charge - Au besoin, des outils de test sont installés pour pouvoir effectuer ces contrôles ; - La fourniture de la documentation. Les contrôles sont considérés comme fructueux lorsque les composants fournis passent les tests avec succès dans les délais impartis. Les tests et leur calendrier sont définis de commun accord et doivent être compatibles avec le lot testing..

41 Cahier des charges S&L/AO/386/ /217 Si les opérations de contrôle révèlent que les performances et/ou les fonctionnalités ne répondent pas ou répondent seulement partiellement à ce qui est demandé dans ce cahier spécial des charges et/ou annoncé dans l offre et les éventuels documents complémentaires, l adjudicataire s engage à apporter à ses frais les corrections ou modifications nécessaires, ou à remplacer tout ou partie des délivrables par une livraison conforme, dans les 30 jours calendrier suivant la date du procès-verbal constatant l impossibilité de procéder à la réception provisoire. Passé ce délai, le SPF Finances se réserve le droit d appliquer les amendes de retard. Dans cette éventualité, tous les tests de réception doivent être recommencés, après que l adjudicataire a apporté les modifications, compléments ou remplacements nécessaires. Concrètement, dans le cas où les tests fonctionnels d une application détectent des anomalies de fonctionnement ou des éléments non-conformes à l analyse fonctionnelle, les modifications devront y être apportées aux frais de l adjudicataire et retestées par les testeurs et utilisateurs finaux (acceptance métier). Dans le cas où ces modifications ont un impact sur un projet qui a fait l objet d une livraison intermédiaire antérieure, les modifications devront y être apportées aux frais de l'adjudicataire avant que le SPF Finances accepte la livraison intermédiaire de cette application. Si les contrôles ne peuvent être menés à bien avec fruit dans les délais impartis, le SPF Finances peut : - appliquer les mesures d office prévues à l article 47 de l A.R. du 14 janvier 2013, qui définit les règles générales d exécution des marchés publics et des concessions de travaux publics ; - ou prendre des dispositions particulières avec l adjudicataire Acceptations provisoires L acceptation des résultats intermédiaires ou définitifs se fera suivant un processus standard (par application). Lorsque les opérations de contrôle sont achevées avec fruit et approuvées par le Project Board (comité de pilotage), le SPF Finances dresse un procès-verbal de réception provisoire des résultats (produits et/ou services) de la phase concernée. Le procès-verbal de réception provisoire sera signé par les deux parties Garantie Le nombre d années proposées pour la garantie est minimum 1 an et court à compter de la réception provisoire. Durant la période de garantie, tout comportement imprévu ou qui ne correspond pas à la description dans le document d Analyse fonctionnelle devra être corrigé dans les délais prévus. La responsabilité de l adjudicataire est engagée aussi bien pour le comportement du système informatique, que ce qui concerne le contenu de(s) base(s) de données et leur cohérence.

42 Cahier des charges S&L/AO/386/ / Réception définitive La réception définitive est déclarée à la demande du fournisseur, après la fin de la période de garantie, pourvu que le SPF Finances n ait pas formulé de plaintes concernant le bon fonctionnement pendant cette période. En cas d objection, la réception définitive est reportée jusqu au moment où le système a fonctionné correctement pendant une période ininterrompue d un an. La réception définitive sera consignée dans un procès-verbal signé par l adjudicataire et le SPF Finances. Le SPF Finances dispose d un délai de 30 jours à compter de la demande de l adjudicataire pour rédiger le procès-verbal d acceptation qui autorise la réception Frais de réception Tous les frais de réception, y compris les éventuels frais de déplacement et de séjour des délégués du pouvoir adjudicateur, sont à la charge de l adjudicataire. 5. Cautionnement En application de l article 9, paragraphes 2 et 3 de l AR du 14 janvier 2013, l attention des soumissionnaires est attirée sur le fait que, dans le présent cahier spécial des charges, il a été dérogé à l'article 25 de l arrêté royal du 14 janvier 2013 relatif au cautionnement et plus particulièrement pour ce qui concerne l adaptation du montant du cautionnement compte tenu de l impossibilité de déterminer avec certitude le montant du marché au moment de son attribution et compte tenu du poids administratif excessif qu impliquerait une adaptation de ce cautionnement en fonction des commandes potentiellement nombreuses adressées par le pouvoir adjudicateur; Pour chacune des commandes passées dans le cadre de ce marché, le cautionnement est fixé à 5% du montant total de la commande, hors TVA. Le montant ainsi obtenu est arrondi à la dizaine d euro supérieure 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:

43 Cahier des charges S&L/AO/386/ /217 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 BE (IBAN), PCHQBEBB (BIC)] ou d un organisme public remplissant une fonction similaire à celle de ladite Caisse, ci-après dénommé organisme public remplissant une fonction similaire 2 lorsqu il s agit de fonds publics, par le dépôt de ceux-ci entre les mains de sa gestionnaire des titres ou dans l une de ses agences en province, pour compte de la Caisse des Dépôts et Consignations, ou d un organisme public remplissant une fonction similaire 3 lorsqu il s agit d un cautionnement collectif, p ar le dépôt par une société exerçant légalement cette activité, d un acte de caution solidaire auprès de la Caisse des Dépôts et Consignations ou d un organisme public remplissant une fonction similaire 4 lorsqu il s agit d une garantie, par l acte d en gagement de l établissement de crédit ou de l entreprise d assurances. Cette justification se donne, selon le cas, par la production au pouvoir adjudicateur: 1 soit du récépissé de dépôt de la Caisse des Dépô ts et Consignations ou d un organisme public remplissant une fonction similaire 2 soit d un avis de débit remis par l établissemen t de crédit ou l entreprise d assurances 3 soit de la reconnaissance de dépôt délivrée par le caissier de l Etat ou par un organisme public remplissant une fonction similaire 4 soit de l original de l acte de caution solidair e visé par la Caisse des Dépôts et Consignations ou par un organisme public remplissant une fonction similaire 5 soit de l original de l acte d engagement établi par l établissement de crédit ou l entreprise d assurances accordant une garantie. Ces documents, signés par le déposant, indiquent au profit de qui le cautionnement est constitué, son affectation précise par l indication sommaire de l objet du marché et de la référence des documents du marché, ainsi que le nom, le prénom et l adresse complète de l adjudicataire et éventuellement, du tiers qui a effectué le dépôt pour compte, avec la mention "bailleur de fonds" ou "mandataire", suivant le cas. Le délai de trente jours calendrier visé ci-avant est suspendu pendant la période de fermeture de l entreprise de l adjudicataire pour les jours de vacances annuelles payés et les jours de repos compensatoires prévus par voie réglementaire ou dans une convention collective de travail rendue obligatoire. La preuve de la constitution du cautionnement doit être envoyée à l adresse suivante : Service Public Fédéral FINANCES Division Engagements à l attention de Madame MALJEAN Françoise NOGA B22 Boulevard Roi Albert II, 33 boîte 781 Bloc B BRUXELLES 5.2. Libération du cautionnement

44 Cahier des charges S&L/AO/386/ /217 Le cautionnement sera libéré en une fois après réception définitive de la derniere commande exécutée sur la base du contrat conclu sur base du présent cahier spécial des charges, à condition que les services fournis aient été réceptionnés. 6. Modalités d exécution 6.1. Clause d exécution Le soumissionnaire s engage, jusqu à la complète exécution du marché, à respecter les 8 conventions de base de l OIT, en particulier: 1. l interdiction du travail forcé (conventions n 29 concernant le travail forcé ou obligatoire, 1930, et n 105 sur l abolition du tra vail forcé, 1957) 2. le droit à la liberté syndicale (convention n 8 7 sur la liberté syndicale et la protection du droit syndical, 1948) 3. le droit d organisation et de négociation collective (convention n 98 sur le droit d organisation et de négociation collective, 1949) 4. l interdiction de toute discrimination en matière de travail et de rémunération (conventions n 100 sur l égalité de rémunération, 1951 et n 111 concernant la discrimination (emploi et profession), 1958) 5. l âge minimum fixé pour le travail des enfants (convention n 138 sur l âge minimum, 1973), ainsi que l interdiction des pires formes du travail des enfants (convention n 182 sur les pires formes du travail des enfants, 1999). En vertu de l article 44, 1er, 1 de l arrêté roy al du 14 janvier 2013, le non-respect de cet engagement sera considéré comme une non-exécution du marché suivant les prescriptions fixées dans les documents du marché, ce qui donnera lieu à la mise en demeure de l adjudicataire, et pourra, en vertu de l article 47, 2 de l arrêté royal du 14 janvier 2013, donner lieu à l application des mesures d office, en particulier à la résiliation unilatérale du marché Clause d évolution technologique Si, avant l'expiration du délai de livraison, une évolution technologique donne naissance à des livrables plus avancés en termes de performances ou de fonctionnalités que ceux proposés dans l offre et ce, sans augmentation de prix, l adjudicataire est tenu d'en avertir le pouvoir adjudicateur et d en proposer le remplacement. Le pouvoir adjudicateur est libre d'accepter ou de refuser la proposition Lieu d exécution du marché et particularités L exécution des services L'exécution du marché se déroulera principalement dans les locaux du SPF Finances - Service d'encadrement ICT, North Galaxy, Avenue Roi Albert II 33, 1030 Bruxelles. Si, au cours de certaines périodes, il fallait travailler en d autres lieux, les frais de déplacement ne seraient pas remboursés par le SPF Finances. Une partie des services peut aussi être exécutée dans les locaux de l adjudicataire si la prestation n est pas possible ailleurs ou si le

45 Cahier des charges S&L/AO/386/ /217 SPF Finances en tire un avantage particulier moyennant l accord préalable du SPF Finances. En vue d une collaboration optimale avec le personnel du SPF Finances, le personnel de l adjudicataire effectuant des prestations dans les locaux du SPF Finances doit, dans la mesure du possible, suivre le même horaire de travail que les collègues du SPF Finances, entre 7h00 et 19h00 selon le régime d'horaire variable en vigueur au SPF Finances. Le 2 novembre, le 15 novembre et la période entre Noël en Nouvel An sont considérés comme jours fériés par le SPF Finances, ainsi que le premier jour ouvrable de l année. Des «ponts» obligatoires sont également prévus ; ils seront communiqués à l adjudicataire chaque année Personnel de l adjudicataire Généralités Pour chacune des commandes basée sur ce marché, l adjudicataire devra désigner un chef de projet (également décrit, dans le cadre de PMfin 1, comme le «coordinateur de projet externe») qui l e représentera dans ses rapports avec le SPF Finances. Le personnel de l adjudicataire qui sera amené à réaliser le marché devra : avoir une expérience dans le cadre de la solution proposée ou de solutions comparables, être en mesure de comprendre tous les textes, rapports, comptes rendus, etc. nécessaires, utilisés ou produits par les deux parties dans le cadre du présent marché, et ce tant en français qu en néerlandais. Avoir une connaissance orale et écrite suffisante pour pouvoir communiquer en français ou en néerlandais, et si possible indifféremment dans les deux langues, Le chef de projet doit être en outre capable de : communiquer oralement tant en français qu en néerlandais. Le service d assistance (helpdesk) et de support technique doit en outre pouvoir : communiquer avec aisance dans les deux langues. Le personnel de l adjudicataire devra satisfaire à toutes les dispositions légales en vigueur en Belgique en matière d'immigration et de permis de travail. L adjudicataire garantira le SPF Finances contre tout dommage géné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. 1 une méthodologie de projet unique au sein du SPF Finances qui est basée sur la méthode internationalement reconnue Prince2

46 Cahier des charges S&L/AO/386/ /217 Le personnel affecté à l'exécution du marché doit être le même que celui proposé dans l'offre. A défaut, le personnel mis à disposition pour l'exécution sera de niveau et d expérience équivalents. Le SPF Finances devra marquer son accord sur la composition de l'équipe proposée pour le projet. L'adjudicataire garantit pour toute la durée du marché, la stabilité des personnes affectées à l'exécution du présent marché. En cours d'exécution, l'adjudicataire n'apportera aucun changement dans la composition de l'équipe de projet sans l'autorisation préalable du SPF Finances. En cas de changement dans l équipe, la firme s engage à suivre les principes suivant : - Tout départ d une personne effectivement occupée sur un projet doit être notifié par écrit au SPF Finances (le coordinateur ict, le responsable du département ict-dev, le gestionnaire de contrat) dés connaissance du départ et s assurer que les personnes informées ont accusé réception de l information. En l absence de notification dans les temps, une pénalité est applicable de plein droit. Pour cette personne, la firme doit proposer au minimum 3 CV au SPF Finances (le coordinateur ict, le responsable du département ict-dev, le gestionnaire de contrat) dans les deux semaines de la connaissance du départ, de profil au minimum équivalent en qualité et en compétences au membre qui quitte l équipe, et s assurer que les personnes adressées l ont bien reçu. - Le SPF Finances évalue les CV et donne réponse. Une pénalité est applicable de plein droit si aucun profil n est jugé satisfaisant. - La firme met à disposition la personne au plus tard 1 mois avant le départ en cas de préavis. La firme met à disposition la personne au plus tard 1 mois après le départ si un préavis n a pas été presté. En l absence d engagement dans les délais, une pénalité est applicable de plein droit par mois de retard accompli. - La firme prévoit un transfert de connaissance à ses frais entre le membre qui quitte l équipe et un autre membre de l équipe (éventuellement le nouvel engagé). La firme doit démontrer que le transfert de connaissance a été réellement effectué par des feuilles de prestations et des documents échangés. Des pénalités sont dues de plein droit en cas de non respect de cette disposition. - La firme s engage à faire en sorte que le nouveau membre de l équipe soit immédiatement productif et efficace. Aucune prestation ne doit à ce propos être prévue pour un quelconque intake sur les projets. Des pénalités sont dues de plein droit en cas de non respect de cette disposition. L'adjudicataire remplace immédiatement les membres du personnel qui lui sont signalés par le pouvoir adjudicateur comme compromettant la bonne exécution du marché par leur incapacité, leur mauvaise volonté ou leur inconduite notoire (article 16 Arrêté royal du 14 janvier 2013).

47 Cahier des charges S&L/AO/386/ /217 Dans ce cas, le changement devra intervenir dans les 10 jours ouvrables de la demande du SPF Finances, et ce sans frais à dater de la notification de l incident au soumissionnaire Capacité de mobilisation de ressources au sein de l équipe de développement / support L adjudicataire s engage par écrit à pouvoir fournir (capacité de mobilisation), pour toute la durée du contrat, une disponibilité minimale de profils garantis conformes au minimum aux pré-requis (voir ci-dessous la Table des capacités) et une stabilité de l équipe. Ce minimum est étendu (*) lorsque la firme prend en charge plus de 4 projets concurrents. Il faut ensuite considérer une règle proportionnelle en fonction du nombre de projets concurrents. Table des capacités - Profil Capacité minimale absolue Capacité minimale étendue * Task Manager senior 1 2 Task Manager junior 0 1 Lead Technical Architect / Methodologist senior Analyste Business d Application / 3 6 Métier expert Designer / Data architect expert 2 4 Développeur senior 8 12 On-boarding initial : On peut comprendre que l équipe de la firme ne soit pas être immédiatement opérationnelle conformément aux standards et méthodologies mis en place par le SPF Finances. Le SPF Finances s attend néanmoins à ce que la période d acclimatation soit réalisée dans les plus brefs délais. Cette période d acclimatation est sans supplément de prix Sous-traitants Le fait que l'adjudicataire confie tout ou partie de ses engagements à des sous-traitants ne dégage pas sa responsabilité envers le pouvoir adjudicateur. Le pouvoir adjudicateur n'a aucun lien contractuel avec ces tiers. Toutefois, le pouvoir adjudicateur exige que les sous-traitants de l'adjudicataire satisfassent en proportion de leur participation au marché aux exigences minimales de capacité financière et économique et de capacité technique et professionnelle imposées par les documents du marché. L'adjudicataire reste, dans tous les cas, seul responsable vis-à-vis du pouvoir adjudicateur. Dans les cas suivants, l'adjudicataire a l'obligation de faire appel à certains sous-traitants, le recours à d'autres sous-traitants étant soumis à l'autorisation du pouvoir adjudicateur : 1 lorsque l'adjudicataire a, pour sa sélection qua litative, utilisé la capacité de certains soustraitants conformément à l'article 74 de l'arrêté royal secteurs classiques; 2 lorsque l'adjudicataire a proposé certains sous- traitants dans son offre conformément à l'article 12 de l'arrêté royal secteurs classiques.

48 Cahier des charges S&L/AO/386/ /217 En cas de changement de sous-traitant par rapport à l offre, l'adjudicataire informera le SPF Finances qui devra marquer son accord avant que l adjudicataire puisse procéder au changement. Il est interdit à l'adjudicataire de confier tout ou partie de ses engagements à un entrepreneur, à un fournisseur ou à un prestataire de services qui se trouve dans un des cas visés à l'article 61 de l'arrêté royal secteurs classiques Moyens mis à disposition par le SPF Finances Moyens techniques L adjudicataire mettra à disposition de son personnel tout le matériel nécessaire à l exécution de sa mission (ordinateur portable, etc.). Le personnel de l adjudicataire dispose d un accès limité au réseau du SPF Finances, ainsi que d une adresse . Le SPF Finances ne dispose pas d emplacements de parking pour le personnel de l adjudicataire. Le SPF Finances n'effectuera aucune adaptation aux postes de travail des membres du personnel de l'adjudicataire afin de les faire mieux fonctionner au sein de l'infrastructure du SPF Finances. L'adjudicataire ne peut en aucun cas modifier, perturber ou surcharger l'infrastructure du SPF Finances par l'ajout de postes de travail pour son personnel dans cette infrastructure, sauf pour ce qui est directement associé au développement de l'application concernée. L'adjudicataire est intégralement responsable de la protection des postes de travail concernés contre les virus et de la gestion de ces postes. Il utilisera de manière prioritaire les outils mis à sa disposition par le SPF Finances. Au cas où d'autres logiciels devraient être utilisés dans le cadre du marché, leur utilisation se déroulera, après acceptation par le comité de pilotage, sous la responsabilité de l'adjudicataire et le coût de cette utilisation sera compris dans le prix des services. Le personnel de l adjudicataire devra suivre les procédures internes et les règlements relatifs à l utilisation des moyens mis à sa disposition et à leur accès, et ne peut exiger aucun ajout ou modification à l environnement de travail du pouvoir adjudicateur. Si des manquements dans le soutien logistique entraînent des perturbations de service, il devra être fait appel aux moyens d arbitrage décrits dans le point «Moyens d actions de l administration Litiges» avant de faire appel au droit. Tâches des collaborateurs du SPF Finances Les collaborateurs du SPF Finances participent aux travaux liés à la maintenance d une application donnée pour ce qui concerne : la définition du contenu ; la participation au choix de solutions : architecture, etc. ; la validation des documents de réalisation : dossiers de spécification, dossiers de réalisation, dossiers d acceptation, dossier de tests, manuels d utilisation, manuels de maintenance, etc. ; les contrôles de la qualité, notamment le contrôle de la concordance de la documentation avec la réalisation, du respect des normes en matière de documentation et de programmation, etc. ; le cas échéant : la participation obligatoire aux tests de réception (aspects techniques et fonctionnels), indépendamment du fait qu il s agisse de tests de fonctionnement unitaires, de tests d intégration ou de tests concernant le fonctionnement général ;

49 Cahier des charges S&L/AO/386/ /217 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 Engagements particuliers pour le prestataire de services Confidentialité et engagements particuliers concernant les informations reçues Tous les résultats et rapports produits par l adjudicataire pendant l'exécution de ce marché, constituent la propriété du pouvoir adjudicateur et ne peuvent être publiés ou communiqués à des tiers, sauf accord écrit préalable de la part du pouvoir adjudicateur. L'exécutant des services et ses collaborateurs sont tenus au secret professionnel quant aux informations qu'ils auraient pu obtenir lors de l'exécution de ce marché. Ces informations ne pourront en aucun cas être communiquées à des tiers sans accord écrit de la part du pouvoir adjudicateur. Tous les renseignements dont le personnel de l adjudicataire sera amené à prendre connaissance dans le cadre de sa mission, tous les documents qui lui sont confiés et toutes les réunions auxquelles il participe sont considérés comme strictement confidentiels. Les informations dont il s agit: peuvent être enregistrées sur n'importe quel type de support d'information, comme le papier, un film, une bande magnétique, un disque, une disquette, un montage intégré, etc. ; peuvent être communiquées à l adjudicataire oralement, par une démonstration et/ou par la transmission d'un support d'information qui contient l'information considérée ou peuvent venir à la connaissance de l adjudicataire à l'occasion de l'exécution du présent marché ou d'une mission confiée par le SPF Finances dans le cadre du présent marché ; peuvent, dans leur totalité ou en partie, consister en, par exemple, études, modes d'emploi, plans de conception, plans de fabrication, descriptions techniques, plans de détail, spécifications fonctionnelles, procédures, programmes d'ordinateur, codes exécutables, calculs, etc. L adjudicataire s engage à garder secrètes, tant pendant qu après l exécution du marché, toutes ces informations confidentielles, de quelque ordre que ce soit, qui lui seront communiquées ou dont il aura eu connaissance au cours de sa mission. L adjudicataire se porte garant du respect de la confidentialité de ces informations par son personnel et ses sous-traitants. Il s engage à ne pas les divulguer à des tiers, en ce compris les filiales et autres entreprises liées à l adjudicataire. Il ne communiquera à son personnel et à celui de ses sous-traitants directement impliqués au marché, uniquement les données nécessaires à l'exécution de leur tâche, dans le cadre du présent marché. Les obligations énoncées ci-dessus ne sont pas applicables aux informations du SPF Finances :

50 Cahier des charges S&L/AO/386/ /217 dont l adjudicataire peut démontrer par un moyen acceptable par le SPF Finances qu'elles étaient déjà en sa possession au moment où elles lui ont été communiquées pour la première fois par le SPF Finances ; qui, au moment où elles ont été connues par le SPF Finances, étaient déjà publiques; qui, après qu'elles aient été connues par le SPF Finances, ont été rendues publiques autrement que par le fait de l adjudicataire ; ou que l adjudicataire a obtenues d'un tiers qui disposait de bonne foi des informations du SPF Finances et qui était autorisé à les communiquer à l adjudicataire. L adjudicataire s'engage : à ne pas copier tout ou partie de l'information du SPF Finances, si celle-ci se trouve sur un support mis à disposition par le SPF Finances ; à, d'autre part, ne pas saisir tout ou partie de l'information du SPF Finances sur un support quelconque, sauf pour l'exécution des missions qui lui sont confiées par le SPF Finances, et ce uniquement si cela s avère nécessaire. Toute l'information mise à la disposition de l adjudicataire par le SPF Finances et tout support d'information, contenant de l'information du SPF Finances, mis à la disposition de l adjudicataire par le SPF Finances reste l'entière propriété du SPF Finances. Même si l adjudicataire a copié ou consigné ces informations ou une partie de celles-ci, elles demeurent la propriété intégrale du SPF Finances. Le SPF Finances a le droit, à tout moment, de demander à l adjudicataire de lui remettre tout ou partie des supports d information sur lesquels l adjudicataire aura stocké de l information du SPF Finances. L adjudicataire s engage à remettre immédiatement les supports réclamés sans les copier. L adjudicataire s engage à remettre au SPF Finances, à l issue de l exécution du marché et sans délai, tous les supports d information qui contiennent de l information du SPF Finances et qui ont été mis à la disposition de l adjudicataire pour l exécution du marché, pour autant que ces supports d information n aient pas déjà été remis au SPF Finances. L adjudictaire est tenu d effacer de ses propres supports toutes copies d informations devenues inutiles dans le cadre de sa mission. Toute information du SPF Finances restera la propriété du SPF Finances. Par la mise à disposition d informations du SPF Finances, celui-ci ne concède à l adjudicataire, ni explicitement ni implicitement, aucun droit à licence sur les droits de brevet, droits d auteur ou autres droits intellectuels. L adjudicataire s'engage à ne pas appliquer industriellement l'information du SPF Finances et à ne pas l'utiliser pour d'autres fins que l'exécution du présent marché ou d'une mission à lui confiée par le SPF Finances dans le cadre du présent marché. L adjudicataire et ses éventuels sous-traitants s engagent également à signaler le plus rapidement possible toute faille ou tout risque qui pourrait nuire à la sécurité ou la confidentilité. L adjudicataire est responsable de tout dommage dont le SPF Finances serait victime du fait du non-respect par lui-même ou par les membres de son personnel d obligations qui lui incombent en vertu du présent article Propriété

51 Cahier des charges S&L/AO/386/ /217 Les études, architectures et développements éventuellement produits par les membres du personnel de l adjudicataire, la documentation correspondante, et en général tout document directement ou indirectement généré par le personnel de l adjudicataire pendant l exécution du présent contrat, ainsi que les droits de propriété intellectuelle y afférents, deviennent, à leur naissance, la propriété du SPF Finances. Il est interdit au personnel de l adjudicataire d emporter des documents appartenant au SPF Finances, sauf si les nécessités de la tâche l imposent, notamment dans les déplacements entre les différents sites du SPF Finances Transférabilité L adjudicataire remettra à un tiers agréé par le SPF Finances ou au SPF Finances toutes les informations nécessaires afin que le SPF Finances puisse effectuer toutes les opérations nécessaires au bon fonctionnement ou à l'évolution de la solution ou pour en confier l'exécution à un tiers si l'adjudicataire ou un de ses sous-traitants reste en défaut (cessation de ses activités ou rupture du contrat). À la fin du contrat, que ce soit par expiration ou rupture, l'adjudicataire prêtera son concours au SPF Finances afin que celui-ci ou un tiers puisse poursuivre sans difficulté les prestations exécutées dans le cadre du contrat. À partir du début de la période de transférabilité, l'adjudicataire s'engage à restituer au SPF Finances tous les éléments nécessaires à la production de l'informatique et tous les documents appartenant au SPF Finances. Les méthodes et procédures instaurées durant les prestations sont la propriété du SPF Finances. Aussi, en cas de résiliation, l'adjudicataire proposera au SPF Finances un plan de transition spécifiant en détail les dispositions et conditions relatives aux tâches à accomplir pour fournir l'information nécessaire à la bonne transition, avec un calendrier de ces tâches. L'adjudicataire s'engage à faire établir ce plan de transition par des personnes faisant partie de l'équipe chargée du contrat, sans supplément de frais pour le SPF Finances. Le SPF Finances est le seul propriétaire intellectuel des solutions développées dans le cadre de ce projet. Toutes les opérations en relation avec la transférabilité incombent à l'adjudicataire. Il s'agit notamment de : la mise à disposition de toutes les procédures nécessaires à la gestion du système livré ; la mise à disposition de documents de synthèse, bilans et autres rapports de réunion constituant le dossier de suivi ; la formation et l'information des représentants du nouveau fournisseur ; le transfert des données. 7. Facturation et paiement. Les paiements ne peuvent être effectués qu à posteriori, pour des fournitures ou services déjà livrés et acceptés. Dans la mesure où le pouvoir adjudicateur est en possession d une facture régulièrement établie (avec mention de la TVA et du numéro du bon de commande correspondant), accompagnée du procès-verbal de réception provisoire, la procédure est la suivante : La facture doit être établie en euros.

52 Cahier des charges S&L/AO/386/ /217 L'adjudicataire envoie sa facture à l'adresse suivante : Service Public Fédéral FINANCES Service central de facturation Boulevard Roi Albert II, 33 bte 788 Bloc B BRUXELLES La facture peut être envoyée aussi, sous forme d un fichier pdf, à l adresse suivante : bb.788@minfin.fed.be La procédure de liquidation s effectuera conformément au Règlement sur la Comptabilité de l Etat. Seuls les services exécutés de manière correcte pourront être facturés. Le pouvoir adjudicateur dispose d'un délai de vérification de trente jours à compter de la date de la fin des services, constatée conformément aux modalités fixées dans les documents du marché, pour procéder aux formalités de réception provisoire et en notifier le résultat au prestataire de services. Le paiement du montant dû au prestataire de services doit intervenir dans le délai de paiement de trente jours à compter de l'échéance du délai de vérification. Lorsque les documents du marché ne prévoient pas une déclaration de créance séparée, la facture vaut déclaration de créance. La facture doit être libellée en EURO. 8. Litiges. Les moyens d'action du SPF Finances sont ceux prévus aux articles 44 et suivants de l arrêté royal du 14 janvier Le marché doit être élaboré, conçu et exécuté conformément au droit belge. Les parties s engagent à respecter leurs obligations de bonne foi et à coopérer en vue de la réussite de l opération. Les litiges relatifs aux obligations résultant des dispositions qui régissent le marché doivent être réglés en concertation. Avant de recourir à d autres moyens, les parties doivent tenter de régler l affaire à l amiable. À cette fin, la partie la plus diligente notifiera à l autre partie la mauvaise exécution du contrat par simple lettre recommandée. Si possible, cette notification s accompagnera d une proposition de solution. L autre partie dispose d un délai de 15 jours à compter de l envoi de la lettre recommandée pour en confirmer la réception et accepter la solution proposée. Faute d accord et avant de faire valoir leurs droits en justice, les parties tenteront de trouver un compromis par la voie de négociations qui seront engagées dès qu il apparaîtra que l affaire ne peut être réglée à l amiable. Les négociations se tiendront à l'adresse indiquée au point «fonctionnaire dirigeant» de la partie II en présence des personnes désignées à cette fin par les deux parties. Sauf accord contraire, les

53 Cahier des charges S&L/AO/386/ /217 négociations ne pourront excéder une durée de 30 jours calendriers, à compter de la première lettre recommandée. Tous les litiges relatifs à l exécution de ce marché sont exclusivement tranchés par les tribunaux compétents de l arrondissement judiciaire de Bruxelles. La langue véhiculaire est le français ou le néerlandais. Le pouvoir adjudicateur n est en aucun cas responsable des dommages causés à des personnes ou à des biens qui sont la conséquence directe ou indirecte des activités nécessaires à l exécution de ce marché. Le prestataire de services garantit le pouvoir adjudicateur contre toute action en dommages et intérêts par des tiers à cet égard. 9. Amendes et Pénalités. En application de l article 9, paragraphe 4 de l AR du 14 janvier 2013, l attention des soumissionnaires est attirée sur le fait que, dans le présent cahier spécial des charges, il a été dérogé à l article 154 de l arrêté royal du 14 janvier 2013 relatif aux amendes en raison de l importance accordée par le Service Public Fédéral FINANCES à la mise en production dans les délais impératifs fixés dans chaque commande 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 Amendes Pour tout service non exécuté dans les délais imposés par le pouvoir adjudicateur, par infraction à ces délais et par jour de calendrier de retard, une amende forfaitaire de 1.250,00 EUR sera appliquée de plein droit pour non-exécution. Les amendes s appliquent de plein droit sans formalité ni avis quelconque Imputation des amendes et pénalités IMPORTANT Pour rappel, le soumissionnaire propose dans son offre un S.L.A. dont les dédommagements s ajoutent aux pénalités et amendes imposées par le pouvoir adjudicateur. Le montant des dédommagements dus par le prestataire en cas de non-respect de son SLA est repris expressément sur la facture et déduit du montant à payer par le pouvoir adjudicateur.

54 Cahier des charges S&L/AO/386/ / Principes généraux du marché. E.PRESCRIPTIONS TECHNIQUES 1.1. Introduction Le soumissionnaire est censé avoir pris connaissance des exigences en matière de «normes ICT», y compris les principes de base de FUP (Finances Unified Process) définis par les projets «SUPDEV», «Identity Management» et «Gestion de projet» du SPF Finances dans le cadre de la structure informatique centralisée (la documentation de cette infrastructure et de ses normes est disponible sur le portail du SPF Finances, à l adresse Peuvent y être consultés notamment les directives en matière d utilisation de «Standards ouverts» et le détail des «Fondements ICT» (Architecture Building Blocks et méthodologie FUP). Les documents présentés sous les rubriques «Fondements ICT» et «Standards ouverts» doivent être considérés comme faisant partie intégrante du présent cahier spécial des charges. Le soumissionnaire s engage expressément à respecter les fondements actuels et futurs dans le cadre de l exécution du présent contrat. Le non-respect de cette règle essentielle du cahier spécial des charges peut entraîner la nullité de l offre. Dans le cadre de la réforme Coperfin, le SPF Finances a entrepris la transposition de ses applications, à l origine écrites en COBOL et déployées sur divers mainframes, vers des environnements modernes et conformes aux standards techniques actuels. Le langage Java constitue la pierre angulaire de cette stratégie. Cette migration est à l heure actuelle très avancée. Les applications métiers de l Administration Générale de la Fiscalité, qui à quelques exceptions près sont opérationnelles (en production) (voir ci-après pour plus de détail), constituent l applicatif cible du présent cahier spécial des charges. Le soumissionnaire est invité à consulter le site Internet ( pour se faire une idée du contexte du projet. Dans ce cadre, et en vue de réaliser ses missions avec toujours plus d efficacité et d efficience, le SPF Finances, et plus spécifiquement l Administration Générale de la Fiscalité, souhaite donc mettre en concurrence la maintenance de ses applications afin d assurer leur évolution et leur pérennité tout en améliorant leur qualité et en optimisant l utilisation des ressources nécessaires à leur fonctionnement. Les domaines métier suivants sont visés: Domaine TVA : Intervat, STIR TVA (back-office TVA), Stiron TVA, MOSS (Mini One Stop Shop) Domaine impôts directs personnes physiques : TAXI (back office de gestion des dossiers IPP), TOW (Tax-On-Web), BOW (Belcotax-On-Web), PDS

55 Cahier des charges S&L/AO/386/ /217 (Proposition de Déclaration Simplifiée), Calculatrix (Calcul, enrôlement de l impôt et des amendes administratives) Domaine impôts directs personnes morales : Biztax (partie front-office et partie back office), Calclsoc (Calcul, enrôlement de l impôt) Domaine transnational AgFisc: STIRInt, FATCA, Auto_DT Domaine tranversal AgFisc: STIR Contrôle, STIR Recherches, Prm-on-web, FinELTS. L attention est attirée sur le fait que la liste des applications citées ci-dessus n est nullement exhaustive mais constitue le cœur de la chaine de traitement relative à chacun des domaines considérés. La mention pour chaque métier de ses applications les plus critiques et emblématiques permet également de mieux cibler le scope de chaque lot. D autres applications relevant de l Administration Générale de la Fiscalité sont donc susceptibles de voir leur maintenance exécutée dans le cadre du présent marché et seront rattachées au lot du domaine fonctionnel correspondant Objectifs généraux du marché Le SPF Finances se doit d utiliser le plus efficacement possible les ressources publiques qui sont mises à sa disposition dans le cadre de l exercice de sa mission. Une attention particulière sera donc apportée aux propositions faites par le soumissionnaire pour améliorer l efficience, l efficacité et la qualité des développements réalisés dans le cadre de la maintenance (tous types), notamment dans les domaines suivants : Mode de collaboration entre lots de support/développement et lot de testing Les équipes en charge du développement et du testing étant distinctes et dépendantes d adjudicataires différents, l organisation d une collaboration efficace entre elles, tout au long du processus de développement, constitue un facteur clé de succès. Ce point étant central dans l approche de professionnalisation et d amélioration de la qualité initiée dans le présent cahier spécial des charges, le SPF Finances accordera une attention particulière à ce point Intégration entre les applicatifs fonctionnellement liés Ainsi que décrit plus en détail ci-dessous, les développements ont été répartis en lots distincts et indépendants réunissant dans la mesure du possible les applicatifs présentant une forte intégration fonctionnelle et/ou technique. C est le cas en particulier pour les domaines IPP et TVA. Cette approche intégrée vise à améliorer l intégration entre divers composants étroitement liés mais développés au cours du temps par des prestataires différents et à l aide de technologies pouvant diverger. L attention sera donc apportée à des propositions favorisant l amélioration dans tous les domaines de la qualité Amélioration de la qualité des applications (disponibilité, performance, optimisation, documentation, qualité du code, consommation de ressources, ). Les applications mises à disposition du personnel de l Administration générale de la Fiscalité (SPF Finances) et des Citoyens (E-Gov), bien qu en constante évolution pour répondre à l évolution des besoins (la description et le traitement des différents types de maintenance seront abordés plus avant dans le présent cahier spécial des charges), sont arrivées à un niveau de maturité couvrant les besoins des utilisateurs (sauf exceptions signalées). Des informations remontées via les différents canaux d information, il ressort de manière

56 Cahier des charges S&L/AO/386/ /217 récurrente qu une attention particulière doit être consacrée à l amélioration de la qualité notamment d un point de vue disponibilité, performance, robustesse et impact sur les environnements (optimisation de la charge). L attention du pouvoir adjudicateur portera donc sur les propositions dans ce domaine Souplesse et réactivité Dans le cadre de l exécution de sa mission, l Administration Générale de la Fiscalité est de manière régulière amenée à introduire auprès de l IT des demandes d adaptation («Change Requests»), parfois conséquentes et/ou urgentes, auxquelles il peut s avérer difficile de répondre en termes de scope et/ou de délai de réalisation. Le SPF Finances, et l Administration Génération de la Fiscalité en particulier, intègrera l approche en la matière, notamment quant aux propositions visant à étendre la capacité IT à mieux cerner les besoins et à y répondre au mieux Implication du personnel interne et renforcement de la maîtrise Le SPF Finances souhaite clairement maintenir, et dans la mesure du possible renforcer, l implication de son personnel dans les travaux visés au présent cahier. Dans un contexte de ressources toujours plus rares, il est cependant peu opportun de fixer un objectif fixe en matière de participation du personnel ICT interne. Dans ce cadre, nous attendons des propositions en matière de Co-sourcing adaptées à ce contexte variable et visant une valorisation maximale des ressources mises à disposition par le SPF Finances Maîtrise des coûts La rencontre des différents objectifs présentés devra notamment induire à terme une meilleure maîtrise (et donc une réduction) des coûts liés à la maintenance des applications visées par le présent marché. Le soumissionnaire est donc invité à mettre en lien ses propositions avec cet objectif et notamment s engager à une réutilisation maximale des composants disponibles, qu ils aient été développés par lui ou mis à disposition par d autres (par exemple un module de signature électronique) Vision et encadrement Vu le délai sur lequel s étend le marché, le soumissionnaire est invité à exposer sa vision de l'exécution du marché, dans le cadre spécifique de l'environnement du SPF Finances. À cette fin, le soumissionnaire décrira de façon générale les aspects suivants, qui feront partie de la phase de préparation et de réalisation : Garantie de réalisation des projets ; Capacité de réaliser les projets à relativement court terme ; Planning et flexibilité du planning ; Flexibilité dans l exécution des projets ; Communication ; Rapportage ;

57 Cahier des charges S&L/AO/386/ /217 Vision à long terme et orientation avenir ; Exploitation des opportunités ; Tous les autres éléments que le soumissionnaire juge utile de mentionner Le prestataire de services utilisera des techniques avancées et éprouvées en matière de gestion de projet, d organisation et de documentation pour : Garantir que toutes les tâches sont définies clairement et logiquement, et comprises de toutes les parties concernées ; S'assurer que tous les membres de l équipe assument des responsabilités claires et bien délimitées, et que ces responsabilités sont communiquées à toutes les parties intéressées ; Veiller à la circulation de l information au sein de l équipe de projet afin de contribuer à la réalisation d une solution intégrée ; Obtenir à temps du pouvoir adjudicateur toutes les informations nécessaires au bon accomplissement du travail ; Suivre et respecter les dates limites et les plannings fixés ; Rédiger une documentation détaillée et correcte des produits et activités ; Mettre en place un rapportage détaillé et à jour concernant la progression, les problèmes, les points à suivre, les risques, etc., concernant les activités de projet menées à bien ou restant à exécuter Economie générale du marché Séparation des aspects développement/support et testing Soucieux d améliorer la qualité de ses applications informatiques, le SPF Finances a depuis quelques années entamé une démarche de professionnalisation du testing applicatif au sens large, ce dans l esprit suivant : Professionnalisation des tests dans le cadre de la méthodologie élaborée pendant les projets PTC (Performance Test Center) et TCC (Test Competence Center) ; Meilleure garantie d une documentation mise à jour ; Mesure indépendante de la qualité du code, notamment grâce aux outils d analyse tels que CAST,Fortify et SonarQube ; Séparation claire des responsabilités entre les équipes respectivement en charge du développement et du testing ; Assistance au Business pour l élaboration des scripts de test (Test Cases) et des critères d acceptation ; Intégration de la composante testing (fonctionnel, performance) dès le début du cycle de maintenance (Définition des requirements). Dans ce cadre, le Département Quality Assurance et IT Process Support a été créé afin d englober l ensemble des aspects liés à la qualité au sens large. C est dans cette optique qu ont été créés notamment le Performance Test Center (PTC) en charge des tests de

58 Cahier des charges S&L/AO/386/ /217 charge et le Test Competence Center (TCC) en charge des tests fonctionnels. Ces 2 équipes sont complétées par l équipe de Test labo en charge des analyses de code. Le présent cahier spécial des charges distingue donc deux composantes principales conformément à la volonté de professionnalisation du volet qualité/testing : o la partie «Développement et support au projet» (4 lots indépendants regroupés selon une logique fonctionnelle), comprenant globalement les activités liés au support et au développement applicatif (à l exception des aspects spécifiquement liés au testing), o la partie «Testing» (transversale aux trois lots de développement) Vous trouverez ci-après plus de précision quant à la portée de la mission de chacune de ces deux composantes, étant entendu que la limite de responsabilité de chacune des équipe en charge (Dev vs Testing) pourra si nécessaire être précisée en kick-off.

59 Cahier des charges S&L/AO/386/ /217 Le descriptif de chaque applicatif joint en annexe précise et/ou complète le champ d action attendu de l adjudicataire dans le cadre de sa mission. Les soumissionnaires des lots 1 à 4 sont expressément invités à prendre connaissance du contenu de la composante «Testing» (lot 5) et inversément Composition des lots La partie du marché relative à la composante «Développement et support» est subdivisée en quatre lots distincts selon un critère articulé autour de la notion de domaine d activité. A titre d information, les tableaux ci-dessous précisent la composition applicative actuelle de chacun de ces lots. Les applications non énumérées dans ce document, mais dont la maintenance serait effectuée dans le cadre du présent marché, seront intégrées à l un de ces 4 lots, sur décision du SPF Finances notamment en fonction du domaine d activité concerné. Les tableaux ci-dessous précisent la situation au moment de la publication par domaine. Lot 1 (Développement et support) : Domaine TVA En production Intervat STIR-TVA Stiron TVA MOSS (Mini One Stop Shop) Oui Oui Oui 2015 Lot 2 (Développement et support) : Domaine Impôts directs - Personnes Physiques (IPP + INR PP) En production Belcotax-on-Web (BOW) Tax-On-Web (TOW) Taxi Proposition de Déclaration Simplifiée (PDS) Calculatrix : Chaine de calcul et d enrôlement IPP (impôt et amendes) Oui Oui Oui Oui Oui

60 Cahier des charges S&L/AO/386/ /217 Lot 3 (Développement et support) : Domaine impôts directs personnes morales + tranversal AgFisc En production Biztax: Module Font-Office (FO) Biztax : Modules Back- Office (BO) et Dossier Unique (DU) Stir-Contrôle Stir-Recherche PRM-on-web CalcIsoc: Chaine de calcul et d enrôlement à l Impôt des Sociétés FinELTS Oui Oui Oui Oui Oui Oui Oui Lot 4 (Développement et support) : Domaine transnational En production STIRint FATCA Auto_DT Oui Oui Oui Incompatibilité entre lots Le SPF Finances estime incompatible la réalisation d activités de développement dans le cadre des lots 1, 2, 3 ou 4 et la réalisation d activités de testing dans le cadre du lot 5. La séparation de ces activités constitue une condition indispensable à la réalisation des objectifs en matière d amélioration de qualité tels que décrits dans le présent document. En conséquence, il est précisé que lors de l attribution du lot 5 (testing), le soumissionnaire qui remporterait l un des quatre premiers lots sera d office écarté pour l attribution du lot 5 sauf si le soumissionnaire a choisi le lot 5 comme premier choix dans son ordre de préférence via le formulaire d offre. Dans ce cas, le soumissionnaire sera écarté pour l attribution du lot 1, 2, 3 ou 4. Les soumissionnaires retenus pour l un des lots de développement (lots 1, 2, 3 ou 4) ainsi que tout soumissionnaire intervenant comme membre d une association sans personnalité juridique constituée pour l exécution du présent marché ou comme sous-traitant d un soumissionnaire des lots 1, 2, 3 ou 4 seront de même écartés.

61 Cahier des charges S&L/AO/386/ /217 A noter que les associations sans personnalité juridique sont autorisées dans le cadre du présent marché. Chacun des membres d une telle association étant responsable solidairement pour l exécution du lot. Le droit d accès (voir point Droit d accès du volet C. «Attribution») étant vérifié auprès de chaque membre de l association, les capacités économique, financière et technique (voir point Sélection qualitative du volet C «Attribution») étant évaluées dans le chef de l association. Le SPF Finances attribuera d abord les lots de développements (lots 1, 2, 3 et 4) puis le lot de testing (lot 5) Collaboration entre les équipes de la composante «Développement et support» et celle en charge du «Testing» et le service de Gestion des Applications de l Administration générale de la Fiscalité. L'AG Fisc a développé une base de données en gestion propre dans SQL Server. Cette base de données appelée BDM (Business Data Management) est conçue comme une plateforme qui doit servir à la conservation claire et à un endroit unique de tous les lay-outs des applications opérationnelles. Le contractant s'engage à adapter les modifications qu'il apporte pendant sa mission aux layouts des tableaux ou aux fichiers de la base de données dans cette base de données BDM. Les droits d'accès nécessaires à cet effet lui seront accordés. Ainsi qu indiqué plus haut, les travaux relatifs à la composante «Testing» (voir partie du cahier spécial des charges relative au lot 5) seront réalisés par une équipe distincte (interne ou externe au SPF Finances) et indépendante de l équipe en charge des développements (lots 1 à 4). Dans un contexte impliquant les équipes de contractants différents, le SPF Finances souhaite naturellement qu un mode de collaboration efficace soit mis en place et demande donc que des propositions soient faites en la matière. Les propositions seront jugées quant à leur qualité intrinsèque mais aussi quant à l ouverture permise par le modèle proposé, s agissant d accorder les propositions des parties en présence pour chaque lot. Cette intégration est sous-tendue par le «Modèle en V», standard du marché qui relie chaque phase du cycle de vie de développement à la phase correspondante en matière de testing. Il est ici question d une collaboration continue dès l élaboration des requirements et jusqu à la complétion du rapport final de test. Lors du kick-off officialisant la prise en charge de l application, la stratégie globale de collaboration entre les adjudicataires des lots de testing et de développement sera présentée. L étendue précise, la profondeur de cette collaboration, et les objectifs de la période, seront déterminés conjointement par le SPF Finances et les adjudicataires en présence et validés en Comité de Pilotage dans le cadre de la préparation de chaque cycle annuel. Prise d effet de la maintenance Pour rappel, le SPF Finances n est pas tenu de commander la maintenance annuelle prévue au présent cahier. Les obligations, décrites au présent cahier spécial des charges, pour une période donnée découleront du bon de commande préalablement transmis à l adjudicataire.

62 Cahier des charges S&L/AO/386/ /217 A noter également le strict découplage entre l octroi des composantes «Développement/support» et «testing». L émission d un bon de commande pour la première n implique donc aucunement une commande pour la seconde, et inversement.

63 Cahier des charges S&L/AO/386/ / Description des applications Une description des applications citées ci-avant est fournie en annexe du présent cahier et couvre les domaines suivants : Description fonctionnelle Description métier des fonctionnalités couvertes par l applicatif Cycle de vie L exécution du présent cahier des charges est basée sur un cycle d exécution annuel, découlant du cycle budgétaire lui-même annualisé. Le présent volet a donc pour vocation de préciser les contours des «prestations récurrentes» en matière de support et de maintenance annuels. Evolutions prévues Cette partie a pour objectif d informer le soumissionnaire quant aux évolutions prévues et/ou probables à la date de rédaction du présent document, ce afin qu il dispose de la vue la plus complète possible. Ces informations sont assurément sujettes à évolution et ne constituent aucunement un engagement de réalisation Modalités d exécution Le SPF Finances pouvant, à certains moments, disposer de ressources internes suffisantes à l exécution de la maintenance, le pouvoir adjudicateur se réserve le droit de ne procéder à aucune commande et ce, sans dommages et intérêts possibles dans le chef des adjudicataires. 1. Simultanéité des développements Pour diverses raisons, notamment de respect des prescriptions légales, il est possible que les réalisations de certains projets se chevauchent, impliquant des pics en matière de charge de travail. Le soumissionnaire doit pouvoir faire face à ces fluctuations le plus souvent impératives. 2. Méthodologie FUP La réalisation des projets devra suivre la méthodologie FUP. Toutefois, pour des raisons historiques, le niveau actuel d intégration avec FUP peut différer d une application à l autre. Dans ce cadre, même si le projet/application n en intègre pas la totalité des principes, le SPF Finances souhaite entamer un trajet visant l intégration de la méthodologie. Si les objectifs précis en la matière seront fixés annuellement et par application/domaine, le soumissionnaire est invité à émettre des propositions en la matière et décrire les profils nécessaires pour ce volet. 3. Cycle de maintenance Le cycle global de maintenance (dérivé de FUP) peut globalement être découpé comme suit (une description plus détaillée de ce cycle est fournie en annexe) : Phase d initiation ; Phase préparatoire et de négociation ; Phase budgétaire (hors FUP) ;

64 Cahier des charges S&L/AO/386/ /217 Phase de réalisation Transfert de connaissance 1. Documentation Les documents devront systématiquement être fournis sous format électronique et respecter les standards et templates mis à disposition par le SPF Finances. L exploitation de ces documents ne devra pas requérir, sauf accord explicite du SPF Finances, l utilisation d outils spécifiques requérant l acquisition de licences. Le SPF Finances demande toujours aussi le matériel didactique, indépendamment du fait que le projet nécessite ou non une formation. La documentation technique doit être disponible en français ou en néerlandais ou en anglais. Le SPF Finances se réserve la possibilité d accepter aussi l anglais pour la documentation technique. Dans ce dernier cas, les deux parties doivent être d accord. Notez que toute la documentation doit être tenue à jour sans frais supplémentaires pour le SPF Finances pendant la durée de la maintenance. La documentation de l utilisateur final doit être disponible en français, en néerlandais et pour certaines applications en allemand voire en anglais (ex. MOSS). Dans ce cadre, les autres langues ne sont pas autorisées. Le soumissionnaire décrira la méthode d'actualisation de la documentation. Le soumissionnaire s engage à donner au SPF Finances un droit de regard sur la confection de la documentation durant l'exécution du projet. L offre décrit comment le soumissionnaire voit cette possibilité. Le SPF Finances peut copier les manuels pour les besoins de leur diffusion interne. 2.Formation Il convient de souligner que la fourniture de cours ne concernera qu une minorité des projets. Il ne faut donc aucunement supposer que cette forme de transfert de connaissances fera partie de l'encadrement d'un projet. Le soumissionnaire doit donc en première instance se concentrer sur le coaching et la documentation technique et fonctionnelle notamment nécessaires aux formations. Chacune des formations requises doit être proposée en français et en néerlandais. La formation sera organisée à 3 niveaux : Utilisateurs : une formation «train-the-trainer» est prévue pour les utilisateurs, par groupes de 10. En complément, l adjudicataire peut présenter d autres modes de formation possible, par exemple l e-learning. Gestionnaire de systèmes : le soumissionnaire propose une formation commune aux gestionnaires et aux développeurs du système. Cette formation est dispensée à des groupes de 5 personnes. Service Desk (remarque : le service desk opère suivant les principes ITIL) : Le soumissionnaire propose ici une formation brève, par groupes de 10 personnes. Cette formation est organisée de telle façon que les membres du service desk

65 Cahier des charges S&L/AO/386/ /217 acquièrent une connaissance suffisante de l application pour remplir leur fonction, ainsi que le bagage nécessaire pour transférer cette connaissance à leurs collaborateurs (train-the-trainer). Les besoins effectifs en la matière seront exprimés et validés par le Business et l ICT du SPF Finances en début de cycle et le cas échéant valorisés et intégrés au contrat annuel de maintenance (voir cycle annuel). La documentation doit être adaptée aux nouveaux développements. 3.Continuité en cas d arrêt d un projet ou du programme Le soumissionnaire doit prouver que les mesures sont prises pour garantir la sûreté et la continuité du marché s il n est pas en mesure de le poursuivre (p.ex. en cas de faillite). 4.Continuité du service et pool de connaissances Dans son offre, le soumissionnaire décrit les moyens et les mesures qu il compte mettre en place pour assurer la continuité du service. L on songe en premier lieu aux mesures internes que l adjudicataire prendra pour installer un centre de compétence afin que les nouveaux membres de l équipe puissent s intégrer efficacement et rapidement dans la partie de la mission qui leur incombe. Il en va de même des éventuels remplacements au sein de l équipe. Le soumissionnaire peut développer la description de son service sur ce plan. Vu la longue durée du marché, le soumissionnaire prévoit aussi de donner la formation nécessaire à ses collaborateurs si le besoin s en fait sentir, sans frais pour le SPF Finances. Le soumissionnaire décrit par ailleurs les connaissances et l expérience qu il peut mobiliser à tout moment pour exécuter le marché. La description couvre aussi ce que le soumissionnaire peut offrir en tant qu entité au SPF Finances en termes de connaissances et d expérience (autrement dit les capacités utiles du «pool» d employés dans lequel le soumissionnaire peut puiser si nécessaire). 5.Disponibilité Il est clair qu au fil d un marché de cette nature, la charge de travail peut varier sensiblement. L adjudicataire doit pouvoir y réagir adéquatement. La charge est notamment influencée par les périodes de vacances, les pointes de travail, la nécessité de grands changements, mais aussi le niveau d importance (bas, moyen, haut, critique) des changements demandés ou des incidents. Le soumissionnaire indique clairement dans quelles marges il réagira et comment. 6.Back-office Le soumissionnaire décrit par ailleurs le support qu il peut assurer en vue d un bon suivi du marché, autrement dit le «back-office». On songe notamment ici à la rapidité de réaction de l adjudicataire, à la qualité de la communication et en général à tout ce qui peut favoriser une bonne collaboration de l adjudicataire avec le personnel du SPF Finances ainsi que la bonne exécution du marché. Le soumissionnaire indique aussi comment il voit la collaboration dans les équipes composées d'employés de sa société et de personnes dépêchées par le SPF Finances.

66 Cahier des charges S&L/AO/386/ / Co-sourcing Compte de tenu de la situation en matière de personnel affectable aux projets IT, le SPF Finances ne peut garantir la disponibilité de ressources internes pour les différents projets visés dans le présent cahier spécial des charges. Néanmoins, la volonté affichée par le SPF Finances est, dès lors que les conditions sont réunies en matière notamment de disponibilité et de niveau de compétence, d intégrer son personnel à ces projets. Un accord (concrétisé par l offre du contractant) sera établi à chaque début de cycle, dans lequel seront notamment mentionné le profil et le nombre de ressources disponibles que le SPF Finances mettra à disposition au cours de ladite période pour réaliser les objectifs fixés de commun accord. Donc, dès lors que du personnel sera affecté au projet en co-sourcing, le soumissionnaire est tenu de respecter les modalités décrites ci-dessous. Il précisera dans son offre au présent marché comment il propose la mise en place pratique de ce mode de collaboration avec les agents du SPF Finances. Le SPF Finances met en place une structure de co-sourcing dans les buts suivants : Favoriser le transfert de connaissance entre le personnel de l adjudicataire et les collaborateurs internes du SPF Finances ; Diminuer les coûts de développement, des tests et de maintenance des projets. Ce co-sourcing est à considérer comme fondement, au même titre que les standards ICT du département. Le contractant est tenu d en respecter les modalités, et seul le SPF Finances est habilité à décider de ne pas y faire appel, que ce soit pour un projet entier ou pour des parties de projet. En ce qui concerne l encadrement administratif, l équipe sera sous la responsabilité d un chef de projet du SPF Finances. Dans toutes les offres qui seront émises par l adjudicataire, il y aura lieu d indiquer de manière explicite les charges de travail réalisées en co-sourcing. Ces lignes donneront forcément lieu à une charge financière nulle dans les tableaux de prix. Dans le cas de profils pour lesquels aucune correspondance n est trouvée dans ceux de cosourcing, l adjudicataire décrira précisément quelles en sont les spécificités et en quoi les profils de co-sourcing ne répondent pas au besoin. Le recours au co-sourcing ne peut en aucun cas enlever ou diminuer la responsabilité du contractant qui devra veiller à un encadrement suffisant du personnel à intégrer. En particulier, le co-sourcing ne pourra pas être utilisé par le contractant comme explication pour du retard de livraison ou pour la présence de failles ou d erreurs dans les applications mises en œuvre. Par ailleurs, toute offre basée sur le co-sourcing décrira de manière intensive la méthodologie qui sera employée par le soumissionnaire pour la mise en œuvre pratique de celui-ci. L accent sera notamment mis sur les méthodes de collaboration, l intégration des équipes, les formations, la répartition des tâches et le suivi et l évaluation des compétences.

67 Cahier des charges S&L/AO/386/ / Personnel mobilisé par l adjudicataire Pour l exécution des projets, le soumissionnaire doit proposer les profils de base via sa liste de prix (avec un prix par profil). Il précise les compétences de chaque profil. Les compétences décrites en annexe au présent cahier sont à considérer comme un minimum. a) Vu l importance des compétences des personnes proposées par le soumissionnaire, le SPF Finances demande que les CV soient soigneusement rédigés et mis en relation avec le présent marché, notamment les profils décrits en annexe 3. Une offre dont les CV ne permettraient pas de s assurer de la complétude par rapport aux profils est susceptible d être considérée comme irrégulière. L expérience requise constitue à ce titre un critère absolu. b) Etant donné le contexte bilingue dans lequel l équipe de l adjudicataire sera amenée à évoluer, le bilinguisme (FR/NL) de l équipe est requis. A cette fin, il est attendu que minimum 80% de l équipe ait pour langue maternelle le français ou le néerlandais et que ces deux langues nationales soient représentées dans l équipe. c) L attention du soumissionnaire est également attirée sur le fait que le SPF Finances entend que les conditions évoquées aux points a) et b) ci-dessus devront être respectées tout au long du contrat.

68 Cahier des charges S&L/AO/386/ / Composante «Développement et Support» (Lots 1 à 4) 2.1. Missions La mission principale sera de renforcer le département «ICT Development» du service d'encadrement ICT par l apport d équipes externes chargées afin d organiser et d'exécuter d une part les travaux de maintenance des applications de l Administration Générale de la Fiscalité et d autre part leur support opérationnel. Pour rappel, les aspects liés au testing, autres que ceux relevant du travail des développeurs, sont repris sous la responsabilité du lot 4. Les lots 1 à 4 comprennent notamment les activités suivantes : Support au Business dans l élaboration et/ou la formalisation des requirements et des analyses fonctionnelles Analyse technique Développements (y compris évidemment les tests unitaires et les tests d intégration des composants) Intégration avec la partie «Testing» prévue au lot 5 (collaboration, planification intégrée, transfert d informations,.) Rédaction / mise à jour des délivrables prévus dans le projet conformément aux standards du SPF Finances (par exemple les documents FUP) Support à la production (notamment support au diagnostic technique et/ou fonctionnel). Support à la production par la livraison de scenarii de monitoring end-2-end permettant la mesure du niveau de fourniture de service Support aux équipes de test (entre autres par l assistance à fournir lors du déploiement de nouvelles versions de l application) Support au Business par la fourniture de données d analyse et/ou statistiques Exécution des tests des composantes (unit tests)

69 Cahier des charges S&L/AO/386/ / Mode d exécution au sein d un lot Évaluation des services exécutés Au moment où les services seront exécutés, une évaluation portera sur leur qualité et leur conformité. A cette fin, le service d Encadrement ICT a mis en place au sein de son département Qualité un comité en charge (QUAC) de veiller au respect de ces aspects (respect des normes, qualité des livrables (documentation, code, ). Ce comité émettra, sous forme de procès-verbal, un avis lors de toute demande de réception (partielle ou totale) des prestations effectuées. Les services incorrects ou non conformes devront être corrigés préalablement à la soumission d une nouvelle demande de réception Support technique par téléphone service desk ITIL Les projets de maintenance comprendront un support par téléphone en 2ème ligne. Le service demandé ci-dessous doit être assuré les jours ouvrables de 7h à 19h. Le SPF Finances met un service desk à la disposition de tous les utilisateurs finaux. Le service desk assure le traitement de tous les types d appels. Le soumissionnaire installera un helpdesk de deuxième ligne pour recueillir les problèmes liés au non-fonctionnement ou au mauvais fonctionnement de l application dont l adjudicataire a la responsabilité, pendant toute la durée du projet. Tous les appels que le service desk ne peut résoudre à distance seront aiguillés vers ce helpdesk. En première instance, ce helpdesk sera accessible au service desk du SPF Finances, qui se chargera de toutes les interventions possibles à effectuer sur les logiciels à entretenir. Les services proposés par l adjudicataire seront introduits dans le respect de la méthodologie ITIL, appliquée au sein du SPF Finances. Cela signifie notamment que la gestion des incidents, problèmes, changements, etc. doit être conforme aux méthodes en vigueur au sein du SPF Finances. La première ligne se chargera de distinguer les incidents d infrastructure et les incidents applicatifs. La communication entre la première et la deuxième ligne est décrite par le soumissionnaire. Elle doit permettre à la première ligne de mettre l utilisateur en contact avec la deuxième ligne si la première soupçonne que l incident signalé va nécessiter une intervention sur place ou une communication entre deuxième ligne et utilisateur. Dans son offre, le soumissionnaire indique comment il entend appliquer les normes ITIL dans sa tâche et comment il va acquérir les connaissances nécessaires pour s intégrer dans les processus existants. La transmission des appels entre le service desk du SPF Finances et le helpdesk de deuxième ligne que l adjudicataire doit mettre en place passera au moins par les canaux suivants : Téléphone et à la disposition des opérateurs du service desk du SPF Finances. Automatiquement ou semi-automatiquement, en reliant l outil du SPF Finances (HP Service Management) à l outil utilisé par le service manager pour la gestion et le suivi des appels. Le soumissionnaire expliquera dans son offre les canaux qu il supporte. Il précisera en particulier :

70 Cahier des charges S&L/AO/386/ /217 o o o o o Les moyens dont l Administration disposera pour contrôler à tout moment l état des appels ouverts. Les moyens dont l Administration disposera pour contrôler le respect du SLA. La façon dont il propose éventuellement de synchroniser les deux outils (SPF Finances et soumissionnaire). Les rapports qu il mettra à la disposition du SPF Finances pour le suivi de la qualité du service. La méthode éventuelle pour résoudre à distance certains problèmes de fonctionnement. Le soumissionnaire doit aussi prévoir un retour d information vers le service desk à propos des appels qui lui ont été transmis ; autrement dit, il doit informer le service desk de la suite qu il leur a réservée, via un canal préalablement annoncé, canal qui permet le suivi des appels. Le soumissionnaire expliquera le service en tenant compte de tous les points évoqués ici. Il fournira aussi les autres services qu il juge nécessaires. Tout changement au système entraîne la livraison d un ensemble de code source et de documentation à inclure dans le système de gestion des versions du SPF Finances. Les changements ne sont effectués qu après l accord du SPF Finances. L adjudicataire transmettra toutes les informations nécessaires à la CMDB (configuration management database), en suivant les procédures imposées par le SPF Finances. Ces procédures seront communiquées après attribution du marché. Elles pourront changer pendant la durée du contrat. Le SPF Finances attire l attention des soumissionnaires sur la grande importance attachée à la surveillance de l intégrité de la CMDB. Dans leur offre, les soumissionnaires préciseront clairement les mesures qu ils proposent à cet effet Profils Rappel : le chapitre «Personnel de l adjudicataire» détermine l engagement de la firme quant au nombre minimum de personnes à garantir par profil (voir la table des capacités). Cet engagement est une prescription technique qui mène à une offre irrégulière si elle n est pas rencontrée, et à des pénalités éventuelles en cas d exécution incomplète de l offre. - le Task Manager : dont les activités principales sont la planification, la communication, la gestion (pouvant être intégrale, en ce compris le rapportage selon les prescriptions du SPF Finances) du projet et la gestion de son équipe et des tâches et activités des personnes associées à une maintenance donnée ou au projet. - le Lead Technical Architect / Methodologist : dont les activités principales dont de maîtriser, d'intégrer, d'expliquer, d'imposer, de contrôler, de coacher, de communiquer, d'être représentant au comité tactique, au cab ou à tout comité qui requiert son expertise, et ce, en regard de la mise en application des standards techniques et méthodologiques du spf finances; il joue aussi le rôle d'assurance projet pour le Task Manager. - l'analyste Business d Application / Métier expert : notamment chargé d assister le business à la capture des besoins conformément à la discipline FUP-D1 ou autre méthodologie

71 Cahier des charges S&L/AO/386/ /217 assimilée (au choix du SPF Finances), essentiellement chargé - conformément à la discipline FUP-D2 ou autre méthodologie assimilée (au choix du SPF Finances), - d'analyser et de formaliser les requirements métier, avec une approche Use-Case centric, et la coopération avec le business et les testeurs. - le Designer / Data Architect expert, également appelé Analyste technique : notamment chargé - conformément à la discipline FUP-D3 ou autre méthodologie assimilée (au choix du SPF Finances) - de réaliser les spécifications des requirements (fonctionnels et non fonctionnels) et les modèles de données essentiellement dans le JEE. - le Développeur senior : notamment chargé du développement applicatif Java/JEE complet et autres systèmes/technologies en dépendance, de la documentation technique, du déploiement (y compris la réalisation des documents et l'utilisation des processus et outils), des tests élémentaires (unitaires, intégration), et de comprendre les autres langages de programmation. Un senior doit présenter les qualités suivantes : Composants et fonctions Lecture / Passif Modification / Actif Architecture / Maîtrise sous jacente Approfondi/Expertise Général/Approfondi Général/Approfondi Concepts/Général Un expert doit présenter les qualités suivantes : Composants et Lecture / Passif Modification / Architecture / Maîtrise sous fonctions Actif jacente Expertise Expertise Expertise Approfondi Avec : Général = utilisation courante (des concepts principaux) Approfondi = utilisation autonome et spontanée (de concepts avancés) Expertise = compréhension naturelle et complète (de tous les concepts) Informations additionnelles sur les compétences et expertise Des compétences et expertises doivent être démontrées par CV. Selon le profil, elles sont classées en deux groupes : le groupe principal (minimum requis) et un éventuel groupe secondaire (atout). Le niveau Senior et une expérience d au moins 6 mois doivent être couverts par les profils pendant toute la durée du contrat pour l ensemble des disciplines listées du groupe principal. Les personnes concernées doivent être disponibles immédiatement en début de contrat. Des pénalités sont dues de plein droit en cas de non respect de cette disposition. Le niveau Senior doit être couvert par les profils dès la remise d une offre impliquant une ou plusieurs des matières du groupe secondaire. Les personnes concernées doivent être disponibles au démarrage du projet. La date de démarrage probable est annoncée 15 jours calendrier à l avance par une autorité du SPF Finances. Des pénalités sont dues de plein droit en cas de non respect de cette disposition. Dans le cas où la firme ne peut pas remplir ces obligations du point de vue du niveau de séniorité dans les matières nécessaires, une période d on-boarding de deux mois est autorisée, pendant laquelle la firme s engage à former (25 à 50% d un ETP) le nouveau

72 Cahier des charges S&L/AO/386/ /217 membre d équipe, et à le mettre à disposition du SPF Finances (le reste du temps) gratuitement. La firme démontre cela par un rapport sur les formations suivies ces dernières doivent concerner la matière manquante et les prestations effectuées. Des pénalités sont dues de plein droit en cas de non-respect de cette disposition. Sauf exception dûment justifiée, les personnes dont les CV sont proposés dans l offre doivent être présentes depuis au moins 6 mois dans l entreprise. Compétences et expertise pour le profil Task Manager Un CV doit au minimum porter sur les matières suivantes (groupe principal), qui peuvent être détaillées selon la spécialité du profil : - Java/JEE project management - Maven, Jenkins et autres technologie associées - RUP, UP - Scrum+XP - PRINCE2 Groupe secondaire : - Redmine ou outil analogue - ITIL Compétences et expertise pour le profil Lead Technical Architect / Methodologist Un CV doit au minimum porter sur les matières suivantes (groupe principal), qui peuvent être détaillées selon la spécialité du profil : - Java/JEE - Data Architecture - Web User Interface Design - Communication inter-applicative - JEE Architecture - Application Architecture - JSF1 et 2, STRUTS 1 et 2 - Maven, Jenkins et autres technologie associées - RUP, UP - UML and Patterns - Scrum+XP Compétences et expertise pour le profil Analyste Business d Application / Métier expert Un CV doit au minimum porter sur les matières suivantes (groupe principal), qui peuvent être détaillées selon la spécialité du profil : - Analyse d application Java/JEE - Analyse et conception de modèles de données - Analyse des Web User Interface - Analyse de la Communication inter-applicative - RUP, UP - UML - Scrum+XP - Analyse des Use Case

73 Cahier des charges S&L/AO/386/ /217 Compétences et expertise pour les profils Designer / Data Architect expert et Développeur senior Un CV doit au minimum porter sur les matières suivantes (groupe principal), qui peuvent être détaillées selon la spécialité du profil : - Java/JEE - DB2 developer - JSF1 et 2, STRUTS 1 et 2 - Maven, Jenkins et autres technologie associées - RUP, UP - Scrum+XP - UML + Patterns (développement) : Groupe secondaire : -.Net - COGNOS,DATASTAGE - PHP - COBOL,BULL,IBM - Delphi 3. Composante «Testing (Lot 5). Le lot 5 du présent marché est relatif à des activités de tests spécifiques aux applications fiscales du SPF Finances Missions La mission principale sera de renforcer la division Test Management du service d'encadrement ICT par l apport des testeurs externes afin d organiser et d'exécuter les tests des applications fiscales développées et maintenues par les équipes de développement au sein du SPF Finances. Il s agit à travers ce lot 5 (Testing) de séparer les activités de tests des activités de développements des lots 1 à 4. La mission secondaire sera d'apporter de l'aide aux testeurs internes de la division de Test Management afin d'améliorer le processus de test existant Exécution des tests Par exécution des tests le soumissionnaire devra remplir les activités suivantes pour le lot testing: Réaliser des plans de test détaillés en respectant la méthodologie de test utilisée au SPF Finances (tant pour les tests statiques que dynamiques) Rassembler les données de tests à utiliser Exécuter les tests d ensembles logiques (system test & integration test) Executer les tests de l application complète (system test: performance, security, functionality & user acceptance test) en collaboration étroite avec le service Gestion des Applications (Ag Fisc) Créer et automatiser les tests de non régression Aider à l analyse des résultats Donner du feedback concernant des adaptations (résultats constatés)

74 Cahier des charges S&L/AO/386/ /217 Rédiger les rapports d évaluation dans lequel sont mentionnés la qualité constatée et les résultats, ainsi que les risques liés à l utilisation des produits Rapporter aux comités de pilotage des risques liés à la qualité des applications Participer à l amélioration de la qualité de l application (entre autre par l enregistrement des constatations réalisées durant les tests effectués et des résultats des analyses de code). Réalisation d un plan de test d intégration détaillé Fourniture d assistance aux équipes de test quant à l amélioration des méthodes de travail et des techniques de test appliquées, l extension des sortes de test appliqués et la gestion des environnements de test et données de test Contexte Environnement organisationnel Référence Le soumissionnaire pourra trouver une description de la méthodologie sous la référence :

75 Cahier des charges S&L/AO/386/ / Environnement technique spécifique aux missions Méthodologie de travail Le SPF Finances souhaite expressément améliorer la maturité du processus de test et des méthodes de test utilisées. Ceci dans le but de mettre des applications de qualité à la disposition des citoyens, des entreprises et des collaborateurs du SPF Finances. Le "leitmotiv" ici, est celui de l'amélioration permanente. On attend des soumissionnaires qu'ils aillent plus loin dans les méthodologies et expertises déjà développées par le passé. L'accent est mis sur les tests fonctionnels, de performance, de robustesse et de convivialité de l'application. De plus, une grande importance est également attachée par le biais d'une étude statistique du code source des applications à la maintenabilité et aux caractéristiques de sécurité du code. Lors de l'élaboration de l'offre, il faut tenir compte des éléments suivants: Disciplines de développement décrites dans FUP Depuis un certain temps déjà, on utilise, le développement des applications repose sur une méthodologie basée sur Unified Process. Cette méthodologie, adaptée aux exigences spécifiques du SPF Finances, est appelée FUP (=Finance UnifiedProcess). Dans le développement des applications reprises dans le scope du présent cahier des charges, les instructions de la méthodologie FUP sont en grande partie respectées. On note toutefois des écarts par rapport à la situation idéale en ce qui concerne la documentation. Il est demandé au soumissionnaire à ce cahier des charges de tenir compte des manquements au niveau du caractère complet de la base de test. Enrichissements spécifiques de la méthodologie de test : Méthodologie TMv4 et PTC La méthodologie de test développée pour le SPF Finances est largement basée sur le standard TMAP. Des affinements spécifiques pour l'exécution des tests de performance ont encore été apportés à la méthodologie de test sur la base de la méthodologie STBoX. Il est demandé au soumissionnaire de décrire à quoi ressemblera son approche. De plus, le soumissionnaire devra également indiquer de quelle manière il prévoit de donner les formations requises à ses collaborateurs pour qu'ils disposent des connaissances nécessaires pour appliquer les méthodologies et les techniques le plus correctement possible Arsenal des outils de test HP ALM La version 11.0 de HP ALM (Application life cycle management) constitue le noyau de la gestion des tests. HP ALM peut reprendre aussi bien les requirements (et notamment les requirements modifiés ou les nouveaux requirements), les définitions de release, les plans de test et les défauts constatés. Ces tools constituent en outre la base de la gestion des tests effectués et du suivi du test coverage.

76 Cahier des charges S&L/AO/386/ /217 Via HP QTP (Quick Test Professional) et UFT, cela constitue aussi la base des tests fonctionnels automatisés et des tests de régression automatisés. Le soumissionnaire est censé augmenter significativement le rythme des tests de régression automatisés en cours de mission et élargir progressivement la collection des scripts de test disponibles. Il est demandé au soumissionnaire de décrire sa vision des tests automatisés et d'indiquer son approche dans ce domaine HP Performance center Un accent important sera mis sur la gestion de la performance. Un élément central à ce niveau sera le HP Performance center toolset qui permet d'effectuer des stresstests et des loadtests. Toute régression de la performance doit en tout temps être évitée. On attend, au minimum, qu'à chaque release majeur d'une application, un projet loadtest soit effectué dans le but de surveiller la performance. Il est demandé au soumissionnaire de décrire sa vision sur les loadtests et d'indiquer quelle est son approche dans ce domaine Compuware Dynatrace en DCRUM Outre les outils destinés à l'exécution des tests, le SPF Finances mettra aussi des outils diagnostiques à la disposition des équipes de développement et des équipes de test. Outre les moyens habituels comme les database client tools, les log file analyse tools et les webservice XML visualisation tools, les principaux outils diagnostiques mis à disposition comprendront aussi les Compuware Dynatrace et DCRUM tools. Ces outils permettront d'étudier le comportement dynamique des applications pendant les tests fonctionnels et les loadtests. On attend du soumissionnaire l'expertise nécessaire pour utiliser ces tools de manière productive. Il est demandé au soumissionnaire de décrire sa vision sur les outils diagnostiques et leur intégration dans des testtools comme HP ALM et HP Performance center Gestion des données de test Sur le plan de la gestion des données de test, le SPF Finances a encore devant lui un long trajet d amélioration à parcourir. Un outil a été acquis qui permet de procéder à des extractions à partir des bases de données de production. Cet outil, appelé SEAL, offre les fonctionnalités suivantes : Définition de schémas de bases de données en fonction des besoins d'une campagne de tests Sélection de données à partir des bases de données source Exécution des extractions et création d une base de données cible Anonymisation de données sur la base de différents algorithmes (aussi bien des données structurées dans les bases de données que des documents contenus dans les collections de documents dans Filenet) Conservation des données pour les campagnes de tests Remise des données en leur état initial après l exécution d une campagne de tests

77 Cahier des charges S&L/AO/386/ /217 Dans la pratique, l outil SEAL n est encore que peu utilisé (principalement en raison de l absence d'environnements de test distincts). Il est demandé au soumissionnaire de décrire sa vision et son approche pratique en matière de gestion des données de test ainsi que d indiquer comment générer la plus grande valeur ajoutée possible avec les moyens disponibles Environnement de test On ne dispose cependant pas encore d environnements de test pour certaines applications reprises dans le présent cahier des charges. Pour les applications pour lesquelles il n existe pas de disposition D-T-A-P des environnements, le soumissionnaire doit tenir compte du fait que les environnements manquants seront créés pendant la durée du marché (c est le cas pour la majorité des applications). Il est demandé au soumissionnaire de donner sa vision sur les évolutions souhaitées dans l aménagement des environnements de test et d indiquer dans quelle mesure son approche s écarte de la situation décrite plus haut. Il est en outre demandé au soumissionnaire de mentionner les points d attention que son expérience lui a montrés comme importants dans la gestion et l utilisation des différents environnements Profils Profils testeurs et Quality Assurance Coordinator Les profils proposés sont les seuls à pouvoir être repris dans l exécution du marché. En cas de remplacement de ces profils, les modifications de profils doivent être soumises à l accord du SPF Finances sous peine de pénalité. Une même personne peut être reprise dans plusieurs profils différents mais en cas d offre, le SPF Finances se réserve le choix de la sélectionner dans le profil désiré Compétences communes Tous les profils des testeurs (P1-P4) proposés doivent répondre à ces exigences sous peine de nullité: Certification ISTQB obligatoire sous peine de nullité de l offre. Fournir la preuve de la certification Maîtrise de la langue française et/ou néerlandaise et connaissance passive de l autre langue Minimum 3 ans d expertise dans le secteur informatique dont 2 ans dans le software testing. À peine d exclusion, les Quality Assurance Coordinators (P5) proposés doivent, au minimum, disposer des compétences suivantes : Pouvoir démontrer au minimum 5 ans d expérience dans un environnement IT, dont minimum 1 an dans une organisation de taille comparable à celle du SPF Finances. Pouvoir démontrer au minimum 2 ans d expérience de projet en qualité de responsable du contrôle qualité et/ou de l assurance qualité dans minimum 2 projets différents. Certification Prince2 ou PMBOK. Maîtrise des deux langues nationales (français et néerlandais) : o Maîtrise parfaite (niveau C2 / locuteur natif) du français ou du néerlandais. o Connaissance active et courante de l autre langue nationale.

78 Cahier des charges S&L/AO/386/ / Profils spécifiques Testeur (minimum 4 testeurs) Activités Un testeur est responsable de toutes les activités primaires de test. Ces activités sont réparties sur l ensemble du trajet de test. Premièrement, le testeur devra préparer les tests. Cela signifie qu il faudra définir la base du test et qu il faudra ensuite procéder à un intake sur cette base de test. Deuxièmement, le testeur devra exécuter les spécifications du test. Cela implique l élaboration de cas de test logiques et la préparation de cas de tests physiques. Pour cette phase, le testeur utilisera les outils de test nécessaires. Ensuite, les tests préparés seront exécutés par un testeur. Pendant l exécution des tests, le testeur rapportera correctement les éventuels manquements et en assurera le suivi. Pendant cette phase, il sera fait usage des outils de test nécessaires. Enfin, les résultats finaux des tests seront rapportés par le testeur sous la forme de conclusions, de tests réussis et ratés. Les résultats seront systématiquement complétés de preuves supplémentaires ( test evidence ) par le testeur. Profil Le testeur connaît une méthodologie de test structurée, TMap Next ou STBOX. Le testeur est également capable d'utiliser un des outils de test suivants: HP ALM, UFT ou LoadRunner/Performance Center. Outre ces compétences de nature plus technique, la maîtrise de compétences de communication est également importante dans le cadre du rôle du testeur, car le testeur doit être capable d'entretenir des contacts étroits avec les développeurs, les analystes et les chefs de projet. Le testeur doit être capable d'exprimer ses idées et ses avis de manière claire et structurée, aussi bien oralement que par écrit. Le testeur posera aussi toujours des questions complémentaires pour être certain de tout bien comprendre. Un testeur est capable de collaborer efficacement avec ses collègues et de contribuer à un climat positif au sein de l équipe pour que le travail puisse être effectué de manière efficiente. Il contribue activement à la réalisation des résultats communs ainsi qu à la résolution des problèmes ou des conflits. Le testeur dispose aussi des compétences d analyse nécessaires. Chaque phase des spécifications des tests étant liée à une analyse de la base de test. Le testeur devra être capable d étudier les informations de manière approfondie et critique et d'estimer correctement les interrelations. Le testeur doit également être disposé à assimiler, comprendre et appliquer correctement les différentes méthodes et procédures disponibles. Le testeur doit être capable d organiser le travail qui lui a été confié de manière efficiente. Pour cela, le testeur formulera des objectifs, planifiera les activités et définira des priorités Coordinateur de test (minimum 2 coordinateurs) Activités D une part, le coordinateur de test sera responsable de l exécution des activités primaires de test (préparation des tests, spécifications des tests, exécution des tests, rapportage et suivi des résultats). D autre part, le coordinateur de test sera responsable de la coordination de l équipe de test. Cela signifie avant tout que le coordinateur de test devra prendre en charge la planification des activités de test de l équipe. Ensuite, le coordinateur de test doit également estimer les éventuels risques et, sur la base de son estimation des risques, déterminer la stratégie de

79 Cahier des charges S&L/AO/386/ /217 test. Enfin, le coordinateur de test déterminera aussi l organisation de l équipe et l infrastructure de test nécessaire. Le coordinateur de test participera également aux réunions de coordination de projet importantes pour la planification de l équipe de test. Le coordinateur de test peut faire des propositions concernant l'élaboration d'un master testplan. Le coordinateur de test veillera aussi à régulièrement faire les rapports nécessaires sur l avancement des tests ( Test Progress Report ). Profil Le coordinateur de test est capable d'identifier les opportunités et d agir ou de faire des propositions quand ces opportunités se présentent. Ce n est pas quelqu un qui attend passivement mais bien quelqu un qui entreprend lui-même des actions. De plus, le coordinateur de test devra être capable de continuer à fonctionner de manière efficace dans les situations difficiles, sous pression élevée (au niveau du temps) et face à la résistance et aux oppositions. Enfin, le coordinateur devra être capable de fixer les objectifs et les priorités de l équipe. Cela signifie que le coordinateur devra être capable d estimer correctement le temps, d'identifier les ressources adéquates et d'organiser les bonnes activités pour atteindre les objectifs fixés. Le coordinateur de test suivra l avancement du projet et le cas échéant prendra des mesures correctives. À côté de cela, le coordinateur déléguera correctement les responsabilités et les tâches aux autres, en tenant compte de leurs possibilités, de leur disponibilité et de leurs intérêts Spécialiste en outils de test (minimum 2 spécialistes en outils de test) Activités Le spécialiste en outils de test sera d une part responsable de l exécution des activités primaires de test (préparation des tests, spécifications des tests, exécution des tests, reporting et suivi des résultats) et d autre part il devra mettre ses connaissances spécialisées au service de l'équipe et servir de point de contact à ce sujet. Le spécialiste en outils de test devra aussi s investir dans l implémentation et le suivi des outils de test (HP ALM, Performance Center, UFT ). Il prendra également en charge le coaching des membres de l équipe concernant ces outils. Profil Le spécialiste en outils de test dispose des connaissances et de l expérience nécessaires pour travailler de manière indépendante sans avoir besoin en permanence d un accompagnement ou de l aide d autrui. Dans son domaine de spécialisation, le spécialiste en outils de test sera capable d'identifier les opportunités et d agir ou de faire des propositions quand ces opportunités se présentent. Il sera aussi capable de continuer à fonctionner efficacement dans les situations difficiles, sous pression élevée (au niveau du temps) ou face à la résistance et aux oppositions. Le spécialiste en outils de test est capable de donner un avis éclairé dans son domaine d expertise. Il adapte son style et ses techniques d avis tant aux personnes auxquelles il s'adresse qu'aux situations. Dans son domaine d expertise spécifique, le spécialiste en outils de test est capable de mettre en œuvre ses nouvelles idées, de proposer des solutions et de faire des propositions en matière d'amélioration des processus. Le spécialiste en outils de test entreprend (ou soutient) d'initiative des actions qui stimulent le développement professionnel des autres. Il aidera les autres et les accompagnera dans l exercice de leur fonction.

80 Cahier des charges S&L/AO/386/ / Spécialiste en méthodologie de test (minimum 2 spécialistes en méthodologie) Activités Le processus de test dans son ensemble ressortit à la responsabilité du spécialiste en méthodologie de test. Cela signifie que régulièrement (p. ex. tous les six mois ou tous les ans), le spécialiste en méthodologie de test effectuera un TPI. Les résultats de ce TPI seront convertis par le spécialiste en méthodologie de test (en concertation avec le Test Manager) en points d action concrets et repris dans un planning comportant divers jalons. Profil Le spécialiste en méthodologie de test dispose des connaissances et de l expérience nécessaires en matière de méthodologie de test pour travailler de manière indépendante sans avoir besoin en permanence d être accompagné ou aidé par quelqu un d autre. Au sein de son domaine d expertise spécifique, le spécialiste en outils de test est capable de mettre en œuvre ses nouvelles idées, de proposer des solutions et de faire des propositions en matière d'amélioration des processus. Au sein de son domaine d expertise spécifique, le spécialiste en méthodologie de test est capable de mettre en œuvre ses nouvelles idées, de proposer des solutions et de faire des propositions en matière d'amélioration des processus. Le spécialiste en méthodologie de test entreprend (ou soutient) d'initiative des actions qui stimulent le développement professionnel des autres. Il aidera les autres et les accompagnera dans l exercice de leur fonction Quality Assurance Coordinator (minimum 4 profils de Quality Assurance Coordinator) Activités Le Quality Assurance Coordinator interviendra principalement en qualité de contrôleur qualité par le biais d initiatives deep dive et la réalisation de reviews concrets pour surveiller le respect des standards ICT du SPF Finances, et plus particulièrement celui du standard FUP (aussi bien les outils que les deliverables). Concrètement, il s agit, entre autres, des activités suivantes : Documenter le review des deliverables: voir FUP et TMv4; Contrôler l utilisation correcte des outils (HP ALM, Continuous Integration, ): voir FUP et TMv4; Contrôler la qualité de la gestion et de la définition des requirements; Contrôler la qualité du code à l'aide des critères de mesure fournis (SonarQube, HP Fortify, ); Surveiller la qualité des activités de test pour le lot 5; Intervenir et communiquer de manière proactive en cas de constatation d incohérences potentielles (et risques) qui surviendraient entre les activités de développement des lots et les activités de testing du lot 5; De plus, à la demande de l adjudicataire, il émettra un avis ad hoc et formulera des instructions en matière de limitation des risques, d 'assurance qualité, de santé du projet et d'application des bonnes pratiques. Il identifiera clairement les interdépendances entre les différentes activités du projet et sera capable d en estimer l impact et les risques dans le cadre de la surveillance de la cohérence entre les activités exécutées dans le cadre du lot 5 d une part et les activités des lots d autre part.

81 Cahier des charges S&L/AO/386/ /217 Dans la pratique, le Quality Assurance Coordinator travaillera en étroite collaboration avec les membres du Comité QUAC. Cela signifie que chaque mois, il fera aux stakeholders du SPF Finances un rapport sur les éléments suivants : Un rapport high level comprenant un aperçu des principaux risques, constatations et recommandations ; Un rapport d activités détaillé sur les activités Quality Assurance complétés de rapports de review. Un planning des activités et des reviews encore à effectuer. Profil Pour pouvoir mener à bien sa mission, le Quality Assurance Coordinator doit disposer des compétences et connaissances suivantes : Développement applicatif : cette activité exige des connaissances dans le domaine des méthodologies de développement (RUP ou méthodologie similaire), des standards J2EE, des bonnes pratiques en matière de design et de qualité du code, Test du software: Cette activité exige des connaissances dans le domaine des différents o niveaux (p. ex. unit testing, system testing, ), o o types (p. ex. test de performance), et sortes (p. ex. stress testing) de tests (voir aussi la description de TMv4 en annexe). Cette activité exige également des connaissances en matière de méthodologies de test. Architecture de l information : cette activité exige des compétences dans le domaine de la transposition de modèles de domaine en modèles de base de données logiques et physiques. Infrastructure: dans le cadre du SPF Finances cela implique surtout des connaissances dans le domaine des serveurs applicatifs, des systèmes de gestion, des outils de développement, etc. Gestion de projet : o Gestion de la communication : communication transparente et obtention de l engagement de tous les acteurs du projet o Gestion des risques : sensibilisation permanente aux risques et à la maîtrise des risques o Gestion des changements Le Quality Assurance Coordinator: Crée une base de confiance avec les différents acteurs; Utilise une approche cohérente; Est capable d entrer en contact avec les bonnes personnes au bon niveau; Applique une méthode de travail très interactive.

82 Cahier des charges S&L/AO/386/ / SLA Introduction L administration souhaite conclure un Service Level Agreement (SLA) ou contrat de niveau de service pour chaque lot de ce marché. Le SPF Finances accorde une grande importance aux SLA qu il demande. Les SLA permettent en effet de surveiller les objectifs et les risques pour l organisation liés aux services demandés. Ces SLA comprennent un tableau avec les délais dans lesquels les SLA respectifs sont valables. Après l attribution du marché et jusqu à l échéance de la période d exploitation, l entrepreneur s engage à respecter les niveaux de service (service levels) et les engagements de résultats fixés par les SLA qui figurent dans ce cahier des charges. Des amendes peuvent être infligées à l adjudicataire si le SPF Finances constate que les niveaux de services et les obligations de résultats ne sont pas respectés. Les normes pour les niveaux de service seront fixées par des exigences de performances exprimées en un ou plusieurs indicateurs de performance. Ces niveaux de service décrits individuellement, éventuellement complétés par des niveaux de service supplémentaires proposés par le soumissionnaire, produiront ensemble le MASTER SLA pour chaque lot de ce cahier des charges. Vu la spécificité du marché, à savoir un plan de maintenance annuel et d éventuelles missions complémentaires sur la base de projets, l approche suivante a été choisie : le MASTER SLA est valable de manière générale ; des exigences spécifiques et d éventuelles modifications convenues, autorisées, par rapport au MASTER SLA en matière de services pour les nouveaux projets figureront dans un SLA spécifique qui sera joint au MASTER SLA sous la forme d une annexe distincte. Le MASTER SLA à proposer sera accompagné d un «Dossier Accords et Procédures» (DAP). Les normes exprimées en exigences de performance et indicateurs de performance, ainsi que les éventuelles clauses d amende afférentes, figureront dans un tableau récapitulatif des KPI (tableau des Key Performance Indicators). Comme modèle de gestion pour ces processus ICT, le SPF Finances a choisi de suivre des processus ITIL V Les SLA seront élaborés dans ce cadre. Le Service Level Management doit aligner le service ICT presté dans le cadre de ce marché sur les objectifs opérationnels en termes de qualité, quantité et coûts. Remarque générale : si le soumissionnaire soumet une offre pour plusieurs lots, il peut formuler une proposition de SLA pour les différents lots de son offre ; en cas de différences pour chaque lot, il devra cependant l indiquer clairement dans son offre. 2 Voir paragraphe Relation entre SLA et ITIL V Glossary

83 Cahier des charges S&L/AO/386/ /217 Documents à introduire obligatoirement avec l offre : 1. SQP & SIP 2. Concept MASTER SLA (conforme au modèle SLA en annexe 4) 3. DAP 4. Exemple de rapport 5. Tableau KPI rempli (conformément au tableau des KPI en format A3 en annexe 4 de ce cahier des charges) a. Pour le tableau KPI, il faut à côté de la version papier ou digital, aussi introduire une version électronique en format Excel dans l offre ; b. Seule la dernière colonne doit être remplie au cas où des amendes plus élevées sont proposées ; c. Les (valeurs des) autres colonnes ne peuvent être modifiées ; 4.2.Principe d élaboration des SLA dans le cadre de ce marché et deliverables correspondants Concept de MASTER SLA - template SLA SPFFIN En annexe 6 de ce cahier des charges figure le modèle SLA actuel du SPF Finances qui sert de point de départ à la rédaction du projet de MASTER SLA. Il s agit d un template général, générique des SLA du SPF Finances, qui doit donc être adapté en fonction du caractère spécifique du cahier des charges pour les lots 1, 2, 3 et 4. Outre les éléments standards du ou des SLA que le soumissionnaire doit présenter, les niveaux de service et les engagements de résultats que le SPF Finances demande dans le cahier des charges doivent y être notamment détaillés. Comme déjà indiqué, le soumissionnaire est libre : d ajouter des points individuels complémentaires, comme des services levels supplémentaires ou des normes de service assortis d exigences de performances et d indicateurs de performances correspondants ; de proposer d autres points pertinents dans le concept MASTER SLA. Aucune information financière ne figure dans le SLA sauf, éventuellement, une liste des clauses d amendes (voir annexe 6) Projet de «Dossier Accords et Procédures (DAP)» contenu En complément à un concept MASTER SLA, le soumissionnaire doit établir et présenter un premier projet de «Dossier Accords et Procédures (DAP)».

84 Cahier des charges S&L/AO/386/ /217 Ce document reprend les accords relatifs au mode de coopération entre le pouvoir adjudicateur et l adjudicataire. L objectif de ce document est de préserver la lisibilité du document des SLA et de faire figurer tous les éléments liés aux accords et détails dans un document DAP distinct. Un avantage supplémentaire de cette méthode est la possibilité d adapter rapidement le DAP sans qu il soit nécessaire d apporter de modification (nouvelle signature ) au document SLA original. Pour résumer, les points suivants sont traités voir l ouvrage de référence pour de plus amples détails : Accords concernant la gestion du document DAP (durée de validité, procédures de modification du DAP, dérogations incidentielles au DAP ) ; Accords concernant les processus et procédures (templates, processus de gestion, tâche de gestion pour chaque processus de gestion, une description détaillée avec flowcharts, interfaces, accords ) ; Lignes de communication (notifications d incidents, procédures d escalade, plaintes, informations de contact personnes impliquées ) ; Tâches, compétences et responsabilités (RACI, structures de concertation, composition des différentes instances compétentes ) ; Exemples de rapportage (organisation du rapportage pour chaque processus de gestion, fréquence et forme du rapportage sur les SLA, éventuellement exemples de rapports ). Pour l élaboration détaillée, veuillez consulter un ouvrage de référence 3 qui contient un template détaillé du DAP. Aucune information financière ne figure dans le DAP. Aucun modèle formel n est imposé au soumissionnaire concernant la forme de cette première version du concept de DAP. En matière de processus et de procédures, le standard en vigueur au SPF Finances est actuellement ITIL V (voir aussi paragraphe ITIL V3-2011). Il est spécifiquement demandé qu une première version des processus suivants et des procédures y afférentes soit, le cas échéant, traitée et décrite dans le concept de DAP à présenter, le cas échéant : o o ITIL Service Delivery Set (gestion tactique) Service Level Management ; Availability Management ; Capacity Management ; IT service continuity Management; Service Support Set (Gestion opérationnelle) Incident Management ; Problem Management ; Change Mangement ; Release Management ; Configuration Management ; Remarque : le service desk en fait également partie. 3 Livre : SLA Best Practices - Bart de BEST p ISBN13 :

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

86 Cahier des charges S&L/AO/386/ / Projet de tableau de KPI avec clauses d amende Un indicateur clé de performances (KPI) est une condition importante qui doit être surveillée afin de limiter les risques liés à l objectif à réaliser par le processus auquel il est associé. Les objectifs des processus permettent eux-mêmes la réalisation des objectifs de l entreprise. Le tableau récapitulatif de l annexe 4 contient à la fois les KPI et les indicateurs de performance (IP) et normes de performance correspondants. Une clause d amende figure également dans le tableau pour certaines normes IP. C est l amende qui est infligée par le SPF Finances en cas de non-respect des normes définies dans le tableau. Le soumissionnaire est libre de proposer des amendes plus élevées (critères d évaluation). Cette première version de ce projet de tableau de KPI avec clauses d amende doit obligatoirement être jointe à l offre (voir critères d évaluation). Elle doit permettre à la commission d évaluation d évaluer le projet de tableau de KPI proposé Service Level Reporting (SLR) - Rapportage sur le niveau de service Le rapportage concernant les normes IP atteintes figure dans des Service Level Reports, qui sont soumis périodiquement au SPF Finances à fins de contrôle et de réorientation. Les modèles de ces SLR sont repris dans le DAP. Le soumissionnaire joindra une proposition de modèle à son offre 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é 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é 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.

87 Cahier des charges S&L/AO/386/ /217 L entrepreneur désignera formellement un Service Level Manager qui soutiendra ce processus pendant toute la durée du projet. Le coût des tâches à exécuter sera compris dans la gestion du projet. Pour de plus amples informations, voir : Délais et moyens d élaboration des DAP, après l attribution du marché Deux mois, après l attribution du marché, le DAP global complet, élaboré en concertation et définitif (Dossier Accords et Procédures) doit être disponible. Les processus et les procédures y afférentes doivent également être au point et opérationnels. Les mesures, rapports et reviews relatifs aux SLA doivent également être opérationnels à ce moment. Le soumissionnaire prévoira dans son offre les moyens nécessaires pour établir, implémenter, exploiter et rectifier tous les documents nécessaires (MASTER SLA, DAP, tableau des KPI ) ainsi que les procédures et processus correspondants durant toute la durée de ce marché. 4.3.Encadrement SLA Relation entre SLA et ITIL V Glossary Les SLA doivent être établis sous la forme de processus. Le SPF Finances utilise le modèle de gestion ITIL V à cet effet. Comme déjà indiqué, il est demandé de tenir compte des objectifs de ces processus de gestion et du Service Level Management dans l élaboration de ces SLA. Les processus de gestion sont décrits dans le DAP. Pour de plus amples informations, voir les sites Web suivants relatifs à ITIL V3-2011: 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 : 5 Pour de plus amples explications concernant les termes utilisés dans ce cahier des charges, veuillez consulter ces ITIL Glossaries. Si le SPF Finances souhaite utiliser une autre définition, cela sera spécifiquement mentionné dans le cahier des charges, et seule cette définition sera valable Relation entre les SLA et les normes et fondements ICT du SPF Finances. Les normes et fondements ICT du SPF Finances sont publiés en ligne sur les sites Web suivants : Néerlandais 4 Since July 2013, ITIL has been owned by AXELOS Ltd, a joint venture between HM Cabinet Office and Capita Plc. Axelos licenses organisations to use the ITIL intellectual property, accredits licensed Examination Institutes, and manages updates to the framework. 5 «Copyright AXELOS Limited All rights reserved. Material is reproduced with the permission of AXELOS»

88 Cahier des charges S&L/AO/386/ /217 menten/ Français Gestion et contrôle des SLA Pour gérer les normes de service, l accent est placé sur une surveillance proactive et réactive : - Proactive par un monitoring de qualité. - Réactive par un processus de gestion des incidents Principe des Quality Gates dans les cycles de développement L adjudicateur attache une grande importance à la surveillance de la qualité pendant l exécution du marché. C est pourquoi il sera nécessaire de travailler avec des Quality Gates pendant l exécution du projet. Celles-ci ont les objectifs suivants : Garantir la qualité au début du projet, par une approche en projet qui intègre la garantie de qualité afin que les produits finaux livrés satisfassent aux standards et normes exigés. Réduire le cycle de développement en «réussissant au premier essai». Accent sur une conception de qualité des produits par une approche «Quality by Design». La notion de Quality Gates consiste à procéder aux analyses nécessaires entre les différentes phases. Nous distinguons les phases principales suivantes dans le cycle de développement de chaque itération : 1. Requirements (FUP D2) 2. Design (FUP D3) 3. Developement (FUP D4) 4. Testing (FUP D5 + TMv4, voir aussi lot 5) Nous distinguons 4 Quality Gates, avec respectivement les 4 «reviews» suivantes : 1. Requirements Review: la validation des requirements en concertation avec le business. L adjudicataire des lots 1, 2, 3 et 4 décrira l approche qu il utilisera dans la review afin d identifier et de valider les requirements. L approche doit permettre d obtenir une compréhension mutuelle optimale de chaque requirements du périmètre de l itération afin que les corrections soient réduites à un minimum dans les phases ultérieures du cycle. 2. Design Review: l adjudicataire des lots 1, 2, 3 et 4 décrira l approche qu il utilisera dans la review pour faire en sorte que la conception corresponde aux standards ICT et aux requirements identifiées. 3. Development Review: l adjudicateur attache une grande importance à une approche «Quality by Design» orientée qualité dans la rédaction du code. L adjudicataire des lots 1, 2, 3 et 4 décrira l approche qu il appliquera dans la review pour garantir que le code livré est développé selon les meilleures pratiques généralement acceptées d une part et satisfait aux exigences des standards en ICT d autre part (voir aussi l introduction du paragraphe I.1.3.2).

89 Cahier des charges S&L/AO/386/ / Test Review: l adjudicataire du lot 5 décrira l approche spécifique qu il utilisera dans la review afin de garantir la qualité des tests et leur cohérence avec les autres phases dans la méthodologie des tests discutée dans le lot 5. Le tout est résumé par l illustration suivante, qui présente la répartition en phases d une itération : L adjudicateur est conscient des différentes méthodologies de type «agile» (scrum...) qui sont habituelles dans le monde du développement de logiciels. La répartition en phases cidessus peut être appliquée dans une approche «agile» (ex. sprints). L adjudicateur ne veut absolument pas de modèle en cascade, mais préfère une approche itérative. La répartition en phases visualisée correspond donc à une itération x et non à l ensemble du projet. Le soumissionnaire qui souhaite appliquer une méthode de développement agile est invité à décrire comment il la greffera sur les standards ICT en vigueur, qui restent intégralement d application. Nous soulignons explicitement le fait que l utilisation des outils et templates décrits dans les standards ICT reste obligatoire (ex. template deliverables FUP, tools FUP ). Ils devront donc également être intégrés dans les approches des reviews demandées dans ce paragraphe.

90 Cahier des charges S&L/AO/386/ / Environnements à supporter dans le cadre de ces SLA Les environnements dans lequel les SLA demandés peuvent être valables figurent cidessous. Ces environnements sont désignés par une lettre ou une abréviation. Dans le tableau des KPI, on a décrit pour chaque KPI l environnement pour lequel il est valable. D : développement À : acceptation T : test P : production 4.4.Service Levels et engagements de résultats correspondants dans le cadre de ce marché Le SPF Finances souhaite définir 7 niveaux de service, adaptés aux différentes phases : 1. Service Levels relatifs à la gestion de projet : 2. Services Levels relatifs à la phase de développement ; 3. Service Levels relatifs à la mise en production ; 4. Services Levels relatifs aux exigences non fonctionnelles ; 5. Service Levels en matière de traitement d incidents, d interventions correctrices et réactives ; 6. Service Levels concernant les services du personnel mis à disposition par l entrepreneur ; 7. Service Levels relatifs au lot 5 Testing. Ces 7 SLA et engagements de résultat sont décrits dans les sections suivantes.

91 Cahier des charges S&L/AO/386/ / Service Levels relatifs à la gestion de projet : délai, exhaustivité et planification PI-Project-bid-delivery-period Objectifs Définition Livrer l offre avec le plan du projet dans le délai fixé par le SPF Finances. Méthode de mesure Formule de calcul Période de calcul Résultat à atteindre Contrôle par comparaison de la date de demande et de la date d'introduction de l offre. Date d introduction de l'offre (ou date d'accusé de réception du SPF Finances) date de demande officielle du SPF Finances. Le calcul se fait trimestriellement et est rapporté en fonction du nombre de demandes qui débutent à partir du 1 er jour ouvrable du 1 er mois jusqu au dernier jour ouvrable du 3 e mois. En fonction de ces chiffres, des actions correctrices sont mises en œuvre si nécessaire. 90% des demandes à fournir doivent être effectuées dans les 10 jours ouvrables PI-Bid-Completeness Composition minimale du lot Liste non limitative : à préciser après adjudication du marché en concertation avec l entrepreneur. Plan du projet avec phases, milestones Estimations des ressources, délais Deliverables à receptioner Services à receptioner Proposition financière Analyse des risques Analyse d impact Le contenu sera précisé en concertation avec l entrepreneur après attribution du marché Description Définition Méthode de mesure Formule de calcul Période de calcul Résultat à atteindre Objectifs Un contrôle de l exhaustivité de l offre sur la base de la composition minimale décrite dans le paragraphe ci-dessus. Vérification par le demandeur après du SPF FIN Tous les éléments sont repris. Nombre d offres complètes, une offre est incomplète si plus d un des éléments convenus de l offre manque ou est incomplet (cf. composition minimale de l offre dans le cahier des charges). Le calcul se fait trimestriellement et est rapporté chaque trimestre en fonction du nombre de demandes, à partir du 1 er jour ouvrable du 1 er mois jusqu au dernier jour ouvrable du 3 e mois. Si nécessaire, des actions correctrices sont mises en place, en fonction de ces chiffres. 90% des offres doivent être complètes sur base trimestrielle. Sur cette base, le SPF FIN a le droit de refuser l offre de l entrepreneur ou de demander des

92 Cahier des charges S&L/AO/386/ /217 informations complémentaires PI-Project Plan-Planning Définition Méthode de mesure Formule de calcul Période de calcul Résultat à atteindre Objectifs 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. Comparer manuellement les dates conformément au planning (par le biais d un éventuel graphique de Gantt du projet) Date de réception date de demande Sur base annuelle, le statut des retards de tous les projets en cours est établi. Par principe, sur la base du graphique de Gantt du projet qui est revu chaque mois par le chef de projet. L évaluation définitive se fait annuellement. 90% des projets attribués à un entrepreneur durant l année en cours peuvent avoir un retard max. de 10 jours ouvrables. 4.6.Niveaux de service phase de développement : conformité à la méthodologie FUP, aux standards ICT et qualité du code L entrepreneur doit se conformer aux deliverables et au cycle de vie (phases, itérations, relations temporelles avec les deliverables ), ainsi qu aux outils standard utilisés au sein du SPF Finances. Cela inclut les points suivants : la réalisation des deliverables FUP conformément à la méthodologie FUP et compte tenu de la qualité livrée ; l utilisation correcte des outils prescrits par la méthodologie FUP. l utilisation correcte des standards définis dans les standards ICT 6 Afin de contrôler et de garantir la qualité du code et de la solution livrée, les principes et critères 7 suivants seront utilisés : La conformité à la méthodologie FUP, en particulier les artefacts de la discipline D4 dont font notamment partie le plan de qualité du code et le rapport de qualité du code. L intégration dans la FUP-ITIL «continuous integration tool chain» (Starteam, Maven, Jenkins, SonarQube, HP Fortify ). Un indicateur de performance sera repris sous le SLA mis en production. 6 Architecture Builing Blocks, voir aussi paragraphe Relation entre SLA et standards et fondements ICT du SPF Finances 7 Vu la durée du contrat-cadre, ces principes et critères pourront être adaptés aux nouvelles évolutions et découvertes technologiques.

93 Cahier des charges S&L/AO/386/ /217 Un contrôle de la qualité du code sera réalisé au moyen de l outil SonarQube (voir aussi Le pouvoir adjudicateur attache une importance particulière : o à un unit test coverage élevé : min. 80% ; o à un degré suffisamment élevé de documentation du code : documentation conforme au public API ; o au Rules Compliance Index (RCI) calculé sur la base des règles du SPF FIN: min 90% ; pas de blocking issues; pas de critical issues; o à la limitation à un minimum du nombre de lignes de code dupliquées : max. 10%. Un contrôle de sécurité et d intégrité du code sera réalisé au niveau des applications web à l aide de l outil HP Fortify. Cet outil partage le nombre de problèmes de sécurité potentiels en 4 catégories : critical, high, medium et low. La condition de base pour l acceptation de la solution est qu il ne peut y avoir aucun problème dans la catégorie critical. Les normes et critères de qualité seront précisés après attribution du marché en concertation avec l entrepreneur. Si nécessaire, et d après les contrôles qualité réalisés, l adjudicataire s engage à apporter les améliorations nécessaires à son code afin de respecter les normes de qualité et les délais des phases établis dans le présent cahier des charges. Le SPF Finances se réserve le droit d utiliser d autres outils afin de vérifier la qualité du code PI-FUP-deliverables Définition Objectifs 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 Formule de calcul Période de calcul Résultat à atteindre La date à laquelle la version finale des deliverables FUP sera reçue au repository central (Starteam). Date à laquelle la version finale est disponible dans le repository central la date prévue dans le planning du projet. Selon le planning du projet Max. 10 jours ouvrables de retard sur la date de livraison PI-FUP-tools & ICT- standards Objectifs Définition Les outils FUP et les standards ICT doivent être respectés en permanence. Méthode de mesure Formule de calcul Contrôle qualité par le SPF FIN ou une partie tierce à la demande du SPF FIN. Le nombre de jours ouvrables entre la date à laquelle les non-conformités ont été communiquées et la date à laquelle l adjudicataire communique formellement qu elles ont été résolues.

94 Cahier des charges S&L/AO/386/ /217 Période de calcul Résultat à atteindre Trimestrielle Les non-conformités constatées doivent être résolues dans un délai de max. 10 jours ouvrables PI-Quality-of-Code Définition Objectifs 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 Formule de calcul Période de calcul Résultat à atteindre Date de livraison de la version figurant dans Delivery Management Nombre de versions qui satisfont aux critères/nombre total de versions Trimestrielle Si une ou plusieurs normes de qualité du plan qualité n ont pas été respectées après la livraison d une version donnée, cela devra être corrigé dans un délai de max. 10 jours ouvrables, par livraison d une nouvelle version qui respecte les normes de qualité fixées PI-Security-Integrity-Code Définition Objectifs C est la durée avant qu une contre-mesure à une fuite de sécurité soit prise après que la fuite a été formellement constatée par le SPF Finances ou une partie tierce. Méthode de mesure Période de calcul - SAST (Static Application Security Testing) - DAST (Dynamic Application Security Testing) Trimestrielle 4.7.Service levels mise en production Les procédures strictes appliquées par le SPF Finances doivent être respectées pour la mise en production de nouvelles versions/nouveaux patches/bugfixes. Ce, afin de ne pas perturber l opérationnalité de l environnement opérationnel existant. Les outils et méthodologies prévus et décrits dans les standards ICT seront utilisés PI-Continuous-Integration-Tool-Chain 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 Formule de calcul Période de calcul Résultat à atteindre Les informations figurant dans les outils de la Continuous-Integration Tool Chain (Jenkins, Delivery Management ). Nombre de versions /patches/bugfixes qui ont été livrés sans utilisation correcte de la Continuous Integration Tool Chain. Trimestrielle Aucune version ne peut être livrée sans utilisation correcte de la Continuous Integration Tool Chain.

95 Cahier des charges S&L/AO/386/ / PI-Releases-in-production Définition Objectifs La première version proposée pour la mise en production doit être exacte et exhaustive par rapport aux exigences définies. Méthode de mesure La gestion des incidents et l outil standard utilisé pour les demandes d installation des versions Formule de calcul Nombre de versions retirées de la production parce que inexactes, incomplètes ou douteuses / Nombre total de versions Période de calcul Trimestrielle Résultat à atteindre Max. 10% 4.8.Service levels exigences non fonctionnelles PI Availibility-7x24x365 et PI-Availibility-5x12 Le SPF Finances considère les indicateurs de performances «disponibilité des applications» comme très importants en vue de garantir un service de qualité pour l organisation interne et les citoyens. Le principe est que les applications sont réparties en plusieurs catégories de disponibilité. La différence entre catégories réside dans les service windows ou périodes d ouverture et dans les pourcentages de disponibilité prévus et souhaités. On indiquera également l environnement pour lequel la disponibilité IP est valable Périodes d ouverture du service (service window) et périodes de maintenance dans le cadre de ces SLA Les périodes d ouverture d un service sont les périodes pendant lesquelles le service est disponible pour son utilisateur. La période de maintenance est la période où les services ne sont pas fournis, par exemple parce que des travaux de maintenance doivent être effectués sur les applications ou l infrastructure Service Windows par catégorie d applications Le SPF Finances prévoit actuellement deux catégories d applications pour lesquelles des indicateurs de performance de disponibilité sont prévus. Application Service window: 7x24x365 Service window: 5x12 Lot 1 (Développement et support) : Domaine TVA Intervat x STIR-TVA x Stiron TVA (sauf VIES) x Stiron TVA VIES x MOSS (Mini One Stop Shop) X Lot 2 (Développement et support) : Domaine impôts directs personnes physiques (IPP + INR PP) Belcotax-on-Web (BOW) x Tax-On-Web (TOW) x

96 Cahier des charges S&L/AO/386/ /217 Taxi Proposition de Déclaration Simplifiée (PDS) Calculatrix IPP Lot 3 (Développement et support) : Domaine impôts directs personnes morales + recherches, précompte et contrôle Biztax : Module Font-Office (FO) Biztax: Modules Back-Office (BO) et Dossier Unique (DU) Stir-Contrôle Stir-Recherche PRM-on-web Calculatrix ISOC FINELTS Lot 4 (Développement et support) : Domaine transnational STIRint FATCA Aut_DT x x x x X x x x x x x x X Service window 7x24x365 Les applications sont disponibles 24 heures sur 24, 7 jours sur 7, tous les jours de l année, à l exception des week-ends de maintenance trimestriels prévus et des périodes d intervention convenues à l avance et confirmées par le SPF Finances. Toutes les autres indisponibilités de l application, par exemple en raison d incidents, seront traités comme tels si elles relèvent de la compétence de l adjudicataire. En fonction de la nature de l incident, le SPF Finances peut décider d effectuer des interventions dans la service window afin de rétablir le service au profit des utilisateurs finaux. Des techniques de back-up en ligne seront utilisées pour ces applications. Service window 5x12 Les applications sont disponibles les jours ouvrables officiels du SPF Finances, de 07h00 à 19h00, cinq jours sur sept, du lundi au vendredi, à l exception des jours fériés et des jours de pont officiels du SPF Finances. Des interventions peuvent avoir lieu pendant le week-end de maintenance trimestriel prévu et les périodes d intervention convenues mutuellement à l avance et confirmées par le SPF Finances en dehors de la service window fixée. Les indisponibilités des applications, par exemple en raison d incidents, seront traitées comme telles si elles relèvent de la compétence de l adjudicataire. En fonction de la nature de l incident, le SPF Finances peut décider d effectuer des interventions dans la service window pour rétablir le service au profit des utilisateurs finaux (voir aussi paragraphe Traitement des incidents, actions correctrices et réactives).

97 Cahier des charges S&L/AO/386/ / Normes PI Availibility-7x24x365 et PI-Availibility-5x12 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. Méthode de mesure Période de calcul Actuellement, le SPF Finances prévoit 4 week-ends de maintenance par an, 1 par trimestre ; pendant cette période, des travaux importants peuvent être effectués et les citoyens ne peuvent pas accéder aux applications e-gov Les indisponibilités qui ne sont pas dues à l entrepreneur (après examen et concertation) ne sont pas prises en considération. Un mois de 30 jours comprend minutes et correspond à 100% de disponibilité pour la service window 7x24x365. La disponibilité peut être calculée de la même manière pour le nombre de minutes de disponibilité dans la service window 5x12. Tout comme les années bissextiles, on tient compte des mois qui comptent 30 et 31 jours respectivement. La disponibilité est mesurée en effectuant une simulation toutes les 10min qui contrôle les fonctionnalités précitées. La disponibilité est calculée et rapportée tous les 6 mois. Des actions correctrices sont mises en place en fonction de ces chiffres. L évaluation définitive se fait annuellement. Résultat à atteindre PI Availibility-7x24x365 PI-Availibility-5x12 99,50% de disponibilité trimestrielle pour chaque application (version) en production de l adjudicataire. 99,50% de disponibilité trimestrielle pour chaque application (version) en production de l adjudicataire Clauses d amende PI Availability La disponibilité et les clauses d amende correspondantes s appliquent à toutes les applications individuelles que l adjudicataire a en production. Les amendes sont donc calculées par disponibilité d une application individuelle PI-Performance La performance doit être déterminée par catégorie d applications ou par exception pour une application individuelle. Les accords en matière de PI-Performance seront déterminés individuellement après attribution du marché et exécution des tests de performances. Actuellement, aucune amende n y est associée. La PI-Performance proposée actuellement est décrite ci-dessous. En fonction des applications, d autres aspects de performances seront ajoutés si cela s avère nécessaire au terme des tests de performances. Objectifs Définition 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 Formule de calcul Période de calcul 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. 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). 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.

98 Cahier des charges S&L/AO/386/ /217 Résultat à atteindre L évaluation définitive se fait annuellement. P. ex. X % < Y secondes Normes à définir en concertation après exécution des tests de performance individuels requis après l attribution du marché.

99 Cahier des charges S&L/AO/386/ / 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 «niveaux de priorité pour les actions correctrices et réactives»). La disponibilité du help desk et la réactivité de l entrepreneur seront : fournir une assistance technique les jours ouvrables du SPF Finances entre 7h00 et 19h00 pour les applications Service Window 7x24x365 et les applications Service Window-5x12. En dehors de ces heures, l adjudicataire organisera un help desk de deuxième ligne pour la Service window 7x24x365 pour les applications e-gov. À partir du moment où les demandes sont attribuées à l équipe de support du soumissionnaire, le SPF FIN exige une acceptation formelle de la demande dans les délais convenus (Incident Response Time). Ces délais sont fixés en fonction de la priorité de la demande. Un délai de résolution maximal est également défini par niveau de priorité (Incident Resolution Time). Pour chaque incident constaté, quelle qu en soit la nature, le SPF Finances complétera une fiche d incident et la remettra à l entrepreneur. Cette fiche permettra de suivre la résolution de l'incident et sera à la base du contrôle de la qualité des prestations fournies. Cette fiche sera codée dans un système de suivi des incidents qui est à la disposition l entrepreneur. Sur cette fiche, l entrepreneur doit compléter tous les éléments requis par rapport à la résolution de l'incident, conformément au SLA qu il a signé dans le cadre de son offre Priorités des incidents Priorités des incidents pour les interventions correctrices et réactives Description et critères Priorité 1 Major incident Impact important sur le processus de travail. Service indisponible pour l ensemble des utilisateurs. Service bloqué ou défectueux pour l ensemble des utilisateurs, baisse importante de la performance entraînant l impossibilité d'utiliser le service. Aucune alternative utilisable n est disponible. Priorité 2 High Priority Incident bloquant ou grave Les incidents qui ont un impact sensible sur une partie du service. Aucune alternative utilisable n est disponible. Priorité 3 Medium Priority Incident superficiel sans impact sur les fonctions opérationnelles du service. Le service ne fonctionne pas comme il devrait, mais est disponible avec un impact minimal ou grâce à une alternative utilisable. Tous les incidents business qui ne sont ni P1, ni P2 et pas single user. Priorité 4 Normal Priority Minor incident ou service request, impact single business user.

100 Cahier des charges S&L/AO/386/ /217 Pas d impact business ou problème fonctionnel minime. Toutes les requests ou les tickets de plainte du business. Remarque : Les incidents peuvent être notifiés manuellement via le help desk du SPF Finances ou automatiquement par le système de monitoring du SPF FIN Matrice de priorités Matrice d urgence / d impact pour les décisions autour de la priorité d incidents en cas de doute : Impact Urgency Low Average High Critical Low Risk Moderate Risk High Risk Very High Risk Définitions d impact sur le business : Very High Risk Impact sur un département complet ou un délai de livraison/service critique ou impact important sur le business sans solution d'urgence réalisable pour le business High Risk Impact sur un grand groupe d utilisateurs ou impact moyen sur le business sans solution d urgence réalisable pour le business Moderate Risk Impact sur un groupe spécifique ou sur plusieurs utilisateurs, ou faible impact sur le business Low Risk Impact sur un seul utilisateur Définitions d Urgency Critical Incident grave qui doit être traité en priorité, en situation de gestion de crise High Incident très urgent qui doit être traité au plus vite Average Incident urgent qui doit être traité rapidement Low Incident sans urgence

101 Cahier des charges S&L/AO/386/ / PI-Incident-Response-Time Délai d acceptation des tickets de help desk selon le niveau de priorités (Incident Response Time KPI). Retour Incidents ou Incident-Response-time. Définition Objectifs 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 Formule de calcul Période de calcul Résultat à atteindre Via l outil help desk SPF Finances Moment de notification de l incident par le SPF FIN moment d acception du ticket par le groupe de support de l entrepreneur trimestrielle Priorité % dans 15min après attribution de l incident au groupe de support de l entrepreneur Priorité % dans 30min après attribution de l incident au groupe de support de l entrepreneur Priorité % dans 30min après attribution de l incident au groupe de support de l entrepreneur Priorité dans 30min après attribution de l incident au groupe de support de l entrepreneur 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) Définition Objectifs 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 Formule de calcul Par l outil de help desk du SPF Finances et le système de traitement d incidents de l entrepreneur Moment d enregistrement incident resolved 8 dans l outil de help desk du SPF Finances moment d attribution au groupe de support Période de calcul Résultat à atteindre trimestrielle Niveau de priorité Délai de résolution (Incident Resolution Time) % dans 4 heures après attribution de l incident au groupe de support de l entrepreneur 8 Si le SPF Finances constate qu une solution x proposée ne résout rien dans la pratique, le moment de proposition de la solution x n est pas considéré lors du calcul de ce KPI.

102 Cahier des charges S&L/AO/386/ / % dans les 24 heures et 100 % dans les 48 heures après attribution de l incident au groupe de support de l entrepreneur 3 80 % dans les 2 jours ouvrables et 100 % dans les 4 jours ouvrables après attribution de l incident au groupe de support de l entrepreneur 4 100% dans 5 jours ouvrables après attribution de l incident au groupe de support de l entrepreneur Retour des incidents : o Toutes les 2 heures de travail pour les incidents de priorité 1 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é Service Levels concernant les services du personnel mis à disposition par l entrepreneur PI-BID-Reactiveness Objectifs Définition Délai de réponse de la société après réception du bon de commande pour fournir le personnel Méthode de mesure Formule de calcul Période de calcul Résultat à atteindre Manuel Nombre de jours ouvrables entre la réception du bon de commande et la réponse de la société Début du projet Max. 10 jours ouvrables PI-Staff-Timesheet Définition Méthode de mesure Formule de calcul Période de calcul Résultat à atteindre Objectifs Fournir des timesheets avec les prestations individuelles du personnel qui travaille sur le projet sur base mensuelle. Remise officielle du timesheet en deux exemplaires, signés par le représentant de l entrepreneur et celui du SPF Finances Date de remise 1 er jour ouvrable du mois Trimestrielle 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 entrepreneur. 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

103 Cahier des charges S&L/AO/386/ /217 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 Service Levels concernant le lot 5 testing Aperçu Les KPI pour le lot 5 «Testing» sont répartis en trois catégories : Test project Test quality Test process performance Les KPI de la catégorie «Test project» sont : PI-Test execution ratio PI-Actualized-testing-effort- burn- down-rate (mananagement KPI only for reporting) Les KPI de la catégorie «Test Quality» sont : PI-Test execution coverage PI-Test build coverage PI-Defect detection ratio Les KPI de la catégorie «Test process performance» sont : PI-Test-efficiency PI-Test-case-automation KPI Test project PI-Test-execution-ratio Objectifs Définition Avancée de la phase d exécution du test en termes de test cases exécutés. Méthode de mesure Formule de calcul Période de calcul Test case en HP ALM Nombre de test cases exécutés/nombre de test cases préparés En fonction de la période de test Résultat à atteindre Au moins 90 % à la fin du projet

104 Cahier des charges S&L/AO/386/ / PI-Actualized-testing-effort- burn- down-rate (management KPI) Définition Objectifs Tous les efforts déployés par rapport à l effort nécessaire actualisé Méthode de mesure Formule de calcul Période de calcul Activités dans Sharepoint Efforts de test actuels/efforts de test estimés jusqu à achèvement En fonction de la période de test Résultat à atteindre Max. 100% par projet KPI s Test Quality PI-Test-execution-coverage Définition Objectifs Exigences (requirements) associées aux test cases exécutés Méthode de mesure Formule de calcul Période de calcul Dans HP ALM Nombre d exigences (requirements) testées / nombre d exigences (requirements) En fonction de la période de test Résultat à atteindre Au moins 90 % à la fin du projet de test PI-Test-build-coverage Objectifs Définition Exigences (requirements) qui ont été couvertes par les test cases par projet Méthode de mesure Formule de calcul Période de calcul Dans HP ALM Nombre d exigences (requirements) couvertes / nombre d exigences (requirements) En fonction de la période de test Résultat à atteindre Min. 90% PI-Defect-detection-ratio Définition Objectifs Défauts manqués durant l exécution du test qui passent dans la production. Mesurées par projets Méthode de mesure Formule de calcul Période de calcul Résultat à atteindre HPALM + HP Service manager Nombre de manquements / (nombre de manquement + nombre de manquements post-release) Cycle de release du projet Min. 90% par projet

105 Cahier des charges S&L/AO/386/ / KPI testing process performance PI-Test-efficiency Objectifs Définition Performance effective vs performance attendue pour l exécution des test cases Méthode de mesure Formule de calcul Période de calcul Sharepoint (test plan + activités) Efforts attendus pour l exécution des tests/efforts actuels pour l exécution des tests En fonction de la période de test Résultat à atteindre Min. 90% PI-Test-case-automation Objectifs Définition Pourcentage de test cases automatisés/ nombre de test cases préparés Méthode de mesure Formule de calcul Période de calcul Dans HP ALM Nombre de test cases automatisés/ nombre de test cases préparés En fonction de la période de test Résultat à atteindre Le minimum doit être défini dans chaque offre ou chaque année 4.12.Périodes d application des différents SLA Service Levels Période de validité Environnements 1. Service Levels concernant la gestion de projets 2. Services Levels phase de développement Dès l attribution De l attribution à la mise en production D-A-T-P D-A-T-P 3. Service Levels mise en production De la mise en production à la fin de la mise en production 4. Service Levels exigences non A partir de la mise en fonctionnelles 5. Service Levels concernant le traitement d incidents, les interventions correctrices et réactives production A partir de la mise en production D-A-T-P 6. Service Levels concernant les Dès l attribution D-A-T-P P P

106 Cahier des charges S&L/AO/386/ /217 services du personnel mis à disposition par l entrepreneur 7. Service Levels concernant le lot 5 testing. Dès l attribution T 4.13.Sanctions Le non-respect d un élément déterminé du SLA est sanctionné d une amende. Le SPF Finances n a nullement l intention de comprimer les frais par le biais d amendes, mais d encourager l adjudicataire à respecter toutes les conventions afin de toujours garantir la prestation de services Principe des propositions d amendes Le SPF Finances impose des amendes standard pour la majorité des service levels. Le soumissionnaire peut proposer des amendes supérieures. Toutes les amendes proposées doivent être reprises dans le tableau de KPI. Ce montant de base pour le calcul des amendes reste d application durant toute la durée du contrat, sauf si un montant supérieur a été proposé par le soumissionnaire : dans ce dernier cas, le montant supérieur est d'application. Les amendes proposées sont un critère d évaluation Tableau des clauses de pénalité Les clauses de pénalité préétablies sont reprises dans le tableau récapitulatif des KPI à l'annexe 4 où sont également indiqués les Indicateurs de performance SLA monitoring, rapportage et analyse, Concertation du Service Management SLA-monitoring 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.

107 Cahier des charges S&L/AO/386/ /217 Pour plus d informations sur cette simulation d utilisateur final, nous vous renvoyons aux Fondements ICT publiés sur l internet, à savoir : Néerlandais : menten/ Français : plus précisément le chapitre ABB End-to-End Monitoring et mesures service level Assistance dans le cadre du monitoring par l adjudicataire Dans le cadre du présent marché, la société collaborera à l établissement et à la validation d un scénario de base et aidera à élaborer les éventuelles adaptations occasionnelles, si une version adaptée /mise à jour d'une application est déployée. Le coût de l'assistance pour établir ce monitoring de base et des éventuelles adaptations dans le courant du projet est compris dans le prix de la maintenance annuelle et des projets supplémentaires. Les résultats du monitoring seront utilisés pour le rapportage SLA et peuvent être mis à disposition de l entrepreneur pour les traiter dans le rapportage SLA à fournir chaque mois. Le SPF Finances fournira à l adjudicataire les données liées au monitoring pour le 10 e jour ouvrable du mois prochain. Si des manquements sont constatés, le monitoring lancera la procédure de règlement des incidents avec l'enregistrement nécessaire. L entrepreneur se déclarera d accord avec cette méthode de travail pour mesurer la disponibilité. Avec l équipe de monitoring, l entrepreneur conclura les accords requis lors du lancement du projet. En cas de doute, il peut faire effectuer à sa charge un audit du système de monitoring des Finances pour vérifier la fiabilité des mesures, et ce pour la partie qui lui importe Rapportage SLA, Reviews, IP-SLR Rapportage Service Level (SLR) général Ce rapportage service level (SLR) a trait aux activités sous-traitées à l entrepreneur par le SPF Finances et qui ont trait aux services dans le cadre du présent cahier spécial des charges. Le point de départ est qu il faut faire rapport e.a. sur les indicateurs de service mesurables repris dans le SLA. La mesure et le rapportage ont lieu chaque mois ou trimestre : 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. L entrepreneur fournit le rapportage au plus tard 15 jours ouvrables après la fin de la période. Lors d un stade ultérieur, il se peut que certains rapportages n'aient pas de valeur ajoutée ou que seules les exceptions doivent être reprises pour certains indicateurs de service. Ceci

108 Cahier des charges S&L/AO/386/ /217 peut mener à une correction de cette structure de rapportage. Les changements dans les service levels mêmes peuvent également entraîner l adaptation de la structure de rapportage. Le soumissionnaire formulera une proposition de rapports trimestriels (SLR) sous la forme d un document exploitable qui indique les niveaux de SLA atteints. Si des incidents de priorité 1 et 2 ou des «SLA breaches» importantes se produisent, l entrepreneur établira un rapport SLR intermédiaire avec les éléments clés devant permettre de suivre les projets et de les présenter aux services concernés du SPF Finances (Reviews). Si nécessaire, une réunion SLA mensuelle est organisée «by exception». Tous les trois mois, une réunion SLA au sein du SPF Finances est organisée sur place, où le Service Level Report trimestriel est abordé. Ensuite, les résultats sont soumis au groupe de pilotage. Un exemple de rapport SLR possible sera joint à l offre de sorte que la commission d'évaluation puisse l'évaluer (sous-critère). Le rapportage SLR utilisera un maximum de tableaux récapitulatifs et de représentations graphiques. Le document SLR présenté contiendra au moins les sujets suivants (liste non limitative) : 1. Résultats service level du SLA par rapport aux normes définies (KPI) avec une explication des éventuelles «SLA breaches» (non-réalisation des normes) ; (mensuel et de manière cumulative sur toute l année) 2. Proposition de SIP pour éviter les «SLA breaches» à l avenir ; 3. Statistiques de performance et de disponibilité ; 4. Statut des composants de la solution (si d application) ; 5. Soumission d une analyse des tendances au groupe de pilotage sur la base des résultats des trimestres passés ; 6. Aspects liés à la sécurité (correctifs, scanning, journaux, auditing ) ; 7. Rapports d incidents (détails sur les incidents par catégorie, Incident Response et Resolution Time ) ; 8. Request For Changes pendant la période de référence ; 9. Analyse des incidents en ce qui concerne la gestion des problèmes (recommandation sur la base d une analyse de la cause principale) ; 10. Tableau de bord récapitulatif avec rapportage du statut de projet pour le management, qui sera soumis aux groupes de pilotage trimestriels ; 11. Propositions d adaptation SLA à soumettre au groupe de pilotage PI-SLR Définition Objectifs Fournir les Service Level Reports à temps Méthode de mesure Formule de calcul Période de calcul Résultat à atteindre Date d si par , date de signature de réception par personne mandatée par le SPF Finances Date de réception 1 er jour ouvrable de la période écoulée de rapportage 3 mois / ad hoc (by exception) Réception au plus tard le 15 e jour ouvrable après la période de rapportage écoulée Concertation Service Management Cette concertation a lieu comme indiqué dans la matrice ci-dessous :

109 Cahier des charges S&L/AO/386/ /217 Nom Fréquence Personnes présentes Sujets Concertation de direction Concertation de Service Level Concertation de marché Concertation sur le fond (non formalisée) 1 * par an Délégation ICT Management SPF FIN Délégation Management entrepreneur Quality Management SPF FIN Service Management entrepreneur 1 * par trimestre 1 * par semaine Quality Management SPF FIN Service Management entrepreneur Management de marché SPF FIN Management de marché entrepreneur Ad hoc Incident management Gestion quotidienne Monitoring contrat et collaboration Développements Escalade pour la Concertation de Service Level Monitoring SLA Développements, améliorations Escalade pour la concertation de marché Intake nouveaux marchés Priorités Plaintes et améliorations Escalade pour Concertation sur le fond 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 Autres Service Levels, obligations de résultats et conclusion Le soumissionnaire peut également proposer un service level avec engagements de résultats pour d autres aspects qu il juge pertinents dans le cadre du présent cahier spécial des charges. Dans son offre, le soumissionnaire doit dès lors déterminer le niveau de service qui doit être atteint, outre les outils et les périodes de mesure, ainsi que la méthode de rapportage. Le SPF Finances peut, s il le souhaite, faire contrôler et exécuter les mesures du SLA, à ses frais, par un bureau d études indépendant. Cela ne dégage pas le soumissionnaire de sa responsabilité concernant le suivi et le contrôle des SLA.

110 Cahier des charges S&L/AO/386/ /217 IMPORTANT Cet appel d offres ne peut en aucun cas être considéré comme un engagement de la part du SPF FINANCES qui se réserve le droit de ne pas attribuer le marché BRUXELLES, Johan VAN OVERTVELDT Ministre des Finances

111 Cahier des charges S&L/AO/386/ /217 ANNEXES 1. Formulaire d offre 2. Modèle de référence 3. Curriculum vitae (annexes 3.a. et 3.b.) 4. SLA à compléter 5. Description des applications 6. SLA Template

112 Cahier des charges S&L/AO/386/ /217 La firme: SERVICE PUBLIC FEDERAL Finances Service d Encadrement Logistique Division Achats North Galaxy Tour B4 bte 961 Boulevard du Roi Albert II, BRUXELLES ANNEXE 1 : FORMULAIRE D offre CAHIER SPECIAL DES CHARGES N : S&L/AO/386/2014 Appel d offres ouvert pour la Maintenance des applications de L Administration Générale de la Fiscalité (SPF Finances). dont l adresse est: immatriculée à la Banque Carrefour des Entreprises sous le numéro: (dénomination complète) (rue) (code postal et commune) (pays) et pour laquelle Monsieur/Madame 9 (nom) (fonction) domicilié(e) à l adresse: (rue) (code postal et commune) (pays) agissant comme soumissionnaire ou fondé de pouvoirs et signant ci-dessous, s engage à exécuter, conformément aux conditions et dispositions du cahier spécial des charges n : S&L/AO/386/2014, les services définis aux prix forfaitaires unitaires mentionnés ci-après, indiqué en lettres et en chiffres, libellés en EURO, hors TVA et TVA comprise, de : 9 Biffer la mention inutile

113 Cahier des charges S&L/AO/386/ /217 Lot 1 PROFIL Task Manager Prix unitaire hors TVA / PAR JOUR-HOMME en Euro (en chiffres et en lettres) Prix unitaire TVA comprise- PAR JOUR- HOMME en Euro (en chiffres et en lettres) Lead Technical Architect / Methodologist Analyste Business / Métier expert Designer / Data architect expert Développeur senior Lot 2 PROFIL Task Manager Prix unitaire hors TVA / PAR JOUR-HOMME en Euro (en chiffres et en lettres) Prix unitaire TVA comprise- PAR JOUR- HOMME en Euro (en chiffres et en lettres) Lead Technical Architect / Methodologist Analyste Business / Métier expert Designer / Data architect expert Développeur senior

114 Cahier des charges S&L/AO/386/ /217 Lot 3 PROFIL Task Manager Prix unitaire hors TVA / PAR JOUR-HOMME en Euro (en chiffres et en lettres) Prix unitaire TVA comprise- PAR JOUR- HOMME en Euro (en chiffres et en lettres) Lead Technical Architect / Methodologist Analyste Business / Métier expert Designer / Data architect expert Développeur senior Lot 4 PROFIL Task Manager Prix unitaire hors TVA / PAR JOUR-HOMME en Euro (en chiffres et en lettres) Prix unitaire TVA comprise- PAR JOUR- HOMME en Euro (en chiffres et en lettres) Lead Technical Architect / Methodologist Analyste Business / Métier expert Designer / Data architect expert Développeur senior

115 Cahier des charges S&L/AO/386/ /217 Lot 5 Testeur PROFIL Prix unitaire hors TVA / PAR JOUR-HOMME en Euro (en chiffres et en lettres) Prix unitaire TVA comprise- PAR JOUR- HOMME en Euro (en chiffres et en lettres) Coordinateur de test Spécialiste en test tools Spécialiste en méthodologie de test Quality Assurance Coordinator Lot(s) pour le(s)quel(s) le soumissionnaire remet offre : LOTS SOUMISSION (OUI/NON)* Lot 1 : Développement/support opérationnel des applications de l'administration Générale de la Fiscalité - Domaine TVA Lot 2 : Développement/support opérationnel des applications de l'administration Générale de la Fiscalité - Domaine Impôts des Personnes Physiques Lot 3 : Développement/support opérationnel des applications de l'administration Générale de la Fiscalité - Domaine Impôts des Personnes Morales (Impôt des Sociétés, Impôt des Personnes morales et Impôt des Sociétés non résidentes) et domaine transversal Lot 4 : Développement/support opérationnel des applications Transnationales Lot 5 : Test des applications de l administration générale de la fiscalité

116 Cahier des charges S&L/AO/386/ /217 J autorise l administration à prendre toutes les informations utiles tant de nature financière que morale sur moi-même, auprès d'autres instances ou organismes. La présente inscription comprend l engagement de faire parvenir à l administration sur simple demande et dans les meilleurs délais les documents et certificats dont elle exigerait la présentation en application du cahier spécial des charges ou en application de la réglementation relative à la conclusion de contrats pour le compte de l Etat. En cas d approbation de la présente offre, le cautionnement sera constitué dans les conditions et délais prescrits dans le cahier spécial des charges. L information confidentielle et/ou l information qui se rapporte à des secrets techniques ou commerciaux est clairement indiquée dans l offre. Les sommes dues seront payées par l organisme de paiement du pouvoir adjudicateur par virement ou versement sur le compte n : IBAN BIC La langue néerlandaise/française 10 est choisie pour l interprétation du contrat. Toute correspondance concernant l exécution du marché doit être envoyée à l adresse suivante: (rue) (code postal et commune) (n de et de ) (adresse ) Fait: A Le 20.. Le soumissionnaire ou le fondé de pouvoirs: (nom) (fonction) (signature) APPROUVE, 10 Biffer la mention inutile

117 Cahier des charges S&L/AO/386/ /217 POUR MEMOIRE: DOCUMENTS A JOINDRE OBLIGATOIREMENT A L OFFRE: - Tous les documents et renseignements demandés dans le cadre de la sélection qualitative et des critères d attribution (voir point 5 du volet C. Attribution) ; N oubliez pas de prévoir une numérotation continue de toutes les pages de votre offre, ses annexes. L ordre de préférence des lots est : LOTS Lot 1 : Développement/support opérationnel des applications de l'administration Générale de la Fiscalité - Domaine TVA Lot 2 : Développement/support opérationnel des applications de l'administration Générale de la Fiscalité - Domaine Impôts des Personnes Physiques Lot 3 : Développement/support opérationnel des applications de l'administration Générale de la Fiscalité - Domaine Impôts des Personnes Morales (Impôt des Sociétés, Impôt des Personnes morales et Impôt des Sociétés non résidentes) et domaine transversal Lot 4 : Développement/support opérationnel des applications Transnationales Lot 5 : Test des applications de l administration générale de la fiscalité Priorité du lot Indiquer par un chiffre (1, 2, 3, 4 ou 5) votre priorité (un seul chiffre différent par lot).

118 Cahier des charges S&L/AO/386/ /217 Annexe 2: Modèle de référence 1. Nom du projet. 2. Nom de 3. Secteur d'activité l entreprise. 4. Nom du 5. Coordonnées contact. 6. Portée 7. Buts poursuivis du développement ou du projet. 8. Date de début 9. Date de fin (par phase) Budget (EUR) A. Matériel B. Logiciels C. Services 11. Résumé et brève description du rôle et de la part des éventuels A. Nom de la ou des entreprises B. Partie du marché C. Compétence sous-traitants 12. Complexité Nombre d utilisateurs, nombre de systèmes IT hors PC (nombre de mainframes, minis et serveurs) 13. Résumé et brève description des systèmes sources 14. Résumé et brève description des systèmes pour la réalisation du projet 15. Méthode de gestion de projet 16. Aperçu des profils affectés au projet ; (nombre (TOTAL) de personnes et hommes-jours pour le projet complet. A. Matériel B. Logiciels A. Matériel B. Logiciels Instrument/méthode. Profil 1 Profil 2 Profil 3 Profil 4 Profil 5 C. Environnement de développement C. Environnement de développement Profil

119 Cahier des charges S&L/AO/386/ /217 ANNEXE 3.a.: Curriculum vitae - INDIVIDUEL NB : L'utilisation de ce modèle est obligatoire. En complétant les CV, le soumissionnaire doit veiller à écrire le nom des personnes en toutes lettres. De même, il précisera clairement les diplômes et les établissements d'enseignement où ils ont été obtenus. Le pouvoir adjudicateur s'engage à traiter ces données avec une extrême discrétion et à ne les utiliser que pour les besoins de l'évaluation de l'offre. Le pouvoir adjudicateur se réserve le droit de considérer comme insuffisants les CV qui ne respecteront pas les règles ci-dessus et de ne pas les prendre en compte dans l'évaluation de l'offre. Si les diplômes mentionnés ne correspondent pas à la réalité, le pouvoir adjudicateur se réserve le droit d'exclure l'offre. Nom Fonction dans le projet : Description de la pertinence du profil pour le marché : Le soumissionnaire explique de la façon la plus détaillée possible pourquoi le profil en question est utile dans le projet. Formations : Humanités ou équivalent : Diplôme obtenu le (date) Enseignement supérieur non universitaire (répéter si nécessaire) : Titre Diplôme obtenu le (date) Institution Enseignement supérieur universitaire (répéter si nécessaire) : Titre Diplôme obtenu le (date) Institution Expérience professionnelle : Chez le soumissionnaire : Fonction actuelle o Titre o Description de fonction o Depuis le Fonction précédente (répéter si nécessaire) o Titre o Description de fonction Du... au... Participation aux projets suivants visés à l'annexe «modèle de référence» (projet et fonction) Participation à d'autres projets importants (nom, client et fonction assumée)

120 Cahier des charges S&L/AO/386/ /217 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)

121 Cahier des charges S&L/AO/386/ /217 ANNEXE 3.B.: Curriculum vitae - SYNTHESE Le soumissionnaire doit également remettre un tableau de synthèse des CV. Ce tableau de synthèse de tout CV est formaté de la manière suivante : Nom : Matière 1 Niveau d expertise de la matière 1 Nombre de mois d expérience et pratique effectifs dans la matière 1

122 Cahier des charges S&L/AO/386/ /217 ANNEXE 4: SLA a completer Le SLA à compléter ce trouve dans le fichier joint sous format XLS. Dans l offre, ce dernier doit être rempli dans le fichier joint.

123 Cahier des charges S&L/AO/386/ /217 ANNEXE 5 DESCRIPTIF DES APPLICATIONS Lot 1 (Domaine TVA) INTERVAT STIR-TVA STIRON-TVA MOSS (Mini One Stop Shop) I. INTERVAT a. Description fonctionnelle Introduction L application Intervat est le point d entrée (e-service) exclusif du SPF Finances pour la plupart des déclarations à la TVA et a été rendue obligatoire sauf rares exceptions pour tous les déclarants. Les déposants peuvent ainsi effectuer le dépôt signé et sécurisé de déclarations par voie électronique, soit manuellement, soit à l'aide de fichiers XML, et suivre le cycle de dépôt jusqu à l accusé de réception. INTERVAT implémente la législation belge et européenne en matière de TVA. Comme tout e-service, Intervat est accessible via un portail où sont décrites de nombreuses informations utiles à propos de l application, et à partir de laquelle il est possible de tester l application. Le portail spécifique à Intervat se trouve à l URL suivant : Acteurs Il y a deux principaux types d acteurs : - les utilisateurs externes : ce sont les déposants (susmentionnés). Ils peuvent notamment déposer en leur nom ou pour des tiers (nommés déclarants). - les utilisateurs internes : ce sont des fonctionnaires. Ils peuvent notamment déposer pour des tiers, ou accéder à la recherche intégrale. Certains utilisateurs internes ont accès à des parties de l application qui fournissent des statistiques ou permettent de modifier certaines règles de dépôt. Composition Intervat est composé des composants ou modules fonctionnels suivants, relatifs chacun à un type de déclaration séparé : Composant TVA LK ICO VR Prorata MTN Couverture fonctionnelle. Déclarations périodiques à la TVA. Listings clients. Relevés intracommunautaires. Demandes de remboursement Vatrefund. Communication du prorata définitif pour une déclaration Vatrefund Relevés de livraisons intracommunautaires des moyens de transport neufs. 629 Déclaration TVA spéciale 629 (article 53 ter du code TVA) pour les personnes qui ne déposent pas de déclarations périodiques mais qui sont redevables de la taxe conformément à l article 51 1, 2 en 2 du code TVA.

124 Cahier des charges S&L/AO/386/ /217 MOSS Régime particulier pour les assujettis qui ne sont pas enregistrés dans 1 ou plusieurs Etats membres dans lesquels ils ont effectué certains services pour le compte de non-assujettis. Le module MOSS comprend 2 volets : 1) enregistrement et 2) déclaration. A cette liste, il faut ajouter les modules «de gestion» suivants qui ne sont accessibles que via la version intranet d Intervat (appelée Intervatconsult voir plus loin) : dont l objet est : Gestion La gestion des règles de déclaration Statistiques Administration la production de Statistiques sur les envois par type de déclaration Fonctionnalité qui permet de joindre une communication pour l utilisateur d Intervat Un dépôt est défini comme l opération par laquelle l utilisateur fait le dépôt d une ou plusieurs déclarations et de leurs annexes. Un envoi est défini comme la réalisation complète d un dépôt. Dans ce texte, Envoi et dépôt peuvent être considérés comme synonymes dans la plupart des cas. Schéma d Intervat Soumission d une ou plusieures déclarations Validation Création via l interface Web, suivi de l envoi (1 déclaration) Ou chargement et envoi d un fichier XML (1 ou plusieurs déclarations) Par rapport au schéma XSD Et contrôle du n TVA (BTWSigna ou format pour non BE) Et règles spécifiques par type de déclaration Stockage du message + quelques attributs Génération accusé de réception Envoi STIR STIR-TVA pour les déclarations périodiques, listings clients, relevés intracommunautaires et déclarations 629 STIRINT pour MTN, VatRefund et Prorata Réception et stockage de la réponse de STIR Requirement non fonctionnels Disponibilité Intervat est une application hautement critique, dont la haute disponibilité (7j/7 24h/24) doit être assurée, impliquant une réactivité de la part de la firme à apporter en cas de défaillance système.

125 Cahier des charges S&L/AO/386/ /217 Volumes et débits Le volume de transactions suivant a été mesuré (un seul envoi peut contenir plusieurs documents) : Type de déclaration Nombre d'envois en 2012 Pics de déclaration (envois) TVA Pic trimestriel (janvier, avril, juillet, octobre ) de envois LK Echéance fin mars : +/ envois en mars ICO Pic trimestriel (janvier, avril, juillet, octobre) de envois VR Échéance fin septembre : +/ envois en septembre MTN Déclaration trimestrielle (janvier, avril, juillet, octobre) PR 39 Le volume de transaction suivant est une estimation des volumes futurs : Type de déclaration Nombre de déclarations (envois) Picsde déclaration (envois) 629 (en production depuis avril 2013) MOSS 580 envois en avril 2013 volume annuel escompté de +/ déclarations Difficile à estimer nouveau régime Pic trimestriel (janvier, avril, juillet, octobre) Tous ces volumes (des deux précédents tableaux) sont à considérer comme un minimum, sachant que le nombre d utilisateurs augmente d année en année et que de nouveaux types de déclarations seront encore ajoutés à l application. IHM L Interface Homme-Machine d Intervat est conforme aux standards de présentation décrit dans la Charte Graphique CCFF. Cette conformité, impliquant l utilisation des composants visuels de CCFF, est obligatoire. b. Cycle de vie de l application 1. Adaptations de l'application aux évolutions technologiques internes (le monde java nécessite un release majeur toutes les 2 années); 2. Adaptations de l'application aux évolutions technologiques externes (OS, navigateur, ); 3. Adaptations de l'application aux modifications législatives. c. Indications quant à la future maintenance évolutive

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

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

128 Cahier des charges S&L/AO/386/ / Adaptations de l'application aux évolutions technologiques internes (le monde java nécessite un release majeur toutes les 2 années); 2. Adaptations de l'application aux évolutions technologiques externes (OS, navigateur, ); 3. Adaptations de l'application aux modifications législatives. STIR-TVA c. Indications quant à la future maintenance évolutive Les déclarations périodiques, les listings clients et les relevés intracommunautaires sont envoyés d Intervat vers l application back-office STIR-TVA. Ces documents sont d abord réceptionnés dans Intervat, éventuellement dans un fichier qui contient plusieurs documents. Ces fichiers doivent être scindés en documents uniques. Cette scission a actuellement lieu dans le mux-demux qui se situe entre Intervat et STIR-TVA. Le but est de contourner mux-demux et que la scission des documents ait lieu directement dans Intervat. L utilisation de mux-demux rend le processus plus complexe, demande une maintenance et est dépassée sur le plan technique. Ce système n'est utilisé que par Intervat. On ne l utilise pas dans les autres applications (p. ex. les déclarations IPP). L abandon de mux-demux entraîne d importants changements du côté de STIR-TVA.

129 Cahier des charges S&L/AO/386/ /217 III. STIRON-TVA a. Description fonctionnelle Stiron TVA (Stiron est le nom générique d'une série d'applications TVA qui remplacent les anciennes applications TVA depuis mars Ces applications sont connectées entre elles et interagissent mais communiquent aussi avec des applications externes (aussi bien du SPF qu externes à ce dernier). Le schéma ci-dessous illustre l application Stiron TVA et ses interactions. Sur ce schéma, les composantes de l application Stiron TVA sont : - Stiron Entités spécifiques - Compte courant - Recouvrement - Comptes spéciaux - VIES - Datamart - Listes intranet - RPMSIG

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

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

132 Cahier des charges S&L/AO/386/ /217 Le module 2 de l application STIRON TVA permet de gérer le compte courant TVA d un assujetti. Cela signifie que tous les arguments possibles, tant positifs que négatifs doivent pouvoir y être inscrits et correctement interprétés. Il s agit principalement des arguments : Déclarations TVA : case 71 ou 72 correction d une déclaration TVA Paiements TVA Décisions 685B et 686B À chaque clôture mensuelle, l application doit pouvoir correctement calculer le solde ou, en d autres termes, vérifier si le montant versé est suffisant ou si une déclaration TVA a été inscrite pour la période concernée. Le cas échéant, l'application doit être capable de calculer le montant correct des intérêts et/ou des amendes dus. Une clôture mensuelle suppose aussi que certains comptes courants peuvent avoir un argument remboursement ou remise à zéro en tenant compte de la réglementation en vigueur. L application doit aussi pouvoir simuler une clôture anticipée pour permettre au SPF Finances d avertir un assujetti qu'il n est pas en règle et lui donner ainsi l occasion de respecter ses obligations fiscales. L application doit aussi permettre aux bureaux de contrôle de la TVA de modifier certains paramètres, notamment le paramètre de demande de remise à zéro, le paramètre de reprise sur la Liste 678, le paramètre d opposition à un remboursement et le paramètre d autorisation du remboursement mensuel. En ce qui concerne le Centre de traitement de l information, l application doit offrir la possibilité de rectifier les paiements effectués indûment par un transfert entre comptes courants. Le CTI doit aussi offrir la possibilité de retirer de l argent d un compte courant pour le transférer à des collègues comptables et/ou un assujetti dans le cadre d une procédure spéciale de remboursement. STIRON TVA doit pouvoir traiter tous les jours les fichiers CODA de la poste financière et inscrire immédiatement les paiements avec communication structurée dans le compte courant. Les paiements qui ne peuvent pas être traités automatiquement doivent être inscrits dans un registre d attente. Ce registre d'attente doit permettre au CTI d attribuer différentes destinations à ces paiements. Voici, cidessous, une liste des possibilités: Remboursement au donneur d ordre Comptabilisation définitive réception affectation à un compte courant transfert à un collègue comptable envoi d une lettre au donneur d ordre du paiement pour obtenir de plus amples informations laisser en attente L'application doit être capable de générer les statistiques nécessaires concernant les fichiers de paiement entrés, concernant la clôture mensuelle et concernant l'état du registre d'attente. Ces statistiques sont indispensables pour le contrôle de la comptabilité. En ce qui concerne les remboursements de TVA, STIRON TVA doit pouvoir générer toutes les listes imaginables pour permettre le traitement des remboursements. Cela concerne les listes des remboursements directement exécutables, les remboursements via les listes 678, 678bis, 702 et 702bis. Les remboursements frappés d opposition via le paramètre cité plus avant doivent donner lieu à l impression d un document 715. L application doit pouvoir générer les fichiers d impression nécessaires pour l impression et l envoi des lettres et/ou documents 628, 680, 671, 673, 670, 642 et 642V. Module 3 Recouvrement Bureau de contrôle:

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

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

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

136 Cahier des charges S&L/AO/386/ /217 M2 M3 M3 M2 M2 M1 M2 Liste 749/7 Liste des décisions 686 encodées par les offices de contrôle TVA. Liste 749/1 Liste des diminutions d O.R. par les services de taxation TVA Liste 749/3 Liste des radiations d O.R. par les services de taxation TVA. Liste 692 (bureau) (remboursements trimestriels) Liste 692 (overview) (remboursements trimestriels) Liste forfaitaire des assujettis Liste 4070 (autorisation remboursement mensuel) RPM_SIG BTW Signa Serveur VIES Module 8 : Lien avec DIM et Filenet Le courrier entrant et sortant doit pouvoir être consulté à partir de l application STIRON Lot 2. Pour cela, il faudra prévoir une synchronisation avec le projet DIM/Myscan Mise en production : septembre Module 9 : ET14000, Monitoring et reporting Ce module comprend le remplacement de l application qui assure la gestion des autorisations ET ET14000 n entrera en production qu'au cours du troisième trimestre De plus, le module 9 contient aussi des statistiques et les outils de monitoring et de reporting concernant l ensemble du Lot STIRON. Pour ces statistiques, un Datamart a été mis au point qui est exploité. b. Cycle de vie récurrent 1. Adaptations de l'application aux évolutions technologiques internes (le monde java nécessite un release majeur toutes les 2 années); 2. adaptations de l'application aux évolutions technologiques externes (OS, navigateur, 3. adaptations de l'application aux modifications de structure de l'organisation; 4. adaptations de l'application aux modifications législatives. L application est utilisée de manière intensive par les bureaux de contrôle de la TVA, les bureaux de recettes, le CTI. Le CTRI, l ISI, depuis mi-mars Ses utilisateurs ont relevé une série de manquements qui ne sont pas des bugs car conformes à l analyse. Ces manquements ne bloquent pas le fonctionnement de l application et de l'administration de la TVA mais empêchent parfois d aboutir à une solution adaptée. Lorsque des problèmes sont signalés concernant certaines fonctionnalités, ces problèmes doivent être étudiés, en partie par le business mais aussi par une équipe technique. Le diagnostic du problème, la recherche de solutions et l implémentation de ces solutions font tout autant partie du marché.

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

138 Cahier des charges S&L/AO/386/ /217 IV. MOSS a. Description fonctionnelle Le projet «Mini One Stop Shop» (MOSS) qui a démarré en février 2013 a pour objectif de répondre aux nouvelles exigences européennes en matière de TVA. Plus précisément ce projet vise le développement d'une application électronique assurant la gestion d'un régime TVA particulier offert à compter du premier janvier 2015 aux assujettis non établis dans un ou plusieurs Etats membres de l'ue qui fournissent des services de télécommunication, de radiodiffusion et de télévision ou des services électroniques à des personnes non assujetties dans ces Etats membres. Les spécifications fonctionnelles et techniques ont donc été définies par l UE pour s assurer de la cohésion des applications entre les pays mais également par le SPF Finances pour toutes les spécificités propres à son environnement. Ce projet est encadré par des dispositions législatives européennes (une modification de la directive 2006/112 réglant le fonctionnement de la TVA, le Règlement 904/2010 organisant la coopération administrative en matière TVA et des nouveaux Règlements d'application des nouvelles règles en question). Ce guichet unique (M1SS) reprend et inclut l'actuelle application VOES (VAT on e-services) dédiée aux prestataires établis en dehors de l'ue et qui ont demandé leur assujettissement en Belgique. Le projet comporte également la mise en œuvre des dispositions européennes relatives à l'accès aux bases de données et aux échanges automatiques d'informations permettant aux Etats membre d'assurer le contrôle de ce régime particulier. 4 modules ont été identifiés pour la réalisation de ce projet. 1. Module «enregistrement» 2. Module «déclaration» 3. Module «paiement» 4. Module «statistiques & reporting» Conformément au planning du projet, les 2 premiers modules ont été développés, testés au niveau belge et au niveau européen (tests de conformance). Les tests du module paiement sont en cours. Le module «Statistiques & reporting» est en cours d analyse et de développement. Ci-dessous une description plus élaborée des aspects fonctionnels et techniques du système MOSS. Pour chacune de ces parties, différentes tâches sont décrites. Ces tâches sont ensuite divisées en sous-tâches en fonction du rôle de la Belgique soit : - comme Etat membre d identification : MSid - comme Etat membre de consommation : MSCon - comme Etat membre d établissement : MSEst - comme autre Etat membre. 1) L enregistrement Le module enregistrement couvre la gestion des demandes d'enregistrement, des demandes de modifications des données d'enregistrement, des demandes d exclusions et la gestion des requêtes sur les données d enregistrement. Demandes d enregistrement BE= MSid ( Etat membre d identification) a) Réception de la demande d enregistrement L adaptation du portail Intervat n est pas couverte par ce module du cahier des charges. Par contre, le lien entre Intervat et l application Mini OSS sera bien à réaliser. Il s agit donc de réceptionner les demandes selon leur provenance.

139 Cahier des charges S&L/AO/386/ /217 b) traitement de la demande : Il faut distinguer un premier traitement de forme de la demande d un traitement de fond (acceptation ou refus de la demande). traitement de forme de manière automatique, directement au moment de l encodage (Intervat) traitement de fond consistant à vérifier que l assujetti rempli les conditions nécessaires et suffisantes pour utiliser ce régime particulier tout en laissant la décision finale à l administration. Le système organise la transmission de la demande d enregistrement aux services concernés via le Task manager. L agent chargé de statuer sur la demande dispose de toutes les informations nécessaires à sa décision et notamment des informations contenues dans la base de données MiniOSS. Il est possible de marquer ( flager ) certains assujettis suspects nécessitant une surveillance. Enregistrement des données d identification dans la base de données belge au sein de l application (pour le EU scheme et pour le non EU scheme). Notification à l assujetti : acceptation/refus. Envoi aux autres Etats membres : Les données d enregistrement doivent être transmises au plus tard pour le 10e jour du mois qui suit la demande d enregistrement. Afin d éviter des enregistrements doubles, la Belgique envoie au fil de l eau dès l acceptation plutôt que par Batch. Flag spécifique dans la signalétique de l assujetti (entité TVA) signalant que l assujetti utilise ce régime spécifique. BE= MSCon, MSest ou autre MS : - intégration des informations reçues dans une base de données avec, entre autres, écran de consultation et historiques des informations. - Flag spécifique dans la signalétique de l assujetti (entité TVA) signalant que l assujetti utilise ce régime Gestion des modifications des données d enregistrement : BE= MSid ( Etat membre d identification) Système quasi parallèle au processus de gestion des demandes d enregistrement : - Réception de la demande de modification : via Intervat ou site Internet - Traitement de la demande : acceptation ou refus - Notification de la décision à l assujetti - Enregistrement des données dans la base de données Mini OSS (avec historique) BE= MSCon, MSest ou autre MS Des requêtes adressées aux MSid doivent pouvoir être réalisées : requêtes automatiques pour une mise à jour régulière des informations, et/ou requêtes sur demande. Gestion des exclusions : Deux possibilités de demande d exclusion : de l assujetti lui-même ou de l Etat membre d identification faisant parfois suite à la demande de l Etat membre de consommation. Lorsque, pour différentes raisons énumérées dans la Directive, l assujetti fait une demande d exclusion (via le portail), cette demande doit être traitée de la même manière qu une demande d enregistrement (5 étapes) - Réception de la demande d exclusion : via Intervat ou site Internet - Traitement de la demande : information complète ou non - Notification de la décision à l assujetti - Enregistrement de l exclusion dans la base de données Mini OSS - Envoi de l information d exclusion à tous les EM. avec code d exclusion. Comme MSid, l application devra générer de manière périodique une liste des assujettis ne remplissant plus les conditions pour pouvoir se prévaloir du présent régime particulier (pas de déclaration, pas de paiement, paiement partiel ). Cette liste sera transmise au(x) service (s) compétent(s) pour traitement et action. En cas de décision d exclusion :

140 Cahier des charges S&L/AO/386/ /217 - Notification de l exclusion à l assujetti - Enregistrement de l exclusion dans la base de données Mini OSS - Envoi de l information d exclusion à tous les EM. (codes d exclusion) Comme autre Etat membre, la Belgique devra recevoir les notifications d exclusion venant des Etats membres d identification et les intégrer (mise à jour) dans la base de données MiniOSS. Gestion des requêtes sur les données d enregistrement : La Belgique doit pouvoir d une part réaliser des requêtes à l attention des autres Etats membres (écran de requête) et d autre part traiter les requêtes reçues des autres Etats membres concernant les assujettis identifiés en BE. Comme c est le cas pour VIES, il s agit d un processus de requête sur les données d enregistrement dans la base de données des MSid. Ce processus est tout à fait informatisé et donc sans aucune intervention humaine. 2) La déclaration La partie déclaration assure la gestion des déclarations, des déclarations correctives, les transmissions des informations aux Etats membres Gestion des déclarations BE= MSid ( Etat membre d identification) a) Enregistrement de la déclaration par le NETP : Les déclarations sont introduites par les NETP via le portail Intervat. Elles sont ensuite transmises pour traitement à l application MiniOSS. A nouveau, l application couvre le lien entre Intervat et le backoffice pour la réception des déclarations et des corrections. b) Vérification de la déclaration initiale reçue => déclaration acceptée ou refusée. c) Assignation d un numéro de référence unique à la Déclaration d) Enregistrement de la Déclaration dans la base de données e) Envoi d un accusé de réception au NETP avec le numéro de référence et l invitation au paiement f) Division de la déclaration par Etat membre concerné. g) Envoi des déclarations aux EM : envoi groupé suivant les spécifications liées aux paiements. BE= MSCon (Etat membre de consommation ou MSEst (Etat membre d établissement) - Réceptionner, valider et enregistrer les déclarations reçues par assujettis dans la base de données européenne. - Assurer le traitement des déclarations et le lien avec le paiement reçu - Mettre en place une série de contrôles automatiques - Générer des exports de données nécessaires au contrôle humain. Gestion des corrections BE= MSid Si une correction est déposée avant le 21e jour du mois qui suit le trimestre, la correction écrase et remplace la déclaration initiale. Si une correction est déposée après le 20e jour du mois qui suit le trimestre, la déclaration corrective est traitée comme la déclaration antérieure qu elle modifie. Elle garde cependant la même référence, mais reçoit un nouveau timestamp. Toutes ces versions sont conservées dans la base de données. BE=MScon ou MSEst Toutes les déclarations correctives reçues sont traitées de la même manière que la déclaration initiale. Elles sont intégrées dans la base de données en fonction du trimestre auquel elles se rapportent. Correction suite à un contrôle : suite à un contrôle, une modification pourrait être apportée aux données de la déclaration. Dans ce cas, un écran d encodage donnant accès à un XML spécifique est à prévoir.

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

142 Cahier des charges S&L/AO/386/ /217 Lors du développement, une série de modifications aux spécifications d origine («KEL») ont déjà été introduites par la Commission Européenne. Certaines modifications viennent d être approuvées ou sont encore en cours d approbation (annexes 1 et 2). L ouverture des échanges entre les Etats-membres début janvier 2015 a mis en lumière d importantes différences d interprétation de la législation et des spécifications. Il en résulte un nombre conséquent de rejets de messages intracommunautaires mettant à mal le bon fonctionnement de ce nouveau régime. De nouvelles modifications des spécifications devront donc être renégociées et ensuite implémentées. Une assistance complémentaire est donc indispensable au maintien d une application fonctionnelle, et doit-nous permettre de respecter les modifications des spécifications fonctionnelles et techniques imposées par la Commission. Il est important de noter que celles-ci sont contraignantes pour les Etats membres. c. Indications quant à la future maintenance évolutive De futures modifications aux logiciels et aux applications résultant de changements législatifs, d upgrades apportés aux environnements ainsi que d éventuelles demandes d améliorations de la part des utilisateurs finaux sont susceptibles de voir le jour. Compte tenu du fait que l application MOSS est entrée en production le 1 er janvier dernier (2015), aucune indication précise quant à la future maintenance évolutive ne peut être communiquée.

143 Cahier des charges S&L/AO/386/ /217 Lot 2 (Domaine Impôts directs Personnes Physiques (IPP + INR/PP) Belcotax-On-Web (BOW) Tax-On-Web (TOW) Taxi Proposition de Déclaration Simplifiée (PDS) Calculatrix (Calcul IPP) I. Belcotax-On-Web (BOW) a. Description fonctionnelle L'art. 92 de l'a.r. d'exécution du C.I.R (Moniteur belge du ) stipule qu'à la fin de chaque année, les redevables du précompte professionnel sont tenus de remplir une fiche pour chacun des bénéficiaires des revenus et d'établir un relevé récapitulatif de ces fiches. Dans le cadre du système Belcotax on web, les employeurs et autres débiteurs de revenus soumis au précompte professionnel doivent satisfaire à cette obligation vis-à-vis de l Administration de la fiscalité des entreprises et des revenus en fournissant les informations via le web. L utilisation de Belcotax on web a été rendue obligatoire pour l ensemble des débiteurs des fiches à et à partir du 01/01/2009. De même, l'art. 57 de l'a.r. d'exécution du C.I.R stipule que dans les 2 mois qui suivent chaque année civile de la période pour laquelle l agrément a été obtenu une copie des attestations délivrées doit être remise à l administration. Dans le cadre du système Belcotax on web, les institutions agréées peuvent satisfaire à cette obligation vis-à-vis de l Administration de la fiscalité des entreprises et des revenus en fournissant les informations via le web. L utilisation de Belcotax on web a été rendue obligatoire pour l ensemble des institutions à partir du 01/01/2012. L application a été étendue à d autres données tel que attestations de titres services, épargne pension, fiches rentes alimentaires ; etc. A ce jour, 35 types d informations différentes sont récoltées annuellement représentant plus de de fiches ou attestations

144 Cahier des charges S&L/AO/386/ /217 Pour accéder aux fonctionnalités de Belcotax on Web l utilisateur doit disposer d une signature électronique de type certificat ou posséder une carte d identité électronique belge. Chaque année, une nouvelle application doit être créée à partir de celle de l année précédente, des adaptations sont nécessaires pour prendre en compte les directives relatives à la nouvelle année de revenus (modification de certaines fiches 281, changement d année, validations ). Toutes ces modifications sont effectuées dans le cadre de la maintenance adaptative. Les fonctionnalités : o Transfert de fichiers (Envois) via le web en format XML ou TXT o Accès via web à un programme de validation avant envoi o Possibilité d encodage par les clients externes et par l administration o Possibilité d envois de fichiers de corrections o Possibilité de consultation et de correction on-line Il permet une disposition en temps réel des données tant pour les fournisseurs de données eux-mêmes, pour les bénéficiaires de ces revenus (MYMINFIN- TOW) que les agents du SPF Finances o Enrichissement des données par recherche du numéro national et du service compétent o Communication des données via web services ou view des données aux applications TAXI, TOW, PDS ou MY MINFIN. o Etablissement de PDF des fiches, relevés et récapitulatifs de données o Etablissement de fichiers en XM,, txt ou Excel récapitulatifs (Bilan, Output prp, recherche avancée) o Ensemble de fonctionnalités à destination des gestionnaires de l application (récupération de fichiers, renvoi de feedback, modification de statuts, contournement de validation, etc) Planning Pour l année des revenus concernés. Date de remise des modifications : novembre/décembre de l année des revenus Date de la mise en Production : 1er février qui suit l année des revenus.

145 Cahier des charges S&L/AO/386/ /217 b. Cycle de vie recurrent Maintenance annuelle La maintenance récurrente couvre l annualisation des déclarations Bow. Cette maintenance est nécessaire pour suivre l évolution des déclarations Belcotax dues aux changements de la législation. Elle est constituée des points suivants : o o Création d une nouvelle version de l application. Modification des fiches. Le cœur de l application étant le traitement des fiches 281.XX, la plupart des adaptations découlent donc des modifications légales appliquées à ces fiches. Ces modifications sont générées par la modification de la législation elles ne sont connues qu à la fin du quatrième trimestre de l année des revenus pour laquelle l application doit être adaptée o Ces modifications entraînent plusieurs adaptations : adaptation du fichier XSD, modifications des règles de validation, changements dans les écrans de saisie et de visualisation des fiches et des relevés adaptation des PDF, changement de la structure des bases de données, adaptation du traitement des envois au niveau back-office, adaptation des récapitulatifs, adaptation des web services et view utilisés par les applications Taxi, Tax-on-Web et PDS (proposition de déclaration simplifiée). Mise à jour de la documentation technique Support L application Belcotax-on-Web est indispensable à l exécution des missions fiscales du SPF Finances. Tout incident de production peut avoir un impact financier et légal considérable (respect des délais légaux), ainsi qu en terme d image auprès du public (application Eservice). Préalablement avant toute intervention, un diagnostic «high level» permet de déterminer l équipe la plus appropriée pour résoudre l incident (ICT operations, équipe de développement. Si un incident survient, une équipe doit être rapidement disponible en vue d en identifier l origine et de le dispatcher à qui de droit. L expérience montre que l équipe de développement doit avoir une connaissance globale suffisante pour accomplir cette mission. Outre ce support de gestion des incidents et autres, il y a lieu de prévoir support complémentaire en vue d améliorer les fonctionnalités existantes aux niveaux de la convivialité, du traitement de cas particuliers. c. Indications quant à la future maintenance évolutive 1. Migration vers authentification FedIam L authentification se réalise actuellement via les services de la sécurité sociale (erranova) elle devrait migrer à terme vers une authentification similaire à celle pour Tax on web 2. nouvelles fiches fiscales à intégrer. La mise en place de la régionalisation devrait entraîner à terme une augmentation des informations récoltées via Belcotax on web. 3. Optimisation de l enrichissement du Numéro national des attestations de dons en utilisant les résultats de l enrichissement NP de l année antérieure.

146 Cahier des charges S&L/AO/386/ / Permettre la consultation modification par un expéditeur de données introduites antérieurement par des sociétés qui ont été ensuite absorbées ou fusionnées avec cet expéditeur.

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

148 Cahier des charges S&L/AO/386/ /217 Tax-on-web permet aussi de visualiser les plus de de propositions de déclaration simplifiée. Cela permet au citoyen de toujours modifier ou compléter sa déclaration. Les déclarations introduites par voie électronique peuvent être traitées immédiatement, ce que les citoyens peuvent remarquer au fait que les premiers avertissements-extraits de rôle sont envoyés dès le mois de juillet (grâce à l intégration du service Zoomit, il y a aussi moins d avertissements-extraits de rôle envoyés sur papier). Un traitement plus rapide et correct des déclarations introduites génère aussi d'importantes économies au niveau des frais de fonctionnement de l'administration. Dans cette optique, le développement de wizards contribue à améliorer la qualité des données entrantes au SPF Finances. De plus, une simulation de calcul anonyme Taxcalc est proposée sur le site web du SPF Finances et une application d entraînement a été mise au point pour les écoles et les organisations intéressées (Taxsimu). Tax-on-web est disponible dans les trois langues officielles, le français, le néerlandais et l allemand. L application doit rester utilisable sur tous les systèmes d'exploitation courants et navigateurs courants. La disponibilité (24h/24 et 7j/7) de l application est une exigence. b. Cycle de vie recurrent a. Contexte Tax-on-web existe depuis L application a atteint à ce jour une maturité tant du point de vue fonctionnel que technique. Cependant, chaque année, la déclaration fiscale étant modifiée, une série d activités de maintenance doivent être réalisées afin de garantir le bon fonctionnement de l application. b. Activités de maintenance adaptative Les tâches principales sont. Project setup Modification des cadres de la déclaration Partie I et II Adaptation des autres cadres (Notes, accusé de réception, Taxworkbox, etc.) Génération des PDF en fonction du nouveau format de la déclaration Adaptation des règles de validation Codes particuliers Wizards Codes montants négatifs Code unique pour plusieurs montants Gestion spécifique des revenus étrangers

149 Cahier des charges S&L/AO/386/ /217 Mise-à-jour de l encodage rapide Maintenance du catalogue de test (Quick test) Modification du schéma pour l envoi en masse (mandataire) Chargement des différentes DB Prefilling de certains codes de la declaration Mise à jour des éléments statiques Par exemple : Templates Finform, pdf mandataires Mise-à-jour de l aide (FAQ, ) Mise à disposition du livret explicatif au format HTML Mise à jour de l interface avec le calcul et l optimisation Suivi technique Entre autre : Préparation et suivi des livraisons Support en production Mise à jour de l application de correction d une declaration. Mise à jour de la fonctionnalité Zoomit Mise à jour de l application d'entraînement (pour écoles etc.) Mise à jour de l application Taxcalc INR-BNI Mise à jour de module de statistiques Mise à jour de l application suite à des modifications réalisées dans d autres applications. 1. PROJECT SETUP Chaque année avant que l équipe projet puisse commencer l analyse et le développement de la nouvelle version, une série de tâches basiques doivent être effectuées afin de rendre l environnement de développement opérationnel. Kick off avec le SPF Configuration des outils, Mise-à-jour des environnements Backup divers, création des labels, 2. MODIFICATION DES CADRES DE LA DÉCLARATION PARTIE I ET II Les cadres de l application seront adaptés en fonction de la nouvelle déclaration IPP. 3. ADAPTATION DES AUTRES CADRES (NOTES, ACCUSÉS DE RÉCEPTION, TAXWORKBOX) Les autres cadres seront également adaptés pour prendre en compte la nouvelle année fiscale. Il s agit par exemple des écrans Parallèlement aux cadres de la déclaration, les autres pages de l application «Notes», les accusés de réception, l écran de résumé avant soumission,

150 Cahier des charges S&L/AO/386/ / GÉNÉRATION DES PDF EN FONCTION DU NOUVEAU FORMAT DE LA DÉCLARATION Les déclarations doivent pouvoir être visualisées au format PDF. 5. ADAPTATION DES RÈGLES DE VALIDATION Les règles de validation ainsi que les messages associés destinés à l utilisateur seront adaptés à la nouvelle déclaration fiscale. Les règles Business sont quant à elles fournies par le SPF Finances 6. CODES PARTICULIERS Certains codes de la déclaration ont des fonctionnalités particulières. Celles-ci doivent également être mises à jour en fonction de la nouvelle version de la déclaration : wizards, codes permettant des montants négatifs, code unique pour plusieurs montants, gestion spécifique des revenus étrangers. 7. MISE À JOUR DE L ENCODAGE RAPIDE L encodage rapide (et visualisation directe des fiches Belcotax) pour le nouvel exercice d imposition. 8. TESTING Pour chaque version mise en production i lest nécessaire d exécuter un nombre de tests unitaires. Des de tests seront également fait en collaboration avec le test center. 9. MODIFICATION DU SCHÉMA POUR L ENVOI EN MASSE (MANDATAIRE) L envoi en masse est une fonctionnalité utilisée par les mandataires qui leur permet d envoyer via un fichier.tow plusieurs déclarations simultanément dans l application. Ces fichiers sont créés via les logiciels de comptabilité suite aux spécifications fournies par le SPF finances. Le schéma xml et les spécificités techniques seront adaptés à la nouvelle déclaration. Le SPF quant à lui se chargera, comme pour les années précédentes, de la publication de la documentation technique. 10. CHARGEMENT DES DIFFÉRENTES DB L ensemble des données nécessaires au fonctionnement de Tax-on-web 11. PRÉFILLING Depuis plusieurs années, le SPF pré-remplit autant que possible la déclaration des citoyens en fonction des données disponibles lors du démarrage de Tax-on-web. Ces données proviennent de différentes origines.

151 Cahier des charges S&L/AO/386/ / MISE À JOUR DES ÉLÉMENTS STATIQUES Templates Finform, pdf mandataires Mise-à-jour de l aide (FAQ, ) Mise à disposition du livret explicatif au format HTML 13. MISE À JOUR DE L INTERFACE AVEC LE CALCUL ET L OPTIMISATION Les interfaces vers la version 2013 du calcul ainsi que vers l optimisation seront adaptées en conformité avec la nouvelle déclaration 14. SUIVI TECHNIQUE En collaboration avec les autres services ICT. Il s agit de la preparations et suivi des livraisons et le support en production. 15. MISE À JOUR DE L APPLICATION (FONCTIONALITE) DE CORRECTION D UNE DECLARATION. Depuis 2013 le contribuable a la possibilité de modifier sa declaration déjà soumise. 16. MISE À JOUR DE LA FONCTIONALITE ZOOMIT Zoomit permet de recevoir des documents via le PC banking. Dans Tax-on-web l utilisateur peut choisir de bénéficier du service Zoomit. Il est nécessaire que le numéro de compte bancaire du contribuable soit lié à Zoomit. Pour cela Tax-on-web utilise les fonctionalitées mises à disposition en interne. 17. MISE À JOUR DE LA FONCTIONALITE DE CORRECTION D UNE DECLARATION. Mise à jour de l application de correction d une declaration. Le contribuable a la possibilitée de corriger sa declaration après la première soumission. 18. MISE À JOUR DE L APPLICATION D ENTRAÎNEMENT Basée sur l architecture de Tax-on-web, l application d entraînement sera également adaptée à la nouvelle déclaration. 19. MISE À JOUR DE L APPLICATION TAXCALC Le calcul anonyme (disponible sur le site web du SPF Finances) Il s agit du calcul de l année actuelle et des années précédentes. 20. INR-BNI

152 Cahier des charges S&L/AO/386/ /217 Activités principales : Cadres de la déclaration Annexes et Notes Encodage rapide Parties I et II Envoi en masse Règles de validation spécifiques Traitement des fichiers imprimeurs Aide en ligne - livret explicatif et aide générale Base de données Interaction avec le module de calcul Gestion des PDF de la déclaration (semi-dynamique) Support et mise en production 21. MISE À JOUR DU MODULE DE STATISTIQUES Le module de statistique a été développé en Il propose certaines statistiques basées sur des requêtes dans la base de données de Tax-on-Web. La mise-à-jour consiste à maintenir ces requêtes (notamment pour mettre à jour l année) et éventuellement à adapter les données business, si nécessaire. 22. MISE A JOUR DE L APPLICATION SUITE AUX MODIFICATIONS REALISEES DANS D AUTRES APPLICATIONS. Tax-on-web est en interaction avec d autres applications. Par exemple : Zoomit, Taxi, FED IAM, IAM etc. Suite à des modifications nécessaires pour le bon fonctionnement des autres applications, Tax-on-web doit s adapter également. c. Indications quant à la future maintenance évolutive Evolutions possibles : - Création de nouveaux wizards avec pour but d aider les utilisateurs au remplissage de leur déclaration. - Mise à jour des déclarations disponibles en (quasi) real time suite à des modifications p.ex. fusion scission des dossiers, création de nouveaux dossiers. L'application TOW est toujours susceptible d'être améliorée et son évolution peut se faire à différents degrés et dans des délais encore à déterminer.

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

154 Cahier des charges S&L/AO/386/ /217 création et archivage de courriers via une application inter-active (déficit indiciaire, absence de déclaration, dégrèvement d office ) ; visualisation des données de BelcotaxOnWeb ; Le portail chef de service permet au dirigeant d un service de taxation IPP ou INR/pp de répartir la charge de travail entre les différents membres de son équipe suivant des critères basés sur la nature des dossiers ou des tâches à réaliser (par.ex validation des workflow). Divers rapports relatifs à l enrôlement aux amendes ou à la charge de travail sont disponibles en vue d assurer un suivi optimal des travaux de taxation des agents et du service dans son ensemble. La partie portail Business permet à certaines personnes : de suivre globalement l enrôlement des dossiers et l injection des déclarations ; de planifier les enrôlements, c est-à-dire, de sélectionner un ensemble de dossiers à enrôler en respectant certains critères (balance globale devant être sous un certain seuil, fonction de l origine de la déclaration, ) ; de gérer le code de la déclaration qui sont calculables et/ou enrôlable de réinitialiser le traitement d un lot de dossiers. Enfin, le portail «backoffice-admin» est destiné à gérer les processes décrits ci-après Les process continus et batchs assurent le fonctionnement intégré de l application. Les déclarations numérisées sont chargées en continu alors que les déclarations TOW ou PDS font l objet d un chargement batch. Vu la grande quantité de déclarations numérisées à traiter après les périodes de souscription (entre et ), leur traitement et leur calcul est effectué par des process continus. Le fonctionnement de TAXI est basé sur un signalitique externe, dénommé EXERCICE et hébergé sur mainframe avec lequel il se synchronise périodiquement via des batchs ou en ligne dans l utilisation du portail agent taxateur. b. Cycle de vie recurrent Maintenance adaptative La maintenance récurrente annuelle comprend les changements techniques nécessaires pour modifier l application Taxi du millésime précédent afin qu elle puisse traiter les déclarations du millésime suivant. Elle a pour objet de mettre à jour les différents composants de l application (notamment : portails, processes batchs et continus) sur base des modifications législatives, organisationnelles, ou techniques liées à l'ipp et l'inr/pp. Chaque année avant que l équipe projet puisse commencer l analyse et le développement de la nouvelle version, une série de tâches doivent être effectuées afin de rendre notamment l environnement de développement opérationnel. Ci-dessous sont reprises les activités principales liées à cette phase de démarrage. 1. Configuration des outils (Setup code source, ) Taxi comprend une application par année, ce qui permet de réaliser des évolutions techniques, fonctionnelles sans devoir intégrer ces changements pour toutes les versions

155 Cahier des charges S&L/AO/386/ /217 millésimées (base de données, ). Dans Starteam, est donc créé un nouveau code base, basé sur la dernière version stable de l année précédente. Tous les bugs fixés après ce «recopiage» doivent être reportés dans les nouvelles sources. A cette fin un label est créé dans l année N-1 pour délimiter le point de démarrage de l année N, ce qui facilite les modifications ultérieures. Dans Starteam est donc créée la structure FUP avec un préremplissage des sources de l année N-1. L application Taxi repose sur deux bases de données : une qui est indépendante de l année et qui est partagée entre les différentes applications Taxi, une autre qui est propre à un exercice donné. Pour la nouveau millésime, il faut donc créer la base de données et la charger avec certaines données comme par exemple la récupération des adresses des dossiers,. 2. Mise à jour des environnements de développement Les environnements de développements sont vérifiés et adaptés afin de pouvoir construire la nouvelle version de l application. Il s agit ici d adapter et/ou vérifier les configurations des serveurs weblogic, apaches, Afin de faciliter le suivi des requêtes de Delivery Management pour les différentes applications Taxi, un nouveau projet Taxi est créé par année dans l application DM. 3. Initialisation de la demande de projet Lors de la phase de démarrage, une série d activités de gestion de projet doivent également être prévues afin de préparer au mieux le nouveau millésime. Il s agit ici d organiser par exemple le kick off du projet, de déterminer avec le SPF Finances le premier planning mais également les priorités pour ce millésime. 4. Déclaration du nouveau millésime Les déclarations fiscales changent d année en année. Ces changements législatifs induisent des modifications dans le code, dans la base de données et dans les fichiers de propriétés de l application. Ces changements concernent l ajout/modification/ suppression de codes. Il s agit donc dans cette partie d adapter l application afin de prendre en compte l ensemble de ces changements législatifs. 5. Adaptation à l environnement technique L infrastructure et les différentes briques sur lesquels l application Taxi repose évoluent. Ces modifications doivent être intégrées dans l application afin d être en phase avec l environnement technique du SPF Finances. Cela comprend des mises à jour pour des versions mineures du framework CCFF, des changements de la version de DB2,. L adaptation technique envisagée dans cette offre couvre les modifications mineures liées à l infrastructure actuelle du SPF Finances. Si des adaptations techniques exceptionnelles non-prévues initialement s avéraient nécessaires, une estimation de la charge de travail devra être faite séparément par l équipe projet et sera soumise au SPF Finances pour validation. 6. Fonctions d importation Scanfin/TOW/PDS L application Taxi interagit avec les applications PDS, TOW et Scanfin. Les différentes déclarations de ces trois applications sont importées dans l application Taxi par deux canaux différents, d une part PDS et TOW et d autre part SCANFIN.

156 Cahier des charges S&L/AO/386/ /217 Pour l interaction avec Scanfin, le schéma XML de l interface doit être mis à jour afin de tenir compte des évolutions législatives de la déclaration. Les déclarations arrivent par lot dans un mécanisme de flux. L interaction avec TOW/PDS se déroule différemment, l application Taxi vient directement lire dans la base de données de TOW les déclarations. Ces déclarations sont stockées sous format XML. Ce fichier XML est également mis à jour chaque année pour refléter la déclaration. Ces changements doivent être pris en compte par le module qui convertit la déclaration TOW en une déclaration Taxi. 7. Process de Taxi L application Taxi comprend au moins une quarantaine de processus (batch) pour une année. Certains de ces batchs interagissent avec d autres applications qui représentent pour Taxi la source officielle de certaines données. L application Taxi interagit notamment avec les signalétiques AJ/EX, NPP, Sitran, les numéros de compte, Toutes ces interactions doivent être adaptées afin d aller sur la bonne source annuelle des données. Les «process» de synchronisation doivent être mis en place et testés. 8. Livraisons et suivi de mise en production support aux tests d acceptance Afin d'optimaliser le processus de livraison en production Taxi, un support sera fourni au SPF Finances pour ce qui est des tests d'acceptance ainsi que de la livraison et du suivi en production (livraison des modules applicatifs et de la documentation d'installation, suivi des requêtes dans Delivery Management). 9. Tests fonctionnels Toute modification, même mineure, peut entraîner l apparition de bugs. L application Taxi, de part sa criticité, ne doit pas contenir de bugs impactant le travail des utilisateurs (agents, ). A cette fin, une batterie de tests existe (automatiques et manuels) et est exécutée sur la nouvelle application afin de s assurer de son bon fonctionnement. Cette batterie de tests doit être maintenue afin de tourner correctement sur la nouvelle application. Les données mêmes des tests doivent être mises à jour (enlever les codes qui ont disparu, ajouter les nouveaux codes, ). Support opérationnel et gestion des incidents L application Taxi est indispensable à l exécution des missions fiscales du SPF Finances. La multitude et la variété des cas traités par TAXI impliquent l occurrence régulière de problèmes de production qui peuvent avoir un impact financier important. Préalablement avant toute intervention, un diagnostic «high level» permet de déterminer l équipe la plus appropriée pour résoudre l incident (ICT operations, équipe de développement, une autre application comme Belcotax, SITRAN, ). Si un incident survient, une équipe doit être rapidement disponible en vue d en identifier l origine et de le dispatcher à qui de droit. L expérience montre que l équipe de développement a une connaissance globale suffisante pour accomplir cette mission. Ces suivi et gestion concernent les différentes millésimes de Taxi (5 années sont supportées). En particulier, il faut veiller à ce que les 7 millions de dossiers soient effectivement traités, calculés et enrôlés avant le délai de prescription.

157 Cahier des charges S&L/AO/386/ /217 Outre ce support de gestion des incidents et autres, il y a lieu de prévoir support complémentaire en vue d améliorer les fonctionnalités existantes aux niveaux de la convivialité, du traitement de cas particuliers. c. Indications quant à la future maintenance évolutive a. Evolution fonctionnelle Voici une liste indicative des évolutions fonctionnelles actuellement envisagées pour l application. 1. Signalétique A l avenir, le SPF Finances envisage de remplacer les signalétiques AJ/EX et NPP (mainframe) par un signalétique relationnel «entité fiscale» basé sur Sitran. 2. Utilisation des nouveaux échanges automatisés des données et exploitation optimale des bases de données L objectif est de remplacer les actuels échanges papier. Un exemple est l échange électronique de données avec la Banque Carrefour Sécurité Sociale en ce qui concerne les données relatives aux revenus d intégration sociale. Ces échanges automatisés de renseignements permettront de calculer les moyens d existence nets, notamment en vue de la vérification des personnes à charge. Les échanges automatisés des données permettront de solutionner certains obstacles légaux. Ainsi, une exploitation des bases de données permettra de solutionner la problématique des contribuables sous administration provisoire. Taxi devra permettre l envoi de la déclaration, de la PDS ou de tout acte de procédure à l Administrateur provisoire, y compris l avis d amende. A titre de dernier exemple, en ce qui concerne les mandataires, TAXI assurera la gestion de leur mandat et de leurs coordonnées. Un échange optimal des données permettra d augmenter le «préremplissage» des données dans TOW. Un «préremplissage» accru contribuera à la simplification administrative pour les citoyens. 3. Implémentation de la signature électronique dans TAXI L automatisation accrue des actes de procédure et des autres courriers nécessite une solution à la problématique de la signature électronique. Celle-ci sera légalisée afin d éviter tout risque de contentieux. TAXI permettra de signer électroniquement tout acte de procédure et tout courrier dont l envoi est centralisé. 4. Adaptation TBT STIRCO et automatisation des codes statistiques

158 Cahier des charges S&L/AO/386/ /217 Actuellement, TAXI fait mensuellement l objet d une extraction de données de type statistiques dans le cadre du processus TBT. Quelques modifications seront réalisées en vue de limiter le processus d extraction TBT aux taxrecords liés à un traitement de type gestion. Les taxrecords liés à un traitement de type «contrôle» seront désormais liés à STIRCO. A l avenir, l objectif est d automatiser les données statistiques sans intervention de l agent. 5. Gestion des transferts de dossiers entre les Administrations P et PME Sur base d un processus déterminant un signal de départ, TAXI gèrera et planifiera le transfert des dossiers entre les Administrations P et PME. TAXI fera en sorte d accompagner ces transferts de la façon la plus automatisée possible. 6. Extension de l Intégration de TAXI en vue de la constitution d un dossier unique basé sur l entité fiscale Dans un premier temps, TAXI deviendra un outil «multi-exercices». Ensuite, l intégration avec les autres applications sera réalisée afin de permettre la constitution du dossier unique de chaque entité fiscale. Est notamment visée l intégration avec STIRCO, WF Contentieux et le dossier permanent digitalisé DOCTRAN. TAXI permettra ainsi à l utilisateur d avoir accès à l ensemble du dossier unique d une entité fiscale. Il aura donc accès à l ensemble du dossier même en cas de changement du bureau compétent. Le nouveau service pourra donc gérer l ensemble du dossier, y compris l enrôlement des suppléments d impôt relatif aux exercices d imposition pour lesquels il n était pas compétent. TAXI tiendra donc compte de la nouvelle approche en matière de gestion des compétences. L INR est bien sûr concerné par cette intégration. 7. Evolution de TAXI vers un instrument collaboratif entre chaque intervenant TAXI deviendra un instrument collaboratif entre chaque intervenant. Ainsi, les Administrations Pet PME sont composées de services de gestion, de contrôle et de contentieux. En tant qu instrument de communication entre les utilisateurs, TAXI doit permettre l interactivité entre les agents chargés de la gestion, du contrôle et du contentieux. En d autres termes, une fois que les tâches attribuées à chaque service sont déterminées dans un processus, TAXI doit devenir un instrument de coordination. TAXI, en tant qu instrument collaboratif, permettra également le télétravail et un meilleur travail à distance entre les personnes. A cet égard, la digitalisation complète des documents entrants sera un facteur de succès. Le suivi du travail effectué à distance par les agents sera assuré par TAXI. 8. Gestion automatisée des courriers Une gestion automatisée des actes de procédure et des différents courriers sera implémentée dans TAXI. Par une exploitation optimalisée de l ensemble des bases de données disponibles au sein du SPF Finances, TAXI sera doté d une fonctionnalité de rédaction des documents de procédure, notamment les demandes de renseignements, les avis de rectification, etc

159 Cahier des charges S&L/AO/386/ /217 TAXI pourra gérer l envoi et l archivage centralisé de ces documents ainsi que le suivi des délais légaux liés aux actes de procédure. TAXI offrira la possibilité à l utilisateur de joindre un document à tout document envoyé centralement. La gestion automatisée des courriers dépendra également d une digitalisation optimale des documents entrants. 9. Coperfin 2.0 Le fonctionnement global et actuel de l application devra également être adapté aux nouveaux processus business en cours d implémentation ainsi qu à la future organisation par groupe cible des administrations fiscales (Particuliers, PME et Grandes entreprises) 10. Intégration d un système de gestion de gestion de rules Ce système de gestion de gestion de rules offrirait la possibilité au business de gérer lui-même la mise en œuvre des filtres (voir description fonctionnelle) tant en terme d activation de contenu et suivi mais également de pour voir piloter sans intervention du développement le process de workflow (exemple d outil : Business Rules Management systems ILOG) Evolution technique 1. Modes dégradés et disponibilité Les nouvelles intégrations avec les applications extérieures devront d emblée proposer un mode dégradé pour éviter des pertes de disponibilité. 2. Dépendances structurelles techniques a) FUP-ITIL (gain de temps) Passer Taxi dans FUP-ITIL nous permettra de gagner du temps pour les intégrations acceptance, diminuant ainsi les temps de latence pendant les périodes de préparation pour les PDS et le lancement des portails. b) Data and data structure management (gain de temps) Certaines requêtes telles que des créations de vues ne sont pas toujours indispensables. Il faut analyser ce qui n est pas indispensable et supprimer ces demandes de delivery management (à remplacer par une meilleure architecture logicielle). Restores acceptance : il s agirait de créer des subset et/ou des procédures automatiques pour remplir l acceptance avec des data permettant les tests d intégration et fonctionnels de taxi. Organisation de la taille DB (gain d espace) : Il s agit de faire un cadastre des tables directement utilisées par taxi et d autres qui doivent absolument rester online pour permettre un archivage annuel et ainsi un contrôle de l espace occupé.

160 Cahier des charges S&L/AO/386/ /217 IV. Proposition de Déclaration Simplifiée (PDS) a. Description fonctionnelle Pour l exercice d imposition 2010, un projet pilote a été mené par le SPF Finances afin d envoyer une proposition de déclaration simplifiée de manière ciblée à un nombre limité de contribuables soumis à l impôt des personnes physiques (IPP). Via ce projet pilote, près de 5000 propositions de déclaration simplifiée ont donc été envoyées directement aux citoyens sans que ceux-ci doivent intervenir. Lors de l exercice 2011, le SPF Finances a étendu ce projet pilote et augmenté de manière conséquente le groupe cible ( déclarations). Outre ces déclarations PDS, déclarations de type 9A ont été générées. Lors de l exercice 2012, le groupe cible avait été étendu, et le retour d expérience de 2011 sur le préremplissage intégré. Cela a permis d envoyer environ PDS et d avoir un retour très faible avec un taux de +- 5 %. Les développements entrepris pour la Proposition de Déclaration Simplifiée (PDS) en 2012 ont été réalisés avec le souci de permettre une éventuelle extension. Le cadre applicatif de base est conçu pour supporter un élargissement du groupe cible. Ce cadre technique est un élément important et ne devrait pas restreindre les différentes évolutions puisque la définition d un nouveau groupe cible peut être facilement intégrée. Pour l exercice 2013, le groupe cible a été étendu aux contribuables bénéficiant de revenus compris dans des rentes viagères (codes 1158/2158 et 1159/2159) et/ou ayant effectué des libéralités (codes 1393/2393 et 1394) : ces codes sont présents dans BOW, cette extension concerne environ pds supplémentaires. Des nouveautés sont apparues : - impression de l'identité des personnes à charge sur la pds - visualisation de l'identité des personnes à charge dans Taxi - visualisation de l'identité des personnes à charge dans TOW - détermination des personnes à charge : exploitation des informations transmises par les cpas pour déterminer les ressources des membres du ménage (codes intégrés dans BOW en 2013, exploitables en 2014) - scannage des pds renvoyées aux services de taxation par les contribuables + archivage dans Taxi et dans myminfin - migration technique de AJ vers l'entité P liée à Sitran - sur base de l identité fiscale, il est prévu de générer le fichier imprimeur. b. Cycle de vie recurrent L application pour les propositions a été réalisée pour fonctionner de manière multi-exercices. Cependant quelques adaptations sont nécessaires pour fonctionner correctement à chaque nouvel exercice d imposition: Mettre à jour certaines propriétés Configurer les différents filtres avec les bonnes valeurs (codes de la déclaration supportées, exclus,...) Retester l ensemble de la chaîne

161 Cahier des charges S&L/AO/386/ /217 c. Indications quant à la future maintenance évolutive En 2014, le SPF Finances pourrait encore étendre ce projet et augmenter le groupe cible. Cependant l extension du groupe demande de pré- remplir un nombre croissants de champs. La récupération de ces données demande des modifications des programmes existants. Le présent projet a donc pour but d augmenter la portée du groupe cible et d améliorer l automatisation des processus liés à la proposition de déclaration simplifiée. De manière plus globale, il faut également prendre en compte tous les efforts entrepris pour inciter le citoyen à souscrire une déclaration de manière électronique par ses propres moyens. L élargissement de la PDS doit idéalement s intégrer dans les démarches entreprises pour élargir le cadre de TOW en orientant les développements pour qu ils soient profitables aux deux applications. Cette combinaison pourrait conduire à une réduction importante de la diffusion des déclarations papier destinées à être scannées. Parallèlement à l aspect technique, l élargissement du groupe sera vraisemblablement influencé par les données qui sont actuellement en notre possession puisqu elles impactent la couverture éventuelle d une autre catégorie de contribuables. A priori, il n est pas aisé d affirmer que nous disposons de suffisamment d informations pour diffuser une proposition de qualité à d autres catégories de contribuables que celle visée initialement, à savoir, les pensionnés. En effet, l orientation initiale vers le groupe des pensionnés ne sollicitait qu un nombre limité d éléments, on peut facilement imaginer qu une orientation vers une autre catégorie nécessitera de disposer de plus d informations. La maintenance évolutive consiste à réaliser des modifications fonctionnelles de l application existante. Les différentes modifications nécessaires sont basées d une part sur la volonté d étendre le groupe cible et sur la pérennisation du processus dans le temps. L extension du groupe cible peut nécessiter des modifications de l application : L augmentation du nombre de déclarations qui doivent être envoyées sur la même période de temps implique des optimisations des processus afin de pouvoir supporter la cadence. Certaines extensions du groupe nécessitent des adaptations en termes de pré- remplissage de la déclaration (par exemple les revenus immobiliers). L extension aux salariés ajouterait propositions de déclarations simplifiées, cela signifie un doublement du volume. Or l ensemble des déclarations doit être envoyé dans une fenêtre de temps restreinte. Afin d atteindre un nombre de de propositions (nombre actuel + les salariés), il faut revoir les processus de la chaîne afin d accélérer la cadence. Il s agit des process PDS eux-mêmes mais également des process Taxi qui injectent les déclarations et les calculent.

162 Cahier des charges S&L/AO/386/ /217 V. Calculatrix (Calcul IPP) a. Description fonctionnelle Deux modes L application Calcul IPP est développée en Java. Elle calcule l Impôt des Personnes Physiques, résidentes et non résidentes, en mode batch et en mode web. En mode web, l utilisateur souhaite obtenir un calcul d impôt en fonction des données qu il introduit. Le mode web est emprunté par Tax-on-web, Tax-calc, Taxi et WebCalculation. L output est constitué d une note de calcul, éditée à l écran et imprimable localement. Cette note de calcul comprend le détail du calcul de l impôt. Le mode batch s exécute de manière automatique : toute déclaration d impôt valide introduite dans Taxi est calculée par le système. Le résultat est stocké dans une base de données DB2. Régulièrement, Taxi sélectionne pour enrôlement un ensemble de déclarations ainsi pré-calculées. L application Calcul IPP assure alors la majeure partie de l enrôlement. Dans ce cadre, elle produit deux outputs principaux : le fichier d édition de l avertissement-extrait de rôle (AER) et le fichier pour l ICPC, c est-à-dire l Administration Générale de la Perception et du Recouvrement (AGPR). L AER comprend non seulement la note de calcul précitée, mais également les données d identification du contribuable (issues de Sitran), des services compétents (issues d Annucomp) ainsi que les données propres à l enrôlement (article de rôle, date d exécutoire, etc ). Cet AER est stocké au format.pdf dans FileNet (accessible via MyMinFin et Taxi). En outre, il est soit imprimé et envoyé au contribuable par FedoPress, soit mis à sa disposition via Zoomit. Le fichier pour l ICPC contient toutes les données nécessaires à l AGPR pour procéder au recouvrement de l impôt ou à son remboursement. Le système ICPC fonctionne en Cobol. Les données issues de l application Calcul IPP (Java/DB2) sont donc traduites dans ce langage. Trois modules L application Calcul IPP comporte trois modules : la Validation, le Calcul proprement dit et l Edition. La Validation consiste en un ensemble de règles qui veillent à ce que les données soumises pour calcul ne comportent aucune erreur vis-à-vis des dispositions fiscales existantes. En mode web, la Validation informe l utilisateur de son erreur et empêche l enregistrement des données tant que l erreur n est pas corrigée. En mode bacth, la Validation intervient aussi, principalement lorsqu il s agit d une déclaration scannée. Celle-ci n a en effet pas bénéficié d une validation poussée avant son introduction dans Taxi. Le Calcul proprement dit effectue le calcul de l impôt sur base des données validées. Aucune erreur technique n est donc susceptible de se produire. Enfin, l Edition édite la note de calcul à l écran et génère le fichier d édition pour stockage dans FileNet et son envoi à FedoPress. Elle génère également le fichier pour l ICPC.

163 Cahier des charges S&L/AO/386/ /217 b. Cycle de vie recurrent Le business lié au calcul de l impôt est fondamentalement annuel : la législation fiscale s applique en effet par année (exercice d imposition). Il s ensuit qu une application Calcul IPP complète doit être livrée chaque année. En outre, cinq applications coexistent en permanence : celle de l exercice d imposition en cours et celles des quatre exercices d imposition précédents. A chaque exercice d imposition, le gouvernement modifie ou supprime des règles existantes ou en invente des nouvelles. Les analystes business traduisent les textes de loi en analyses. Ces analyses sont enregistrées sur Caliber RM et sur StarTeam. Leur structure en arbre reflète fidèlement la structure du Code des impôts. Chaque analyse est appelée «opération». Chaque opération est décrite suivant un modèle. Ce modèle comprend, outre la description synthétique en langage naturel du traitement à effectuer, la liste des inputs et des outputs de l opération, ainsi que son algorithme, dans un langage mathématicopseudo Java. Si bien que le développeur Java est capable d implémenter le traitement désiré directement sur base de cette analyse. Chaque analyse fait l objet d une quality review par un autre analyste. Il en va de même de l implémentation. Chaque modification est testée au moyen de tests unitaires («white tests») et de tests complets, qui exécutent des calculs du début à la fin («grey tests»). Ces batteries de tests sont exécutées de manière automatique avec les outils HP ALM et Quick Test Pro, fortement customisés pour les besoin de l application.

164 Cahier des charges S&L/AO/386/ /217 c. Indications quant à la future maintenance évolutive Au niveau business A partir de l exercice d imposition 2015, la régionalisation de l impôt des personnes physiques se développe considérablement. L application Calcul IPP en est fortement impactée. Non seulement pour l exercice d imposition 2015 mais également pour les exercices d imposition suivants. Le SPF Finances reçoit déjà actuellement des demandes d avis des régions sur la faisabilité technique de mesures qu elles envisagent de prendre à partir de l exercice d imposition Cela va inévitablement augmenter la charge de travail puisque, désormais, quatre pouvoirs sont susceptibles d adopter des mesures impactant le calcul de l impôt : le fédéral et les trois régions. Et cette charge de travail supplémentaire va être engendrée non seulement par l augmentation du nombre de mesures mais également par la complexité croissante qu elles vont induire dans le programme de calcul. Au niveau ICT L application calcul IPP est dépendante de Java, DB2, Weblogic, Annucomp, Sitran, Caliber, HP ALM, Quick Test, Jenkins, etc Chacune de ces applications et composantes est susceptible d évoluer, de faire l objet de mises à jour. A chaque fois, il convient d adapter l application calcul IPP pour qu elle continue à fonctionner. Ces adaptations doit être répercutées plusieurs fois : sur l application liée à chaque exercice d imposition ainsi que sur celles relatives aux exercices d impositions précédents.

165 Cahier des charges S&L/AO/386/ /217 Lot 3 (Domaine impôts directs personnes morales + transversales Ag Fisc) Biztax (Stiron lot 1) : Module Font-Office (FO) Biztax (Stiron lot 1) : Modules Back-Office (BO) et Dossier Unique (DU) CalcIsoc Stir-Contrôle Stir-Recherche PRM-on-web I. Biztax Front-Office (Biztax FO) a. Description fonctionnelle 1. Généralités L application BIZTAX frontoffice a été lancée en mai Cette application offre aux utilisateurs externes entreprises, asbl et leurs mandataires la possibilité d introduire leur déclaration à l impôt des sociétés, des non-résidents, et des personnes morales par voie électronique. Il est même envisagé de rendre la déclaration électronique obligatoire. L utilisateur peut remplir en ligne aussi bien le formulaire de déclaration que tous les formulaires annexes (relevés et déclarations). Les données relatives à ces formulaires sont reprises dans une taxonomie XBRL modifiée chaque année. Les éléments et la structure déterminés dans cette taxonomie XBRL sont traduits par l application en écrans à remplir. Sur ces écrans, l utilisateur peut introduire non seulement des données structurées mais aussi ajouter des PDF pour les annexes pour lesquelles aucun modèle n a été élaboré. Les données remplies sont conservées de manière centralisée de sorte que l utilisateur peut revenir plus tard sur sa déclaration pour la modifier ou continuer à la remplir. Il est possible d effectuer un contrôle des erreurs à n importe quel moment. Le calcul de l impôt dû ou à rembourser est également possible. Le module de simulation ne fait pas partie du présent marché. Les déclarations générées par un logiciel externe peuvent être facilement téléchargées dans BIZTAX, par maximum 25 à la fois, via un fichier "biztax". Ici aussi, il doit être satisfait à une série de contrôles techniques et de contenu. Après introduction de la déclaration, l'utilisateur peut consulter l accusé de réception, la preuve de la signature des déclarations chargées, les fichiers PDF de la déclaration (y compris tous les formulaires) et chaque annexe PDF jointe séparément à la déclaration. Les adaptations fiscales annuelles à ces déclarations pour les personnes morales ont un impact sur ces applications. Chaque année, une nouvelle version doit être élaborée qui soutient le nouvel exercice d imposition. Le BIZTAX frontoffice est une application externe dont le service ne peut pas être interrompu.

166 Cahier des charges S&L/AO/386/ /217 Pour l exercice d imposition 2011, plus de déclarations à l impôt des sociétés ont été introduites via BIZTAX. Depuis l exercice d imposition 2012, les déclarations peuvent être introduites via BIZTAX, non seulement à l impôt des sociétés (ISoc) mais également à l impôt des nonrésidents/sociétés (INR/soc) et à l impôt des personnes morales (IPM). Pour l'exercice d'imposition 2012, plus de déclarations ont été introduites via BIZTAX. Le nombre total de déclarations à introduire est d environ : Impôt des sociétés : Impôt des personnes morales : Impôt des non-résidents/sociétés : Chaque année, ce nombre augmente de 3% en moyenne. L application interne BIZTAX backoffice light permet aux agents contrôleurs et taxateurs internes de consulter les déclarations introduites via BIZTAX. Ils peuvent non seulement consulter la déclaration et ses annexes, mais aussi l'accusé de réception reçu par l'utilisateur. BIZTAX backoffice light n est plus utilisé que pour les exercices d imposition 2011 à 2013 compris. Les déclarations et les annexes introduites dans ces trois types d impôt doivent être traitées par le backoffice. Les déclarations introduites par voie électronique sont transférées, jusqu à l exercice d imposition 2013 compris, vers le backoffice actuel CVVEN pour traitement ultérieur des déclarations. À cette fin, les données sont extraites des déclarations déposées, puis converties et envoyées au mainframe Bull. Là, elles sont traitées en batch par le backoffice. Le fichier personnes morales (PM) interne est également actualisé. Le transfert des déclarations vers le backoffice de BIZTAX ne fait pas partie du présent marché. L application est intégralement disponible dans les trois langues nationales, le français, le néerlandais et l allemand. L application doit être compatible avec les systèmes d exploitation et les navigateurs courants. BIZTAX frontoffice est accessible via le portail du SPF Finances. Une disponibilité (24h/24 et 7j/7) de l application est exigée. 2. Accès à l application Avant d avoir accès à l application BIZTAX, chaque utilisateur doit s authentifier. Cette authentification se fait à l aide d un certificat numérique. Ce certificat est intégré dans la carte d identité électronique belge (eid). L'utilisateur peut aussi utiliser des certificats émanant d une des autorités de certification suivantes: GlobalSign et Isabel. Toutes les déclarations générées et complétées restent modifiables tant que l utilisateur utilise la même eid ou le même certificat. L utilisateur peut consulter sa déclaration, son accusé de réception et les fichiers PDF de sa déclaration (y compris tous les formulaires) et toutes ses annexes. Ce qui précède n est cependant pas possible en cas d utilisation du système de gestion des accès et des mandats FedIAM. Dans ce cas, les dossiers sont accessibles aux utilisateurs considérés comme des représentants légaux, des mandataires ou des représentants d un mandataire. 3. Remplissage en ligne des déclarations 3.1. Recherche Des critères de recherche peuvent être introduits sur l'écran de recherche pour rechercher une déclaration précise. En cas d introduction de valeurs incorrectes dans un champ, une icône d erreur s affiche au-dessus du champ concerné et si des erreurs ont été faites au niveau de plusieurs champs, l icône d erreur s'affiche en haut de l'écran après avoir cliqué sur le bouton "Chercher déclarations". Pour que l action de recherche puisse s exécuter, il faut que les champs soient correctement remplis.

167 Cahier des charges S&L/AO/386/ /217 Après le lancement d une recherche, l utilisateur voit s afficher à l écran une liste des déclarations trouvées. Si la liste est trop longue, elle est scindée et s affiche sur plusieurs pages. La liste peut être triée sur chaque colonne en cliquant sur le titre de la colonne. Si une action de recherche ne donne aucun résultat, un message indiquant qu aucune déclaration n a pu être trouvée s affiche à l écran. Si l utilisateur souhaite ouvrir une déclaration précise, il lui suffit de la sélectionner dans le tableau des résultats et d ensuite cliquer sur le bouton Ouvrir déclaration. En utilisant le bouton "Download XLS", l utilisateur peut télécharger la liste des résultats affichée à l'écran sous la forme d'un fichier Excel. Si l utilisateur n a pas trouvé la déclaration qu il cherchait, il peut créer une nouvelle déclaration en cliquant sur le bouton Créer autre déclaration. En cliquant sur ce bouton, l utilisateur est redirigé vers l écran "Créer autre déclaration". Ce bouton n est visible pour l utilisateur qu après une action de recherche. Si une des valeurs complétées lors de la création de la déclaration n est pas correcte, par exemple la date de début de la période imposable, la déclaration peut être supprimée. Par la suite, une nouvelle déclaration peut être créée avec des données correctes. Ce qui précède est adapté lorsqu il est fait usage du système de gestion des accès et des mandats FedIAM. Dans ce cas, les dossiers seront accessibles aux utilisateurs considérés comme des représentants légaux, des mandataires ou des représentants d un mandataire. Un moteur de recherche adapté offre les deux possibilités de sélection en tenant compte des informations disponibles à partir du système des mandats. Les autres fonctionnalités restent inchangées Remplissage La déclaration peut être remplie par étape, en utilisant les différents onglets qui abritent les données signalétiques, la déclaration et les annexes. Les données signalétiques et certaines données fiscales liées au numéro d entreprise sont déjà disponibles et sont préremplies dans la déclaration. Les données remplies sont sauvegardées centralement, de sorte à permettre à l utilisateur de modifier ou finaliser sa déclaration. L écran de remplissage de la déclaration comprend, outre un menu déroulant, quatre parties distinctes: les informations contextuelles de l entreprise, la barre de navigation des onglets, les boutons correspondants à des fonctionnalités spécifiques et les champs à remplir du formulaire de déclaration et des formulaires annexes scindés en onglets. Chaque bouton est lié à une fonctionnalité distincte. Le bouton "Enregistrer" permet d enregistrer temporairement une déclaration (partiellement) remplie. Quand on passe d un onglet ou d un menu à un autre, la déclaration est automatiquement temporairement enregistrée. Le bouton "Liste des erreurs" redirige l utilisateur vers la liste des erreurs de la déclaration en cours et l endroit à partir duquel il peut lancer le contrôle des erreurs. Lorsque l utilisateur clique sur le bouton "Vider", après une demande de confirmation, tous les champs de la déclaration sont entièrement vidés (les données de l entreprise dans l onglet Id seront à nouveau remplis comme en cas de création d une nouvelle déclaration). Le bouton "Ouvrir le document PDF" permet d ouvrir une déclaration déjà (partiellement) remplie dans un document en format PDF. Ce document PDF est généré dans la langue utilisée à ce moment dans l application. Les champs à remplir du formulaire de déclaration et des formulaires annexes regroupés sous différents onglets et dans lesquels l utilisateur peut saisir des chiffres et du texte et qui servent également à joindre des annexes en format PDF. Dans certains champs, l utilisateur doit introduire des montants. Sous peine de générer l apparition de messages d erreur à l'écran, ces montants doivent toujours satisfaire à certaines règles. Le montants sont, par exemple, limités à 14 chiffres et deux décimales. Les totaux des champs (entourés en orange) sont calculés et remplis automatiquement. Dans certains tableaux, on trouve un bouton "Ajouter une ligne". Il sert à ajouter une ligne dans le tableau, qui doit être remplie avec les données correctes. Un tableau n est donc pas limité à un nombre fixe de lignes. Un nombre limité d'annexes non standardisées pouvant être jointes à la déclaration a également été prévu pour lesquelles un fichier PDF peut être chargé en cliquant sur le bouton "Ajouter". Quand l'utilisateur clique sur ce bouton, un écran pop-up apparaît dans lequel l utilisateur peut sélectionner

168 Cahier des charges S&L/AO/386/ /217 l annexe qu il souhaite ajouter à sa déclaration. Une fois l annexe ajoutée, l utilisateur peut l ouvrir en utilisant le bouton "Ouvrir" ou la supprimer de la déclaration en utilisant le bouton "Effacer. Quand une annexe est ajoutée, le bouton "Ajouter devient indisponible; quand aucune annexe n est ajoutée, les boutons "Effacer" et "Ouvrir" sont indisponibles Valider Un contrôle des erreurs peut être effectué à n'importe quel moment. Le contrôle des erreurs comprend une série de contrôles techniques et une série de règles de validation de contenu intégrées dans la taxonomie XBRL et de contrôles contenus dans le module externe Calculatrix. L intégration de ce module externe Calculatrix fait partie du présent marché, ce qui n est pas le cas de son développement. Un ordre chronologique fixe d exécution des règles de validation a été défini. Certaines règles donnent lieu à l envoi d un statut "bloqué". Lorsque c'est le cas, l'utilisateur ne peut plus rien corriger et la déclaration est automatiquement vidée. Lorsque c est possible, un lien est établi entre le message d erreur de la liste des erreurs et le champ concerné par l'erreur. Les champs entachés d une erreur sont marqués et une fenêtre contenant le message d erreur s affiche sur les écrans de remplissage Simuler Quand la déclaration se voit attribuer le statut "Sans erreurs" ou "Souscrite" l utilisateur peut demander une simulation d impôt. Cette simulation d impôt lui fournit une indication sur le montant estimé de l impôt. L écran de résultat comprend le montant d impôt estimé correspondant à la déclaration effectuée et une icône PDF qui permet de visualiser le calcul détaillé de cette simulation en format PDF. La simulation fait partie de l application distincte Calculatrix. Seule l intégration de la simulation fait partie du présent marché Signer Quand la déclaration obtient le statut "Sans erreurs", elle peut être signée via le sous-menu "Souscrire". Après avoir été signée, la déclaration est introduite et il n'est plus possible de la modifier dans BIZTAX. Pour cette souscription, le système utilise une signature PDF basée sur la technologie Adobe LiveCycle. Après avoir été signée, la déclaration reçoit le statut "Souscrite" et elle ne peut plus être modifiée dans BIZTAX. Dès que la nouvelle application interne de traitement des déclarations sera mise en production, il sera possible d'introduire des déclarations rectificatives Consulter Après la signature de la déclaration, plusieurs documents peuvent être consultés en utilisant le sousmenu "Documents de la déclaration". Plusieurs documents peuvent être consultés: toutes les annexes chargées pendant l introduction de la déclaration en tant que documents PDF, l accusé de réception sous forme de PDF avec la signature numérique du SPF Finances comme preuve de l'introduction de la déclaration, la déclaration complète (formulaire de déclaration et annexes) sous la forme d un document PDF avec la signature de l'utilisateur sur la déclaration remplie en ligne, le document XBRL de la déclaration et pour les déclarations chargées, la preuve PDF de l introduction de la déclaration avec la signature numérique de l'utilisateur. L'utilisateur peut sélectionner le document qu il veut consulter. Par défaut, le système sélectionne le premier document de la liste. Si l'utilisateur clique ensuite sur le bouton Ouvrir, un écran pop-up apparaît à partir duquel l'utilisateur peut choisir d ouvrir le document ou de le sauvegarder localement.

169 Cahier des charges S&L/AO/386/ / Charger les déclarations Outre la création et le remplissage en ligne de sa déclaration, l'utilisateur peut aussi charger directement dans l application un fichier qui contient une ou plusieurs déclarations. Ce fichier est enregistré localement avec l extension ".biztax" et peut contenir une ou plusieurs déclarations concernant différents exercices d imposition ou différents types d impôts Exigences Ces fichiers doivent satisfaire à une série d exigences techniques : Exigences : structure, format XML, UTF-8, etc. Maximum 25 déclarations par fichier Maximum 6 annexes PDF par déclaration Taille maximum de chaque déclaration de 15 MB Après son chargement, le fichier "biztax" subit une première validation sous la forme de contrôles techniques. C est ainsi, entre autres, que le système vérifie si le fichier chargé est techniquement correct et si chacune des entreprises pour lesquelles une déclaration a été chargée est en droit d introduire une déclaration. Si une des déclarations du fichier chargé est considérée comme non correcte après ces contrôles techniques, l ensemble des fichiers chargés est considéré comme non valide et toutes les déclarations contenues dans le fichier sont rejetées Contrôles spécifiques Un fichier ayant passé avec succès cette première validation peut être signé par l utilisateur. L'utilisateur reçoit un PDF qui reprend les numéros d entreprise, les exercices d imposition et les dates de fin de la période imposable des déclarations chargées qu il doit signer et envoyer. Avant de signer définitivement les déclarations du fichier, un premier contrôle de contenu est effectué pour chaque déclaration afin de vérifier si les données qu elle contient sont correctes. Chaque déclaration doit passer par plusieurs étapes et les contrôles peuvent se faire de manière totalement ou partiellement asynchrone. Aperçu schématisé des contrôles : Si aucune erreur n est constatée, la déclaration est signée. Si des erreurs sont trouvées dans une des déclarations du fichier chargé, un message d'erreur s'affiche dans l'aperçu des déclarations chargées.

170 Cahier des charges S&L/AO/386/ /217 Les différents statuts pouvant être attribués à un fichier "biztax" chargé sont : En traitement : les déclarations sont contrôlées au niveau des erreurs de contenu. Annulé : le fichier "BIZTAX" contient une erreur qui entraîne le rejet de l ensemble du fichier et aucune déclaration n est souscrite. Traité : ce chargement a bien été accepté, les déclarations sans erreurs sont souscrites et les déclarations qui contiennent encore des erreurs de contenu ne sont pas souscrites Souscription La souscription se fait par le biais de la signature d'un fichier PDF en utilisant la technologie Adobe LiveCycle. En l absence d erreurs, la déclaration peut être souscrite. Si des erreurs ont été trouvées dans une des déclarations du fichier chargé, un message d erreur apparaît dans l aperçu des déclarations chargées. L'utilisateur peut rechercher la déclaration non signée via "Chercher déclarations", ouvrir les déclarations concernées en utilisant «Ouvrir» et retrouver l erreur en naviguant dans la "Liste des erreurs" Consulter les fichiers chargés Une fois la déclaration signée, l'utilisateur peut aussi consulter les documents de déclaration de sa déclaration et demander une simulation d impôt. Le remplissage en ligne peut aussi toujours être ouvert, mais l utilisateur ne peut plus rien modifier. Pour chaque paquet chargé, aussi bien avec succès qu avec des erreurs, l'utilisateur peut consulter un écran récapitulatif a posteriori. Cet écran récapitulatif est le dernier écran que l'utilisateur a vu lors du chargement de ses déclarations. Pour cela, il doit sélectionner le chargement qu il souhaite consulter sur l écran de chargement et cliquer sur le bouton "Détails". Les différents statuts qui peuvent être attribués à un fichier biztax" chargé sont les suivants: En traitement: les déclarations sont contrôlées par rapport aux erreurs de contenu. Annulé : le fichier "BIZTAX" contient une erreur qui entraîne le rejet de l ensemble du fichier et aucune déclaration n est souscrite. Traité : ce chargement a bien été accepté, les déclarations sans erreurs sont souscrites et les déclarations qui contiennent encore des erreurs de contenu ne sont pas souscrites. Une déclaration chargée qui contient encore des erreurs de contenu, rechargée par la suite, ne peut plus être reprise dans la liste des déclarations chargées dans le fichier «biztax» précédent. Les déclarations ne sont reprises que dans le fichier dans lequel elles ont été chargées pour la dernière fois. b. Cycle de vie récurrent Pour la version adaptée au nouvel exercice d imposition, il est fait appel à une aide externe pour un accompagnement au niveau de la gestion des environnements et du roll-out; des tâches dont l exécution sera de plus en plus confiée à l équipe ICT du SPF Finances. Il est demandé au partenaire externe de proposer des activités de support et de coaching à cet effet. Des développements complémentaires pourront être réalisés s ils s avèrent nécessaires à la mise en production de la nouvelle version de l application. Un aide externe est également demandée pendant la période de production au cas où des problèmes concernant le fonctionnement de l application ou des pannes se produiraient. Des développements pourront être confiés au consultant externe s ils s avèrent indispensables pour assurer le bon fonctionnement et le fonctionnement correct de l application. Voici un aperçu des tâches annuelles récurrentes.

171 Cahier des charges S&L/AO/386/ / Adaptations liées à l exercice d imposition Chaque année, des changements au niveau de la fiscalité et la mise en place d un nouvel exercice d imposition imposent des modifications. Pour chaque exercice d imposition, il existe des déclarations adaptées y compris leurs annexes. BIZTAX utilise la technologie XBRL (extensible Business Reporting Language). Les changements fiscaux annuels sont traduits dans une taxonomie XBRL unique, spécifique à chaque exercice d imposition qui contient les trois déclarations et toutes leurs annexes. Une taxonomie XBRL reste active pendant minimum trois ans. La taxonomie XBRL est développée par le SPF Finances. Aperçu schématisé de l architecture de la taxonomie XBRL: Les précédentes versions de la taxonomie XBRL, y compris la documentation s y rapportant sont consultables sur le site à la page «publications techniques» ( La majorité des fonctionnalités de l application sont directement adaptées au moment du chargement d une nouvelle taxonomie XBRL mais certaines exigent toutefois une adaptation des codes. Il faut, au minimum, adapter les fonctionnalités suivantes de l application : Écrans de recherche Chargement des déclarations Création des déclarations Écrans de saisie Validation des déclarations Visualisation des messages d erreur Lien vers Calculatrix pour l exécution de certains contrôles et pour une simulation

172 Cahier des charges S&L/AO/386/ /217 Les écrans sur lesquels l'utilisateur peut remplir manuellement sa déclaration sont générés à partir de cette taxonomie XBRL et le nouvel exercice d imposition est automatiquement intégré dans les nouveaux écrans de recherche. Pour cela, on utilise toutes les composantes existantes de la taxonomie XBRL: presentation linkbases, definition linkbases (y compris presentation hypercubes), label linkbases et les formula linkbases pour les totaux. À côté de cela, on utilise aussi un fichier XML contenant des paramètres, un table analyser, un Xpath generator et un XForms generator. Le lien avec les messages d erreur et leur affichage sont également liés à ce point. Présentation schématique de la génération des écrans : Présentation schématique de l utilisation des formula linkbases pour les totaux dans les écrans de saisie : Mise à jour de la taxonomie XBRL La taxonomie XBRL est développée et adaptée par le SPF Finances. Dans le but de pouvoir conserver certaines fonctionnalités existantes, les adaptations à la taxonomie XBRL peuvent toutefois exiger de devoir faire appel à une aide. Les modifications architecturales ne sont pas prévues, mais une adaptation majeure de la déclaration ou de ses annexes liée à un exercice d imposition peut entraîner l ajout d un nouveau schéma ou d un nouvel aspect technique qui requièrent des adaptations de l application. Dans ce cas, pour pouvoir conserver les fonctionnalités existantes et intégrer le nouveau schéma ou le nouvel aspect technique, des adaptations de l application peuvent également exiger de faire appel à une aide. 2. Gestion des environnements et déploiement (roll-out) L application doit fonctionner dans différents environnements y compris la mise en production dans l'environnement de production. Plusieurs installations dans l environnement d acceptation pourront être exigées avant que l application ne soit mise en production. L installation de l application se fera via l application standard du SPF Finances et conformément à FUP-ITIL.

173 Cahier des charges S&L/AO/386/ / Corrections techniques et fonctionnelles nécessaires qui ont un effet sur le fonctionnement de l application après l exécution des tests BIZTAX est une application externe utilisée par environ utilisateurs. Chaque année des adaptations doivent y être apportées pour en garantir le bon fonctionnement en tenant compte des changements intervenus sur le marché (OS, navigateurs, javascripts, etc.). 4. Adaptations nécessaires en raison de modifications des standards ICT BIZTAX doit toujours être conforme aux standards ICT. Pour pouvoir le garantir, chaque année, des adaptations doivent être effectuées. 5. Suivi du fonctionnement de l application et aide, y compris au niveau du diagnostic et de l implémentation des corrections à l application, en cas de problèmes après sa mise en production. BIZTAX frontoffice est une application externe dont le service ne peut pas être interrompu. La nondisponibilité de ces applications dans la version exercice d imposition 2013 peut mettre en péril le bon fonctionnement du SPF Finances et plus particulièrement de l AG de la Fiscalité et qui plus est considérablement nuire à son image. L'aide externe demandée doit garantir non seulement le suivi du fonctionnement de l application, mais aussi le support en cas de constatation ultérieure de manquements qui mettent en péril le bon fonctionnement de l application. 6. Services à fournir Pour chacun des aspects mentionnés plus haut, les services suivants doivent être fournis: Analyse fonctionnelle : adaptation des documents d analyse fonctionnelle et surtout aide fonctionnelle aux développeurs dans le cadre des développements à exécuter Architecture, analyse technique, développement et déploiement : un architecte technique adapte les analyses techniques le cas échéant et soutient les développeurs dans l implémentation de ces adaptations. Les adaptations annuelles n exigent, en principe, aucune modification de l architecture. Il faut prévoir la gestion des environnements et le déploiement avant la mise en production de l application dans les différents environnements (développement, acceptation et production). Documentation et transfert de connaissances: la documentation technique doit être actualisée et un transfert de connaissances doit avoir lieu à destination des collaborateurs concernés du SPF Finances. La documentation fonctionnelle (manuel utilisateur, FAQ, vidéos d instructions et présentations) ne fait pas partie du présent marché. Gestion de projet: quatre groupes de pilotage maximum seront organisés par an pour assurer le suivi du projet. Le groupe de pilotage suit l avancement des services à fournir et surveille la coordination avec les autres applications et composantes utilisées par BIZTAX. Du début des analyses à la mise en production comprise, des réunions de suivi doivent être organisées toutes les semaines ou toutes les deux semaines pour suivre l'avancement et pouvoir faire des corrections ou informer le groupe de pilotage des problèmes et des nouveaux risques dans le cadre de la procédure d'escalade prévue. Méthodologie: Le SPF Finances utilise Prince2 et FUP-ITIL. Les produits existants doivent être adaptés dans leur forme actuelle. c. Indications quant à la future maintenance évolutive

174 Cahier des charges S&L/AO/386/ /217 Si des évolutions fonctionnelles s avèrent nécessaires, elles seront identifiées d une part sur la base du feedback des utilisateurs de ces applications et des questions fréquemment posées au Contact Center et aux business experts de deuxième ligne qui représentent une charge importante de travail, et d autre part en fonction des facteurs environnementaux en mutation auxquels l application doit être adaptée. Des évolutions techniques peuvent s avérer nécessaires si des adaptations sont apportées aux standards ICT. Une provision pour les nouveaux travaux est demandée. La priorisation et la nécessité de nouveaux travaux seront validées au cas par cas par le chef de projet et le groupe de pilotage. Voici quelques évolutions attendues : Améliorations dans chacune des fonctionnalités existantes en cas de demande suffisante de la part de l'utilisateur. Cela peut aller de l ajout de boutons à l'extension effective de la fonctionnalité existante. Rendre possible la consultation des données du dossier fiscal de BIZTAX BO (avertissementextrait de rôle, correspondance, statut du dossier, ) par les utilisateurs dans l attente d une intégration dans MyMinfinPro pour les entreprises Intégration des demandes d attestations fiscales qui ressortissent à la compétence des services de taxation ISoc, INR/soc et IPM.

175 Cahier des charges S&L/AO/386/ /217 II. Biztax Back-Office et Dossier unique (Biztax BO) d. Description fonctionnelle BizTax Backoffice permet aux services de taxation de gérer les déclarations à l impôt des sociétés, l impôt des personnes physiques et l impôt des non-résidents/sociétés. Sur la base du planning actuel, le nouveau backoffice sera opérationnel le 1er mars 2014 et pourra traiter les déclarations à partir de l'exercice d imposition Les déclarations à l impôt des sociétés, l impôt des personnes physiques et l impôt des nonrésidents/sociétés sont introduites par voie électronique par les contribuables ou leurs mandataires via l application BizTax Frontoffice. Seul un nombre limité de déclarations sont encore déposées sur papier. Les déclarations introduites électroniquement sont ensuite transférées vers le backoffice actuel, CVVen 11 pour finalement déboucher sur l envoi de l avertissement-extrait de rôle au contribuable. Le projet BizTax Backoffice a pour objectif de renouveler complètement le backoffice existant et de l élargir. Son renouvellement s imposait du fait que le backoffice existant est technologiquement dépassé et que de nouvelles fonctionnalités s avèrent nécessaires. 1. Fonctionnalités BizTax Backoffice comprend les fonctionnalités suivantes: 1. Les déclarations introduites via BizTax Frontoffice sont automatiquement transférées vers BizTax Backoffice. 2. Les déclarations introduites sur papier peuvent être introduites par le gestionnaire de dossier via BizTax Backoffice; pour les annexes sur papier, un formulaire scan peut être créé pour que les annexes puissent être jointes au formulaire de déclaration sous forme électronique. 3. Les déclarations, introduites par voie électronique par le contribuable ou par le gestionnaire de dossier, sont vérifiées par rapport à une série de règles de validation. Ces règles de validation se trouvent d une part dans la taxonomie XBRL (cf. infra), et d autre part dans l'application externe Calculatrix. Exemples de validations possibles: - La déclaration est tardive; - La déclaration comporte un tarif spécifique ou des éléments qui rendent le calcul automatique de l impôt impossible; - plusieurs déclarations ont la même date de bilan; - la déclaration a été introduite à une date de bilan inconnue dans le Dossier unique; - la langue de la déclaration ne correspond pas à la langue reprise dans le Dossier unique; - les chiffres de la déclaration dépassent les montants limites ou s écartent des tarifs fiscaux des exercices d imposition antérieurs; - la déclaration contient des erreurs (p. ex. le montant des versements anticipés ne correspond pas aux chiffres figurant dans le fichier de l'exercice d imposition). 4. Envoi de tâches vers l'application TaskManager. Si une déclaration présente des anomalies, suite au processus de validation lié à la taxonomie ou à Calculatrix, une tâche est créée dans 11 CVVen = Centrale Validatie Vennootschappen

176 Cahier des charges S&L/AO/386/ /217 l application TaskManager. Cette tâche doit être traitée par le gestionnaire de dossier avant que la déclaration ne puisse être enrôlée. Chaque tâche créée se voit attribuer une série de caractéristiques (p. ex. SLA, description, date d échéance, etc. selon les modalités définies dans l application TaskManager). 5. Lettres standards. La résolution des anomalies peut exiger l envoi de courriers. L application BizTax Backoffice devra disposer d une bibliothèque de lettres standards qui seront envoyées aux contribuables ou à des tiers. Certaines données contenues dans ces lettres seront déjà préremplies avec des valeurs par défaut (p. ex. le numéro d entreprise, l adresse, etc.). Une copie des courriers sortants sera conservée électroniquement et jointe aux déclarations et/ou au dossier permanent (voir plus loin). Le courrier entrant donne lieu à la création d un formulaire scan également joint à la déclaration et/ou au dossier permanent sous forme électronique. La conception technicofiscale des modèles (templates) et des règles de validation s y rapportant est analysée par l administration et mise à disposition pour implémentation. Exemples de courriers standards : - 279: Avis de rectification E1 : Avis de taxation d office E2 : Avis de taxation d office (avis 8 jours) E2V : Avis de taxation d office en matière de précompte - 279F1 : Amende administrative - 279F2 : Notification d une amende administrative - 279T : Communication de la position définitive de l'administration - 279V-279Pr : Avis de modification en matière de précomptes - 332: Demande de renseignements - 332ter : Demande de renseignements à des tiers - 332C : Renvoi de la déclaration pour défaut de forme - 440B : Invitation à se présenter au bureau - 440BI : Annonce d une visite sur place - Déclaration d accord ISoc IMP INR/Soc. - Demande de renseignements informelle - Lettre contenant seulement l en-tête et les coordonnées personnelles du gestionnaire de dossier - Déclaration d accord impôt des sociétés 6. Dossier permanent. Un dossier permanent électronique est conservé pour chaque contribuable. Un dossier permanent contient notamment une série de tableaux qui découlent de la taxonomie XBRL. Après validation des déclarations, ces tableaux sont actualisés sur la base des déclarations introduites ou des corrections ultérieures effectuées par le gestionnaire de dossier. Le dossier permanent peut aussi contenir de la correspondance concernant le contribuable qui n est pas liée à un exercice d imposition spécifique. Exemples de tableaux : - 276D : aperçu des augmentations d impôt et amendes administratives appliquées - 328D : tableau d origine du capital - 328R : tableau des réserves taxées - 328S : tableau des réserves exonérées - suivi des plus-values soumises à taxation étalée 276K1 7. Enrôlement. Après validation, si la déclaration ne contient plus d'erreurs, elle est déclarée prête à être enrôlée. Le calcul de l impôt dû, la création et l envoi de l avertissement-extrait de rôle sont assurés par une application distincte, à savoir Calculatrix. Ce processus ne fait donc pas partie du scope de l application BizTax Backoffice, mais il faut prévoir les interactions nécessaires. L ensemble du processus d enrôlement prend plusieurs semaines. Dans certains

177 Cahier des charges S&L/AO/386/ /217 cas, les services de taxation doivent toutefois procéder à un enrôlement urgent. Un modèle a été spécialement conçu à cet effet. 8. Module d octroi. Le chef de service des services de taxation dispose d un module spécifique qui lui permet de distribuer les tâches entre ses différents collaborateurs. Ce module lui permet aussi de connaître le pourcentage de tâches dont est responsable chacun d eux. 9. Listes. Des listes peuvent être générées pour chaque service de taxation qui donnent un aperçu de l avancement des activités du service et permettent dès lors de procéder à des ajustements le cas échéant. De plus, diverses listes peuvent aussi être générées au niveau des déclarations (introduite dans les délais prescrits, tardive, pas introduite, prescrite, etc.). Actuellement, huit listes sont définies qui rassemblent des données à partir de diverses bases de données (Sitran, Entités, BizTax Backoffice). Les données de ces listes sont actualisées tous les jours. Exemples de listes : - Listes basées sur les données enregistrées dans l Entité (3 listes) - Listes basées sur les données enregistrées dans l Exercice d imposition (5 listes) 10. Pour le service central, un module spécifique permet de gérer l enrôlement au niveau national. Ce module permet d exécuter l enrôlement en fonction de différents paramètres (p. ex. moment de l enrôlement, montant minimum ou maximum, etc.). 11. Liste imprimeur. Au niveau central, le backoffice doit générer un fichier qui permet à l imprimeur d envoyer les déclarations sur papier aux contribuables (nom, adresse, date limite, données de l expéditeur, etc.). 12. Base de données relationnelle. Les données des déclarations et le dossier permanent, conservés dans le format XBRL doivent être mis à la disposition d autres applications par le biais d une base de données relationnelle pour leur permettre de les utiliser dans le cadre de leur traitement ultérieur. 2. Gestion via les Entités et l Exercice d imposition Outre plusieurs modules spécifiques, BizTax Backoffice devra permettre de conserver, suivre et traiter différentes données aussi bien au niveau des entités qu au niveau de l exercice d imposition. L Entité est le lien indispensable entre les données signalétiques personnelles et les droits et les obligations fiscales et non fiscales qui en découlent. L entité est le point de liaison entre le volet données signalétiques personnelles et les autres volets du Dossier unique et notamment les données fiscales parmi lesquelles les données des déclarations, les données de contrôle et les données de perception et de recouvrement, les données patrimoniales et les données douanières. L entité représente l ensemble des droits et des obligations liés à un impôt, une taxe ou un droit acquis du SPF Finances. Il s agit d une ou de plusieurs Unités Personnes.

178 Cahier des charges S&L/AO/386/ /217 L Entité générique est complétée d'une série de données spécifiques à BizTax. L Entité contient une série de données qui s appliquent à des contribuables spécifiques sur plusieurs exercices d imposition (p. ex. date de bilan, langue, etc.) tandis que le volet Exercice d imposition contient des données spécifiques à l exercice d imposition concerné (date de réception de la déclaration, date limite de déclaration, etc.). Sur la base des données enregistrées dans l Entité, un Exercice d imposition est initialisé chaque année. En d autres termes, un dossier est créé pour chaque déclaration devant être introduite pour l'exercice d'imposition spécifique qui contient déjà une série de métadonnées (date de bilan, date limite, service compétent, langue, etc.). Aussi bien les données de l Entité que celles de l Exercice d imposition doivent pouvoir être conservées, actualisées et consultées sur la base d'une série de règles de validation. 3. Liens avec les autres applications BizTax Backoffice possède de nombreux liens avec d autres applications Sitran Sitran est la seule application au sein du SPF Finances qui rassemble toutes les données signalétiques des contribuables et les met à la disposition de divers utilisateurs et applications, parmi lesquels BizTax Backoffice. Elle est alimentée par une série de sources authentiques parmi lesquelles la Banque-Carrefour des entreprises. L alimentation des diverses applications se fait sur la base de signaux développés pour les différents champs de données de Sitran et que les applications utilisent pour adapter leurs champs de données, lancer certaines transactions ou créer des tâches. BizTax Backoffice utilise actuellement 9 signaux : - Statut juridique - Forme juridique - Adresse - Fusions et scissions - Code d activité - PersIDF et UPersIDF

179 Cahier des charges S&L/AO/386/ /217 - Qualité - Grande entreprise /PME - Date du bilan Ces signaux lancent une série de tâches ou actualisent une série de champs dans l application BizTax Backoffice AnnuComp AnnuComp est l application au sein du SPF Finances qui rassemble les données signalétiques de tous les services, ainsi que leurs compétences. BizTax utilise AnnuComp chaque fois qu un service compétent doit être déterminé, p. ex., en cas de changement d adresse d un contribuable, en cas de création d un avertissement-extrait de rôle sur lequel doit figurer le service compétent, etc Calculatrix Calculatrix contient d une part une série de règles de validation concernant les déclarations pour autant que celles-ci ne soient pas reprises dans la taxonomie XBRL. D autre part, c est aussi au sein de l'application Calculatrix que l impôt dû est calculé, que des simulations sont faites et qu est repris l'ensemble de la chaîne d'enrôlement TaskManager Les tâches créées au sein de chaque application sont centralisées dans le TaskManager et donnent à l'utilisateur un aperçu de toutes les tâches qui lui ont été attribuées. Au sein de TaskManager, les tâches peuvent être classées en fonction de leur degré de priorité, de l'application qui les a générées, etc Identity & Access Management (IAM) C est au sein d IAM que sont stockés les droits d accès de chaque utilisateur aux diverses applications. 4. extended Business Reporting Language (XBRL) L application BizTax Backoffice repose en partie sur une taxonomie XBRL qui génère les écrans des déclarations et du dossier permanent. Les écrans des déclarations sont générés par une taxonomie qui constitue une extension de la taxonomie aussi utilisée dans le cadre de BizTax Frontoffice; une taxinomie distincte a été développée pour le dossier permanent. L application doit tenir compte du fait qu'on n'utilisera pas uniquement la taxonomie relative aux déclarations concernées et au dossier permanent, mais que d autres taxonomies et/ou une extension de la taxonomie à d autres concepts et d autres données propres à l'environnement backoffice pourraient également s avérer nécessaires. Plusieurs versions de la taxonomie ISoc, INR/Soc et IPM sont également possibles. Dans la mesure du possible, il faudra que leur gestion et leur actualisation soient centralisées (taxonomy repository). La validation s'applique aussi bien aux conditions techniques (prescriptions XML et XBRL, aux données structurelles, etc.) qu aux contrôles de contenu (e.a. contrôles mathématiques et logiques, validations technicofiscales) Aperçu du nombre potentiel d'utilisateurs

180 Cahier des charges S&L/AO/386/ /217 Nombre d utilisateurs Backoffice Services de taxation classiques ISoc: répartis sur 160 bureaux Read & Write Centres de contrôle : répartis sur 48 centres Services de taxation IPM: 149 répartis sur 13 bureaux Services de taxation INR/soc: 100 répartis sur 6 bureaux Recherches : 450 IPP: TVA : Fraude : 650 Read & Write Read & Write Read & Write Read Read Read Read & Write En dehors de ces utilisateurs directs actifs, de nombreux autres services du SPF Finances souhaiteront aussi, à l avenir, pouvoir consulter les données contenues dans les déclarations et leurs annexes. b. Cycle de vie récurrent Étant donné l évolution constante de la législation fiscale et les changements qui interviennent au niveau des directives administratives, le backoffice doit nécessairement pouvoir s'adapter à ces changements et être modifié. Les changements se situent principalement sur les plans suivants: - Les déclarations et le dossier permanent sont générés dans le Backoffice par le biais d une taxonomie. Quand la législation ou les développements techniques évoluent, il faut pouvoir adapter la taxonomie le cas échéant. Cette adaptation de la taxonomie peut mener à la création de nouveaux écrans relatifs à la déclaration ou au dossier permanent (tableaux supplémentaires). Sur le plan des règles de validation contenues dans la taxonomie aussi, des changements peuvent s avérer nécessaires. Une aide à la création et à la gestion de la taxonomie XBRL ainsi qu à l intégration et à l adaptation de la génération des écrans sur la base de la Taxonomie XBRL adaptée sera nécessaire chaque année; - Des modifications des règles de validation gérées par Calculatrix peuvent s avérer nécessaires; - Adaptation des lettres standards ou création de nouvelles lettres; - Adaptation ou création de nouvelles listes;

181 Cahier des charges S&L/AO/386/ /217 - Aussi bien au niveau des Entités que de l Exercice d imposition, des champs supplémentaires peuvent s'avérer nécessaires; sur ce plan, l'application devra alors être adaptée, ce qui peut aussi impliquer la création de règles de validation supplémentaires; - L Exercice d imposition est initialisé automatiquement chaque année; des modifications de ce module peuvent donc s avérer nécessaires à la suite de modifications de la législation ou des directives; - Les interactions avec les diverses applications peuvent exiger des modifications au niveau de l application BizTax Backoffice; - Si on utilise de nouveaux signaux supplémentaires en provenance de Sitran, il faudra développer les transactions et les tâches nécessaires, liées à ces signaux supplémentaires dans BizTax Backoffice; - Les données enregistrées dans le fichier Liste Imprimeur peuvent être modifiées et/ou étendues. c. Indications quant à la future maintenance évolutive Les évolutions futures de BizTax Backoffice peuvent se situer sur les plans suivants : 2. Lettres de rappel Les contribuables qui n ont pas introduit leur déclaration sont invités à s acquitter spontanément de leur obligation dans une lettre de rappel avant de se voir infliger une amende. À l avenir, la détection des contribuables qui n ont pas introduit leur déclaration et l envoi d une lettre de rappel doivent se faire entièrement automatiquement. 3. Amendes administratives Les contribuables qui ne respectent pas la législation fiscale peuvent se voir infliger des amendes administratives. Ils sont avertis de ces amendes par lettre recommandée (lettre standard). Ils disposent d un délai d un mois pour formuler leurs remarques et le cas échéant une amende dont le montant dépend des amendes déjà encourues est enrôlée. Les contribuables reçoivent un avertissement-extrait de rôle leur demandant de s acquitter de ce montant dans le délai légal imparti. L historique de ces amendes est tenu dans un tableau du dossier permanent. L ensemble de ce processus, qui se fait encore pour l instant en grande partie sur papier, doit être automatisé : - Envoi d une lettre standard au contribuable en infraction; - Réception de sa réaction; - Établissement et envoi de l avertissement-extrait de rôle avec consultation obligatoire de l historique; - Actualisation du tableau du dossier permanent après l enrôlement; - Transfert automatique des montants enrôlés à l Administration du recouvrement en vue de la perception ou du recouvrement du montant dû 4. MyMinFin À l avenir, certains modules du backoffice pourront être mis à la disposition du contribuable et/ou de son mandataire pour consultation.

182 Cahier des charges S&L/AO/386/ /217 Cette consultation se fera probablement via MyMinFin. L intégration nécessaire à cet effet doit être prévue. 5. Intégration avec d'autres applications De nombreuses applications utilisées par les services de taxation ont parfois été développées indépendamment les unes des autres et à des moments différents. Ces applications ont souvent été développées dans le cadre du programme Traitement intégré, un des principes stratégiques de la réforme Coperfin au sein du SPF Finances. Dans les prochaines années, il y aura sans doute lieu d améliorer l intégration entre les différentes applications, notamment en raison des réformes organisationnelles annoncées au sein du SPF Finances. Les principales interfaces de BizTax Backoffice sont celles avec l application Stirco (module de support des activités de contrôle). Les agents taxateurs, chargés des activités de contrôle, utiliseront aussi beaucoup BizTax Backoffice. Stirco et BizTax Backoffice qui sont actuellement deux applications distinctes devront de plus en plus être intégrées. 6. Nouvelles fonctionnalités L application BizTax Backoffice sera mise en production au plus tôt à partir de l'exercice d imposition Après sa première mise en production, les utilisateurs constateront probablement une série de manquements au niveau des fonctionnalités de l application qui demanderont des développements supplémentaires.

183 Cahier des charges S&L/AO/386/ /217 III. CalcIsoc d. Description fonctionnelle Introduction Calcisoc est responsable d une série de programmes de calcul et d enrôlement des impôts sur les revenus suivants : impôt des sociétés, impôt des personnes physiques et impôt des nonrésidents/sociétés. Cela concerne les nombres de personnes morales suivantes : pour l impôt des sociétés pour l impôt des personnes physiques pour l impôt des non-résidents/sociétés L objectif de Calcisoc est de réaliser une imposition correcte en temps utile pour tous les contribuables et la mise à disposition en temps utile d un module de calcul qui leur permet de calculer eux-mêmes leur impôt pour ainsi encourager la compliance. Calcisoc interagit avec les applications suivantes: Biztax front-office, Biztax back-office, versements anticipés, Sitran, Entités, Annucomp, ICPC, Fedopress. Description Toutes les interventions d acteurs humains se font par le biais de l application Biztax (front-office ou back-office). Calcisoc calcule l impôt en mode simulation lorsque la fonctionnalité est appelée par Biztax frontoffice. Dans ce cas, aucune donnée n est sauvegardée. Calisoc calcule l impôt en mode calcul définitif lorsque la fonctionnalité est appelée par Biztax backoffice. Les données résultant du traitement sont envoyées à Biztax back-office où elles sont stockées pour permettre l enrôlement après sélection par un agent. À intervalle régulier, Calcisoc consulte, au moyen d une vue, la base de données Biztax pour déterminer si un (ou des) paquet(s) est(sont) prêt(s) pour l enrôlement. Les déclarations correspondantes et le résultat du calcul définitif associé sont extraits de Biztax et intégrés à Calcisoc. Le processus d enrôlement continue par la création de rôles, l attribution de numéros de rôle et de numéros d articles, l envoi des fichiers d enrôlement au système de recouvrement, l édition d AER et l apurement des versements anticipés. À la fin du processsus d enrôlement, un feedback est transmis à Biztax back-office.

184 Cahier des charges S&L/AO/386/ /217 Modèle d architecture fonctionnelle Diagramme des packages. Enrichissement Validation Fonctionnalités permettant de compléter les données du bordereau avec des données externes au système ou des données provenant de déclarations précédentes Fonctionnalités permettant de valider les données du bordereau et d émettre des warnings ou erreurs quand une (des) règle(s) de validation ne sont pas rencontrées

185 Cahier des charges S&L/AO/386/ /217 Calcul Édition Enrôlement Apurement VA Fonctionnalités permettant de calculer l impôt des sociétés Fonctionnalités permettant de construire une note de calcul au format PDF ou un avertissement-extrait de rôle Fonctionnalités permettant d introduire les données nécessaires au recouvrement dans le système général de recouvrement du SPF Finances Fonctionnalités permettant la synchronisation avec la base de données VA et l apurement des VA b. Cycle de vie récurrent Les adaptations fiscales annuelles aux trois déclarations destinées aux personnes morales ont un impact sur Calcisoc. Chaque année, il faut prévoir une nouvelle version qui supporte le nouvel exercice d imposition. Une nouvelle législation fiscale, une nouvelle jurisprudence et de nouvelles dispositions administratives entraînent nécessairement des changements au niveau de l application. Les adaptations aux applications avec lesquelles Calcisoc interagit et les évolutions techniques des standards ICT nécessitent une maintenance continue de l application. Enfin, de nouveaux développements sont également nécessaires pour continuer à garantir le fonctionnement correct et performant de l'application. c. Indications quant à la future maintenance évolutive L application Calcisoc n est en production que depuis septembre 2014 pour les enrôlements de l exercice d imposition Une série de manquements au niveau des fonctionnalités de l application seront sans aucun doute constatés qui exigeront des développements supplémentaires. Parmi les fonctionnalités déjà identifiées comme manquantes et donc à développer, on note : Enrôlement plus rapide Intégration de l enrôlement manuel GUI pour bloquer les codes Statistiques des enrôlements Plateforme de test efficace

186 Cahier des charges S&L/AO/386/ /217 IV. Stir-Controle (STIR-CO) a. Description fonctionnelle Release 1 Description générale STIR-CO(ntrole) a pour objet le développement d'un module de contrôle pour tous les services de contrôle des impôts sur le revenu et la TVA au sein de l'ag de la Fiscalité. Au sein du programme STIR, la gestion du plan de travail dans le contexte de la surveillance fiscale a d ailleurs déjà été réalisée. Ce projet de suivi comprend l affinage des fonctionnalités du plan de travail de STIR-CO(ntrole), ainsi que le développement de fonctionnalités au niveau de la gestion de la documentation et de la correspondance. Ces fonctionnalités contiennent le cœur de la réalisation de la surveillance fiscale et des missions de contrôle proposées via les applications de gestion des risques. Ces missions de contrôle sont en outre subdivisées en une série de volets concentrés sur l étude d une matière fiscale spécifique. Objectifs du projet Optimiser, uniformiser et accroître la transparence de la gestion du plan de travail de toutes les missions de contrôle effectuées au sein des CC de l AFER. La numérisation du dossier de contrôle qui le rend consultable par tous les fonctionnaires du SFP Fin y autorisés. Ampleur (scope): Le projet en soi ne concerne que la gestion et l exécution des missions de contrôle au sein des CC de l AFER. À partir du 01/01/2012, le scope de ce projet a été étendu à tous les services de contrôle classiques de l AG de la Fiscalité. L aspect analyse des risques ne fait pas partie du projet Stirco. Produits finaux: Une application qui supporte la gestion du plan de travail de toutes les missions de contrôle exécutées au sein des CC de l AFER et qui permet à l agent contrôleur individuel de gérer son dossier de contrôle électronique. Au sein de l application, des rapports standards sont aussi disponibles pour la communication des informations de management nécessaires. Release 2 Cette phase du projet STIR-CO comporte l affinage des fonctionnalités du plan de travail, comme des développements en matière de la gestion des documents et de la correspondance. Les missions de contrôle proposées par l application de gestion des risques seront fractionnées en un nombre de volets.

187 Cahier des charges S&L/AO/386/ /217 Vue synthétique du module 1: Contrôle. SITRAN WS Sitran Webservices SOAP WS Stiron Documents IAM Contrôle Up loa d qu eue CCFF CCFF LDAP Contexte interapplicatif Cognos STIR_CORE FileNet

188 Cahier des charges S&L/AO/386/ /217 b. Cycle de vie récurrent 1. Adaptations de l'application aux évolutions technologiques internes (le monde java nécessite un release majeur toutes les 2 années); 2. Adaptations de l'application aux évolutions technologiques externes (OS, navigateur, ); 3. Adaptations de l'application aux modifications de structure de l'organisation; 4. Adaptations de l'application aux modifications législatives; 5. Amélioration de la qualité des applications existantes. c. Indications quant à la future maintenance évolutive 1. Implémenter des rapports et des suivis aussi bien pour une utilisation interne que pour une utilisation externe (COGNOS et BAM); 2. Étendre l accès à STIR-CO aux services de gestion des services classiques et par le contextual services; 3. Étendre la fonctionnalité de base et les templates des documents structurés; 4. Introduire, au sein de STIR-CO, un système de mailing qui informe le gestionnaire du plan de travail des nouvelles actions chargées, des modifications importantes, des transferts des missions 5. Reprise des dénominations des services dans le menu déroulant des codes crestra; 6. Intégration de STIR-CO avec Stiron Lot 1 Biztax, Taxi et Lot 2 TVA pour le préremplissage de la fiche de résultats sur la base des données introduites pour l enrôlement ou sur la base de l ordre d'enrôlement afin d'éviter les incohérences et les redondances; 7. Exportation des missions vers Excel (existe déjà) mais avec l ajout des volets sousjacents, liés à chacune des missions exportées (statut volet, exécutant, ); 8. Prévoir un menu déroulant exécutant pour les recherches de volets par le chef de service; 9. Visualisation de la date de clôture d une mission sur la liste des missions.

189 Cahier des charges S&L/AO/386/ /217 V. Stir-Recherche d. Description fonctionnelle Release 1 Au sein du système pour la gestion intégrée de l Administration des Impôts et du Recouvrement (STIR), le développement du module STIR-RE doit offrir un soutien en matière d'une part de la gestion de plan de travail pour la Recherche d'autre part la gestion des documents et des tâches des agents de la Recherche. Le projet STIR-RE se rapporte à l'exécution des actions de recherche au sein des secteurs d'activités. Un nombre fonctionnalités seront développées en matière de gestion du plan de travail et des instructions de travail qui seront complétées dans le cadre d'un prochain release. Release 2 Un nombre de nouveaux éléments sont introduits dans l application comme la gestion des documents structurés et non structurés, l intégration avec le Dossier unique, la notion de charge de travail y compris le fonctionnement avec une équipe d'action, la notion vaste de constatation y compris le processus de validation et les constatationsnon programmées. Vue synthétique du module 2: Recherche. SITRAN WS Sitran Webservices SOAP WS Stiron Documents IAM Recherche Up loa d CCFF CCFF LDAP Contexte interapplicatif STIR_CORE FileNet e. Cycle de vie récurrent 1. Adaptations de l'application aux évolutions technologiques internes (le monde java nécessite un release majeur toutes les 2 années); 2. Adaptations de l'application aux évolutions technologiques externes (OS, navigateur, ); 3. Adaptations de l'application aux modifications de la structure de l'organisation; 4. Adaptations de l'application aux modifications législatives;

190 Cahier des charges S&L/AO/386/ / Amélioration de la qualité des applications existantes. f. Indications quant à la future maintenance évolutive Les évolutions de STIR_Recherches peuvent être divisées en 2 volets : Une composante technique Une composante organisationnelle /réglementaire 1. La composante technique de STIR_Recherches concerne l adaptation de l application aux modifications relatives à la technologie utilisée. a. Au sein du projet NCO, plusieurs modules d introduction (MySQL et PHP) ont été développés par le passé qui offraient la possibilité aux personnes concernées de fournir des données pour l'exécution des SLA. Ces modules ne répondent toutefois pas aux standards ICT actuellement en vigueur et doivent donc être remplacés par des modules d introduction flexibles qui satisfont aux standards ICT actuels et futurs. 2. À partir de 2014/2015, l application STIR_Recherches doit être adaptée à une série de modifications organisationnelles /réglementaires. Sans ces adaptations, l application ne pourra plus être utilisée. Les points d'attention importants sont les suivants: a. Introduction d'une nouvelle structure organisationnelle dans laquelle les 2 directions DRL et DRNI sont remplacées par 1 Centre National de Recherche (CNR) et les 22 inspections existantes sont remplacées par 2 services comprenant plusieurs équipes (inexistants dans la structure actuelle). La nouvelle structure doit être implémentée dans l application. Cela implique que des modifications mineures ou majeures doivent être effectuées au niveau de la structure des tableaux sous-jacents; redéfinition et adaptation des règles de validation actuelles; réévaluation des business rules à l occasion de l implémentation d une approche orientée processus des Activités de recherche (P111); réétudier et adapter la matrice Consultation pour les personnes concernées, étant donné qu'on les retrouve aussi dans les toutes nouvelles structures organisationnelles et de concertation, b. En redessinant les ressorts dans la nouvelle structure, l upload central de l application doit être appliqué in extenso. Cette adaptation est aussi l occasion rêvée d améliorer l harmonisation des fonctionnalités de cet upload avec les besoins et les attentes aussi bien des personnes concernées que des utilisateurs internes. c. Afin de pouvoir anticiper les futures modifications organiques et procédurales, il est souhaitable de développer un module administrateur de sorte que les adaptations nécessaires à l application puissent être effectuées facilement et de manière à pouvoir garantir la continuité de l application. Un module administrateur offre aussi la possibilité de diminuer la dépendance d'un partenaire externe. d. L introduction obligatoire (par le COC de l AG de la Fiscalité) du processus P111; son suivi via les KPI (à partir de 2014), ainsi que la poursuite du développement du mode de fonctionnement via des SLA avec divers stakeholders, invite le CNR

191 Cahier des charges S&L/AO/386/ /217 à faire développer un module de suivi. Sans ce module les activités du CNR ne pourront pas être suivies de manière sérieuse et professionnelle et le CNR ne peut procurer qu une aide faite d informations fragmentaires. Le suivi au niveau individuel du collaborateur doit se faire via le Business Activity Monitoring (BAM). Pour le suivi au niveau du service et du centre, on peut éventuellement opter pour une autre solution. L'utilisateur externe (stakeholder) doit pouvoir suivre l exécution des tâches confiées au CNR.

192 Cahier des charges S&L/AO/386/ /217 VI. PRM-On-Web (ou Prm-on-web) a. Description fonctionnelle Qu est-ce que le précompte mobilier? Le précompte mobilier est une imposition due sur les revenus des capitaux et des biens mobiliers (notamment les intérêts et les dividendes), ainsi que sur les revenus divers à caractère mobilier. De manière générale, le précompte mobilier est retenu à la source et doit être versé spontanément au SPF Finances par ceux qui attribuent les revenus imposables (définis comme les débiteurs par opposition à ceux qui reçoivent les revenus), ou par certains intermédiaires financiers. Le précompte est d ailleurs aussi dû, dans certains cas particuliers, par le bénéficiaire des revenus. Ce précompte doit être payé dans les quinze jours qui suivent l'attribution ou la mise en paiement des revenus imposables. Prm-on-web Grâce à l application internet Précompte Mobilier (Prm-on-web) du SPF Finances, depuis 2012, tous les contribuables peuvent introduire leurs déclarations de précompte mobilier directement par voie électronique. Prm-on-web est une manière rapide, conviviale et sûre de faire une déclaration de précompte mobilier. Prm-on-web accepte 2 moyens d identification : la carte d identité électronique; ou un certificat de classe III délivré par: Global Sign ISABEL Certipost Prm-on-web doit être disponible 24 heures sur 24 de manière à permettre d introduire une déclaration à n importe quel moment. Le précompte mobilier doit être déclaré et payé dans les 15 jours après la date d'attribution ou de mise en paiement des revenus imposables, c.-à-d. la date à laquelle le bénéficiaire peut réellement disposer de ses revenus. Le système fournit aux contribuables une communication structurée qu ils doivent utiliser pour le paiement.

193 Cahier des charges S&L/AO/386/ /217 b. Cycle de vie récurrent L application Prm-on-web fait partie du projet Stimer. Bien que le projet Stimer ressortisse à la compétence de l AG PR, la partie Stimer Prm (c est ainsi que l application Prm-on-web est définie dans Stimer) est attribuée à l AG de la Fiscalité. Cette partie contient d ailleurs l enregistrement des déclarations Prm, qui fait partie des compétences de l AG de la Fiscalité. Le projet Stimer a été remplacé par le projet First. Il existe un contrat de maintenance avec la société Centran pour assurer la maintenance de Stimer/First. Étant donné que le projet Stimer a fait de nombreuses maladies d enfance, Prm-on-web n a pas non plus été épargnée par celles-ci. Au cours de ces dernières années, de nombreux bugs ont dû être réparés dans cette application. Ces bugs et ces maladies d enfance sont aujourd hui largement résolus. De ce fait, quasi aucune, voire aucune, maintenance n a été nécessaire. En 2014, plusieurs adaptations fonctionnelles ont dû être effectuées au niveau des écrans de saisie et de la base de données. Prm-on-web ne nécessite pas de cycle de maintenance annuel. Les adaptations à cette application ne sont pratiquement dues qu en raison des modifications de la législation ou des directives administratives. c. Indications quant à la future maintenance évolutive Pour l'année 2015, le modèle de déclaration du Prm change fondamentalement. Cela demandera une adaptation des écrans de saisie et de la base de données. Dans ce cadre, le développement d un modèle d information statistique s avérera également nécessaire. De plus, la direction responsable de la législation relative au Prm réfléchit actuellement à une déclaration complémentaire pour ce qu on appelle les prêts-citoyens. Aucune décision n a toutefois encore été prise à ce sujet, ni sur le plan administratif, ni sur le plan politique.

194 Cahier des charges S&L/AO/386/ /217 VII. Fin ELTS d. Description fonctionnelle FinELTS est une application pour introduire les : Déclarations pour la taxe d épargne à long terme Déclarations pour la taxe sur les primes (nouveauté) par les institutions financières et les compagnies d assurance L application permet d introduire les données via : Écran Fichiers L accès à l application est possible via : La carte d identité électronique Un certificat de classe 3 délivré par Global Sign, Isabel ou Certipost L utilisateur doit, de plus, être enregistré dans le système Quel que soit le mode d accès (Eid, classe3), lors de la première connexion l utilisateur doit posséder les droits d administrateur sur la machine. Pour un accès via Eid, les informations suivantes doivent se trouver dans l Numéro de l entreprise (no BCE) Nom de la personne mandatée qui accède au site Numéro national de la personne mandatée qui accède au site Adresse de la personne mandatée Pour un accès via certificat de classe 3, les informations suivantes doivent se trouver dans l Numéro de l entreprise (no BCE) Adresse de la personne mandatée L objet du certificat classe 3 (identifiant + nom) : dans le premier écran de l'application FINELTS, cliquer sur le bouton e. Cycle de vie récurrent Il n y a aucune modification qui soit récurrente lors de chaque cycle annuel. Les modifications dépendent des décisions budgétaires. f. Indications quant à la future maintenance évolutive

195 Cahier des charges S&L/AO/386/ /217 En vertu de l'article 8 de la directive 2011/16/EU européenne concernant l'assistance administrative pour les impôts directs, la Belgique est obligée d'échanger pour la période d'imposition débutant le 1er janvier 2014, d'une façon automatique, tous renseignements disponibles dont elle dispose vis-à-vis des résidents des autres États membres en matière de revenus. Pour fournir les renseignements relatifs aux assurances-vie des non-résidents automatiquement et de manière structurée à STIRint, il faut modifier les inputs de FinELTS (encodage et fichiers XML) utilisés par les membres d'assuralia pour disposer des codes pays, codes postaux et si possible des NN et par conséquent modifier la base de données pour recevoir ces informations et créer un flux XML pour recevoir les demandes en provenant de STIRint et renvoyer les réponses. Donner accès à l application aux autres services tels que Grande Entreprise, au recouvrement, au Datawerahouse, au TACM, au Service de Gestion de données

196 Cahier des charges S&L/AO/386/ /217 Lot 4 (Domaine Transnational) 1. Description générale 1.1. Introduction. STIRint/FATCA/Auto_DT STIRint est un programme qui regroupe plusieurs applications utilisées dans le cadre de la collaboration administrative internationale. Une des principales tâches du programme est d exécuter et de gérer chaque type d échange international d informations, aussi bien dans le domaine des impôts directs que dans celui de la TVA et du recouvrement. En raison des différentes bases légales impliquées, l exécution et la gestion de l échange international d informations se font dans des applications distinctes. Même au sein d une même matière, il est souvent nécessaire de développer plusieurs applications pour satisfaire aux différentes obligations internationales. STIRint est une plateforme communautaire, composée de différents modules au sein de différentes administrations : AG Fisc (Impôts directs et TVA) AG PR (Perception & Recouvrement) AG DP (Documentation Patrimoniale) ISI (Inspection Spéciale des Impôts) Le service de Recouvrement non seulement échange des informations au niveau international mais utilise également un système de notification des documents et plus spécialement des demandes de prise de mesures conservatoires et d exécution du recouvrement. Au cours de la réunion de direction du SPF Finances du 23/01/2015 il a été décidé de confier la gestion générale du programme STIRint à l Administration Générale de la Fiscalité Les applications triées par domaine. Vous trouverez ci-après un aperçu des applications au sein du programme STIRint triées par domaine. Cette liste n est pas exhaustive et peut être complétée d autres applications au sein du programme STIRint. Les applications pour la TVA Coopération internationale Cette application est utilisée pour le suivi et la gestion de chaque dossier et de chaque type d échange d informations en matière de TVA. Cette application contient de nombreuses fonctionnalités qui permettent de satisfaire à toutes nos obligations internationales: entre autres, la gestion des autorités compétentes belges et étrangères, le suivi des délais d exécution, la collecte des informations statistiques,

197 Cahier des charges S&L/AO/386/ /217 la gestion des mandats octroyés dans le cadre des contrôles multilatéraux, etc. VAT Refund. À terme, cette application sera transférée à l Administration Générale de la Perception et du Recouvrement. Ce module garantit la gestion des demandes de remboursement de la TVA (8 e et 13 e directives). Le module envoie les demandes des assujettis belges vers les autres États membres via Intervat et garantit la réception et le traitement des demandes de remboursement de la TVA des contribuables établis dans les autres États membres (8 e directive) et dans des pays hors Union européenne (13 e directive). VAT on-e-services (VOES) Ce module fait partie de l application MOSS depuis le 01/01/2015. Ce module doit néanmoins rester actif jusqu au 31/12/2017 afin de permettre aux assujettis non européens de rectifier leurs déclarations Voes antérieures à La description de ce module est reprise dans la description du module MOSS. Il s agit, en fait, du même régime que MOSS, à la seule différence qu il s applique aux assujettis non européens depuis Les applications pour les impôts directs. Coopération internationale Cette application est utilisée pour le suivi et la gestion de chaque dossier et de chaque type d échange en matière d impôts directs. Cette application contient de nombreuses fonctionnalités qui permettent de satisfaire à toutes nos obligations internationales : entre autres, la gestion des autorités compétentes belges et étrangères, le suivi des délais d exécution, la collecte des informations statistiques, la gestion des mandats octroyés dans le cadre des contrôles multilatéraux, la consultation des informations par les services de taxation compétents, etc. Directive sur la fiscalité de l épargne & OCDE Cette application nous permet de respecter les obligations imposées par la Directive européenne sur la fiscalité de l'épargne en ce qui concerne l'envoi d informations. L application permet aussi le traitement technique des informations concernant les revenus de l'épargne que nous recevons des autres États membres de l'ue, des territoires dépendants ou associés ainsi que d une série de pays tiers. Avant d être envoyées, les informations collectées auprès des institutions financières belges sont soumises à un traitement. L application assure aussi le traitement technique et la mise à disposition des informations relatives aux revenus de l épargne que nous recevons des autres États membres de l UE, des territoires dépendants ou associés et d'une série d'autres pays tiers.

198 Cahier des charges S&L/AO/386/ /217 Cette application traite (envoie et réceptionne) aussi l échange automatique d informations dans les formats développés par l OCDE. Auto_DT Cette application a été développée dans le cadre de l article 8 (échange automatique d informations) de la Directive européenne 2011/16/UE. Cette application permettra à la Belgique de respecter son obligation au niveau de l envoi des informations disponibles à partir de l année de revenus 2014 (les premiers échanges auront lieu en 2015) vers les autres États membres de l'ue concernant les catégories de revenus suivantes : FATCA IE (Income from Employment): Revenus professionnels DF (Director s Fees): jetons de présence LIP (Life Insurance Products): produits d assurance sur la vie PEN (Pensions): pensions ROY (Royalties) IP (Immovable Property) Propriété et revenus de biens immobiliers Cette application assurera le traitement des renseignements échangés dans le cadre de l accord inter-gouvernemental conclu entre la Belgique et les États-Unis (U.S.) le 23/04/2014. Avant d envoyer les informations aux États-Unis, les informations collectées auprès des institutions financières belges sont soumises à un traitement. Il s agit ici d un échange mutuel automatique annuel d informations entre les institutions financières belges et américaines. Les premières informations seront échangées en septembre Les applications de MyMinfinPro qui sont liées à STIRint: Il s agit de l application JMonnet et de l application FATCA au sein de MyMinfinPro. Cette dernière ne doit pas être confondue avec l application FATCA au sein de STIRint. Les applications pour la Perception et le Recouvrement. Coopération internationale. Le module IINV gère : 1) en ce qui concerne les créances dont le recouvrement est confié au SPF Finances, l ensemble du workflow de l assistance internationale aux fins du recouvrement sur la base de la Directive 2010/24/UE et des traités internationaux et bilatéraux.

199 Cahier des charges S&L/AO/386/ /217 L assistance proposée comprend la communication d informations, la notification de documents administratifs et judiciaires, la prise de mesures conservatoires et le recouvrement des dettes. Le principal utilisateur de ce module est le Service de recouvrement transversal (précédemment : CLO Recouvrement), qui fait partie du Centre Spécial de Recouvrement. Les différents bureaux de recettes ont accès (consultation) aux dossiers qui les intéressent. 2) En ce qui concerne les créances dont le recouvrement relève de la responsabilité des régions et des pouvoirs subordonnés, l envoi des requêtes et de la correspondance s y rapportant entre les bureaux de liaison régionaux et les administrations étrangères pour toutes les formes d assistance prévues sous 1). Les applications pour l Inspection Spéciale des Impôts Recherche transversale dans les applications Coopération /recouvrement internationaux des Impôts directs, de la TVA et de la Perception et du Recouvrement. Remarque : l ISI traite ses dossiers d échange d informations dans les applications Coopération Internationale ID et Coopération Internationale TVA 1.3. Aperçu des types d applications. Chacune des applications de STIRint permet de réaliser des échanges internationaux de type individuel, en batch et transactionnel. Pour les échanges internationaux individuels les applications présentent les caractéristiques suivantes : Disponibles pour plusieurs services du SPF Finances, avec droits d accès contrôlés et spécifiques; Larges possibilités de recherche avec plusieurs critères de recherche au travers de tous les dossiers présents dans l application; Mise à disposition des données sans devoir copier et envoyer des documents ( Paperless ); Mise à disposition d une interface en vue de la création et de la gestion des échanges; Enregistrement de tous les types d échanges et octroi d un numéro de dossier unique par l application; Gestion du flux des échanges et de leur traitement; Création et gestion de statistiques; Définition flexible des droits des utilisateurs;

200 Cahier des charges S&L/AO/386/ /217 Liaison entre les échanges et les dossiers uniques des personnes; Suivi des échanges (rappels); Conformité aux normes choisies par le SPF Finances. Font partie de ces applications : la coopération internationale dans le domaine de la TVA, des Impôts directs et du Recouvrement. Pour les échanges internationaux automatiques (en batch), les applications présentent les caractéristiques suivantes : Gestion de la réception des fichiers en provenance de l'étranger (soit automatiquement par , soit manuellement via un support mémoire); Introduction du fichier dans le système et envoi vers les différentes applications et/ou personnes; Possibilité de rectification du contenu reçu; Exportation des données à partir de différentes sources vers des États partenaires; Mise des données à la disposition des applications demandeuses; Création et gestion des statistiques; Recherche et consultation des fichiers envoyés et reçus; Recherche et consultation du contenu des fichiers envoyés et reçus (au niveau du dossier); Gestion et suivi des identifications manuelles. Font partie de ces applications : savings directive/ocde, JMonnet, Auto_DT, FATCA, FATCA (MyMinfin) pour les Impôts directs, Enregistrement dans un autre État membre et MTN pour la TVA. Pour les échanges internationaux transactionnels, l application VATRefund présente les caractéristiques suivantes: Gestion des demandes, des corrections et des données de signalement; Prise de décisions au niveau des montants à rembourser; Gestion des paiements; Gestion technique des échanges; Création et gestion des statistiques Description des applications existantes. STIR international regroupe toutes les applications qui échangent des informations entre la Belgique et les autres pays.

201 Cahier des charges S&L/AO/386/ /217 Voici un schéma du projet STIRint en plus de ses connexions et interactions avec d autres applications du SPF Finances.

202 Cahier des charges S&L/AO/386/ /217 Applications BOW STIR- BTW Controle INTERVAT Stimer (ICPC) Belconet TAXI Portaal VATrefund VATeservice Stipad TBT Data Warehouse SITRAN (STIR-DU) Bevoegde ambtenaren CCFF IAM STIRint platform DLO centraal permanent bevoegd tijdeliijk bevoegd SDen OESO (Jmonet) Patrimonium Bulk Pensioenen Levens Verz. Arbeid VAT refund VATon e- services CLO BBI Int. Invord. DLO PLO DIM CLO Generiek bulk Generiek Dossiers Dorothée/ Saintex CLO Tijdelijk bevoegde SNRI GrenszoneBTW Directors Fees Dividend Ander inkomen Meer waarden STIRint BBI centraal OCS Internationale invordering Post Fax... Mail CCN/CSI CCNMail... CCFF HuidigeModeules StirInt SDenJMonet: momenteel nogapart Belgische Regios FODLandX FODLandY FODRegio RLandZ FODTijdelijk bevoegdeambtenaar LandN European Commission Financiële Instellingen