MARCHE PUBLIC DE SERVICES - finances.belgium.be · La solution offerte en réponse à ce cahier spécial des charges formera la base du Project Initiation Document (PID) à établir

SERVICE PUBLIC FÉDÉRAL FINANCES Réf.: Sherlock

P. 1

CAHIER SPECIAL DES CHARGES

MARCHE PUBLIC DE SERVICES

“SHERLOCK”

APPEL D'OFFRES OUVERT

Date de la séance d'ouverture des offres : Le 19 décembre 2013 à 14 heures 30


P. 2

Table des matières

I. DISPOSITIONS ADMINISTRATIVES .................................................................................................. 5

I.1 DESCRIPTION DU MARCHE .................................................................................................................. 5 I.2 IDENTITE DU POUVOIR ADJUDICATEUR ................................................................................................. 6 I.3 DECLARATION DE CONFIDENTIALITE .................................................................................................... 6 I.4 MODE DE PASSATION ......................................................................................................................... 6 I.5 PROCEDURE NEGOCIEE ULTERIEURE .................................................................................................. 6 I.6 FIXATION DES PRIX ............................................................................................................................. 7 I.7 DUREE DU MARCHE ............................................................................................................................ 7 I.8 SESSION D’INFORMATION ................................................................................................................... 7 I.9 FORME ET CONTENU DES OFFRES ....................................................................................................... 8 I.10 GROUPEMENT SANS PERSONNALITE JURIDIQUE ............................................................................... 10 I.11 INCOMPATIBILITES .......................................................................................................................... 10 I.12 VARIANTES .................................................................................................................................... 11 I.13 OPTIONS ....................................................................................................................................... 11 I.14 DELAI DE VALIDITE ......................................................................................................................... 12 I.15 DEPOT DES OFFRES ....................................................................................................................... 12 I.16 OUVERTURE DES OFFRES ............................................................................................................... 14 I.17 PROCEDURE D’ATTRIBUTION DU MARCHE ........................................................................................ 14 I.17.1 Droit d’accès ........................................................................................................................ 14 I.17.2 Critères de sélection qualitative ........................................................................................... 17 I.17.3 Régularité des offres ............................................................................................................ 18 I.17.4 Critères d’attribution ............................................................................................................. 18

II. DISPOSITIONS CONTRACTUELLES ............................................................................................. 20

II.1 LE BON DE COMMANDE ET SES MODALITES ....................................................................................... 20 II.2 FONCTIONNAIRE DIRIGEANT ............................................................................................................. 20 II.3 CAUTIONNEMENT ............................................................................................................................ 20 II.4 CARACTERE LIVRABLE DU SYSTEME PROPOSE .................................................................................. 22 II.5 EXECUTION DU MARCHE .................................................................................................................. 22 II.5.1 Clause d’évolution technologique ......................................................................................... 22 II.5.2 Délais d’exécution ................................................................................................................ 22 II.5.3 Lieu d’exécution du marché et particularités ........................................................................ 23 II.5.4 Personnel de l’adjudicataire ................................................................................................. 24 II.5.5 Sous-traitants ....................................................................................................................... 25 II.5.6 Moyens mis à disposition par le SPF Finances ................................................................... 25 II.5.7 Normes et standards à respecter ......................................................................................... 26 II.5.8 Gestion des changements (« change management ») ........................................................ 27 II.5.9 Engagements particuliers concernant les informations reçues ............................................ 28 II.5.10 Responsabilités .................................................................................................................. 30

II.6 SUIVI DES SERVICES PRESTES ET CONTROLES PAR DES TIERS ........................................................... 30 II.6.1 Suivi de la bonne exécution du marché ............................................................................... 30 II.6.2 Contrôles par des tiers ......................................................................................................... 31

II.7 ÉVALUATION DES SERVICES PRESTES ET OPERATIONS DE VERIFICATION ............................................ 31 II.8 RECEPTION PROVISOIRE ................................................................................................................. 32 II.9 GARANTIE ...................................................................................................................................... 32 II.10 RECEPTION DEFINITIVE.................................................................................................................. 33 II.11 MODALITES ET FRAIS DE RECEPTION .............................................................................................. 33 II.12 PROPRIETE DES SOFTS DEVELOPPES ............................................................................................. 33 II.13 FACTURATION, PAIEMENT ET REVISION DES PRIX............................................................................. 34 II.13.1 Facturation et paiement ...................................................................................................... 34 II.13.2 Révision des prix ................................................................................................................ 35 II.13.3 Clause du client le plus avantagé....................................................................................... 36

II.14 PUBLICITE - REFERENCEMENT ....................................................................................................... 36 II.15 LIVRAISONS EN RETARD ................................................................................................................ 36 II.16 MOYENS DE DEFENSE DE L’ADMINISTRATION - LITIGES .................................................................... 36

III. DESCRIPTION DES EXIGENCES TECHNIQUES .......................................................................... 38


P. 3

III.1 INTRODUCTION .............................................................................................................................. 38 III.2 REMARQUES QUANT A LA STRUCTURE DU VOLET TECHNIQUE DU CAHIER SPECIAL DES CHARGES ........ 39 III.2.1 Définitions ........................................................................................................................... 39 III.2.2 Acronymes et abréviations .................................................................................................. 39

III.3 CONTEXTE DU MARCHE .................................................................................................................. 41 III.3.1 Contexte général ................................................................................................................. 41 III.3.2 Contexte technique ............................................................................................................. 43 III.3.3 Contexte organisationnel .................................................................................................... 43

III.4 DESCRIPTION DU MARCHE .............................................................................................................. 47 III.4.1 Généralités .......................................................................................................................... 48 III.4.2 Utilisateurs du système ....................................................................................................... 50 III.4.3 Exposé des besoins fonctionnels ........................................................................................ 50 III.4.4 Exigences non fonctionnelles ............................................................................................. 78 III.4.5 Aspects techniques ............................................................................................................. 80

III.5 ENCADREMENT DU MARCHE ........................................................................................................... 86 III.5.1 Phasage .............................................................................................................................. 86 III.5.2 Décision Go / No Go ........................................................................................................... 88 III.5.3 Aspects personnels ............................................................................................................. 89 III.5.4 Licences à livrer .................................................................................................................. 89 III.5.5 Documentation à fournir ...................................................................................................... 89 III.5.6 Gestion de la qualité et des risques .................................................................................... 90

III.6 SERVICES A PRESTER .................................................................................................................... 90 III.6.1 Transfert de connaissance .................................................................................................. 90 III.6.2 Collaboration et coaching ................................................................................................... 91 III.6.3 Assistance complémentaire ................................................................................................ 92 III.6.4 Transférabilité ..................................................................................................................... 92 III.6.5 Maintenance ........................................................................................................................ 93 III.6.6 Intégration au service desk ................................................................................................. 94 III.6.7 Service Level Agreements (SLA) ........................................................................................ 95

III.7 INFORMATIONS CONCERNANT L’INVENTAIRE .................................................................................... 98

ANNEXE A : FORMULAIRE D'OFFRE .............................................................................................. 101

ANNEXE B : CURRICULUM VITAE ................................................................................................... 103

ANNEXE C : MODÈLE DE RÉFÉRENCE .......................................................................................... 105

ANNEXE D : FORMULAIRE DE QUESTIONS/RÉPONSES ............................................................. 106

ANNEXE E : INVENTAIRE ................................................................................................................. 107

ANNEXE F : CONCEPTS ................................................................................................................... 115

ANNEXE G : SCÉNARIOS DU WORKFLOW CONTENTIEUX ET RECOUVREMENT ................... 120

ANNEXE H : EXEMPLES DE SCENARIOS FIODA .......................................................................... 124


P. 4

Auteur de projet Nom : Service d'Encadrement ICT Adresse : Boulevard du Roi Albert II 33 bte 95 à 1030 Bruxelles Personne de contact : Madame Nathalie Orban Téléphone : 0257/6.43.12 Fax : 0257/9.68.01 E-mail : [email protected] Réglementation en vigueur 1. Loi du 15 juin 2006 relative aux marchés publics et à certains marchés de travaux, de fournitures et de services, et ses modifications ultérieures. 2. Arrêté royal du 15 juillet 2011 relatif à la passation des marchés publics dans les secteurs classiques, et ses modifications ultérieures. 3. Arrêté royal du 14 janvier 2013 établissant les règles générales d'exécution des marchés publics et des concessions de travaux publics, et ses modifications ultérieures. 4. Règlement général pour la protection du travail (RGPT), Loi sur le bien-être et Code sur le bien-être au travail. En ce qui concerne les documents propres au pouvoir adjudicateur :

Le présent cahier spécial des charges.

Les avis relatifs au marché et les avis de modification, annoncés ou publiés dans le Bulletin des Adjudications et dans le Journal des Publications de l'Union Européenne, qui concernent les marchés publics en général.

Les clarifications résultant de la séance d'information (questions posées et réponses données par le pouvoir adjudicateur). Ces précisions font partie intégrante des conditions contractuelles. Le soumissionnaire est censé en avoir pris connaissance et en avoir tenu compte dans son offre.

Les documents auxquels le pouvoir adjudicateur fait référence dans le cahier spécial des charges.

En ce qui concerne les documents propres au soumissionnaire :

L'offre du soumissionnaire.

Les précisions et engagements acceptés par le SPF Finances et qui complètent l'offre (avec la même référence) suite aux questions et demandes de clarification.

Autres documents possibles : - Dérogations, précisions et commentaires -


P. 5

I. Dispositions administratives Cette première partie se rapporte à la réglementation relative à la passation d'un marché public jusqu'à la désignation de l'adjudicataire. Les dispositions contenues dans cette partie se rapportent à la loi du 15 juin 2006 et à l’arrêté royal du 15 juillet 2011 et ses modifications ultérieures.

I.1 Description du marché Il s’agit d’un marché de services Objet des Services : SHERLOCK. Le marché se compose de la fourniture d'une application informatique à laquelle la suite du texte fera référence sous le nom le SHERLOCK. Scope de SHERLOCK:

Créer, gérer et stocker les dossiers infractionnels et les dossiers contentieux et recouvrement, afin de répondre aux obligations normatives (forme, contenu et délais)

Permettre le suivi des dossiers (attribution des tâches, agenda, historique …)

Centraliser et stocker les informations, afin de rapporter de manière fiable et pertinente au Management ;

Interagir avec différents systèmes (PLDA, SITRAN, … 1), afin d’accroître l’efficacité et

l’efficience des agents, en facilitant leur accès à des données nécessaires à une réalisation optimale des dossiers ;

Faciliter le contrôle interne et la transparence entre les services

SHERLOCK est une application qui est :

soit entièrement le résultat d’un développement spécifique et sur mesure, réalisé par l’adjudicataire suivant les spécifications de ce cahier spécial des charges ;

soit essentiellement un package/outil « off-the-shelf » prêt à l’emploi, paramétrable, suffisamment personnalisable et extensible pour que les spécifications de ce cahier des charges soient réalisées aussi complètement que possible ;

soit une combinaison de ces deux options ;

et pour laquelle l’ensemble réalisé satisfasse intégralement aux résultats de l’analyse fonctionnelle à réaliser (voir PHASE 1 “Elaboration” au § III.5).

Nous distinguons les niveaux de priorité suivants :

P1 – « Nécessaire » : Ces fonctionnalités sont considérées comme cruciales pour la plus-value escomptée et la réalisation des objectifs métier. L’application proposée par le soumissionnaire doit apporter une solution adéquate à chacune de ces exigences.

P2 – « Souhaité » : Caractéristiques d’intérêts pour lesquels une mise en oeuvre éventuelle peut être réalisée en tenant compte de la faisabilité technique, du coût de revient et de l’impact sur le planning. Chaque exigence de niveau prioritaire P2 est considérée comme une option (voir I.13). Le soumissionnaire devra formuler une solution pour chacune de ces

1 Pour une liste des acronymes et abréviations utilisées, voir III.2.2


P. 6

exigences. Pendant l'exécution du contrat la possibilité de réalisation de chaque P2 sera prise sur base d'une analyse coût / bénéfice.

P3 – « Futur » : Ces exigences sont mentionnées à titre d’information et ne font pas partie du marché. Leur réalisation effective est prévue pour des releases ultérieurs. Il est cependant essentiel que la solution proposée n’exclue pas la réalisation future de ces exigences.

La partie réalisée sera entièrement conforme aux résultats de l'analyse fonctionnelle à exécuter (voir PHASE 1 « Elaboration » in § III.5). Pour tous les logiciels et les composants qui seront mis en œuvre, le soumissionnaire doit inclure dans son offre une description technique de la solution proposée. La solution offerte en réponse à ce cahier spécial des charges formera la base du Project Initiation Document (PID) à établir au début du projet. Lieu de la prestation du service: Service d'Encadrement ICT, Boulevard du Roi Albert II 33 bte 95 à 1030 Bruxelles

I.2 Identité du pouvoir adjudicateur Service Public Fédéral Finances Service d’Encadrement ICT Boulevard du Roi Albert II 33 bte 95 1030 Bruxelles

I.3 Déclaration de confidentialité La personne ou les personnes qui intervien(nen)t en tant que mandataire(s) et qui a/ont signé cette offre électroniquement, garantit/garantissent la confidentialité des données et les résultats de leur traitement qui sont obtenus dans le cadre de la mission décrite dans ce cahier spécial des charges. Il s’ensuit que ces données et les résultats de leur traitement :

seront utilisés uniquement ,si nécessaire, pour la réalisation de l'objet de la mission,

ne seront ni diffusés ni copiés,

ne seront pas gardés plus longtemps que nécessaire pour l'exécution de la mission.

I.4 Mode de passation Le marché est passé par appel d'offres ouvert. En application de l'article 35 de la loi du 15 juin 2006 relative aux marchés publics et à quelques marchés de travaux, de fournitures et de services, le pouvoir adjudicateur peut soit renoncer à octroyer le marché, soit recommencer la procédure, au besoin suivant une autre méthode.

I.5 Procédure négociée ultérieure Conformément à l'article 26 § 1, 2°, b de la loi du 15 juin 2006 relative aux marchés publics, le pouvoir adjudicateur se réserve le droit, moyennant une procédure négociée, sans publicité pendant une période de maximum trois ans après la conclusion du présent marché, d'attribuer, au soumissionnaire


P. 7

qui a obtenu le premier marché, un marché pour de nouveaux services consistant en une répétition des services similaires aux services décrits dans le présent cahier spécial des charges.

I.6 Fixation des prix Le présent marché consiste en un marché mixte. Le marché mixte est celui dont les prix sont fixés suivant plusieurs des modes dont il est question aux alinéas 4° à 6° de l'article 2 de l'arrêté royal du 15 juillet 2011. Tous les prix mentionnés dans le formulaire « inventaire » doivent être obligatoirement libellés en euros. Dans son offre, le soumissionnaire indiquera les prix de toutes les parties de l'offre. Il complétera à cet effet l'inventaire prévu en annexe du présent cahier spécial des charges (annexe “inventaire”). Les prix sont mentionnés tous frais compris, mais hors TVA. L'offre doit mentionner le prix de TVA inclusif séparé de celle-ci pour chaque partie de l'offre.

L'utilisation du modèle "inventaire", tel qu'il est joint au cahier des charges, est obligatoire. La non-utilisation de ce modèle peut mener à l'exclusion de l'offre. L'on ne tiendra pas compte des prix qui sont mentionnés à un autre endroit qu'à la partie 2 de l'offre.

I.7 Durée du marché Le marché a une durée prévue de 4 ans qui débute à la date d'envoi du premier bon de commande. L’adjudicataire est tenu, à l’issue de la période initiale de 4 ans, d’assurer la maintenance pendant deux fois une année supplémentaire sur simple demande du pouvoir adjudicateur. L’adjudicataire reste donc lié contractuellement pendant le délai de la période initiale, augmenté de prolongations éventuelles.

I.8 Session d’information Étant donné la complexité du marché, le pouvoir adjudicateur a décidé d'organiser une séance d'information unique à l'attention des candidats-soumissionnaires.

Il ne sera répondu à aucune des questions posées après cette séance d’information afin de traiter tous les candidats-soumissionnaires de la même manière.

Il y sera exclusivement répondu aux questions écrites introduites au plus tard le 22 octobre 2013 par le biais du formulaire questions / réponses joint en annexe au présent cahier spécial des charges (voir “annexe: formulaire questions / réponses”). Ces questions peuvent uniquement être introduites par courriel, dans un tableur tel que celui joint en annexe, à l'adresse [email protected] La séance d'information se déroulera le 28 octobre 2013 à 10h à cette adresse : SPF Finances Boulevard du Roi Albert II 33 1030 Bruxelles. C5. Salle Mandarin. Toutes les questions doivent obligatoirement faire précisément référence au cahier spécial des charges, de façon à faciliter une réponse rapide (par ex. partie 1, point 1.1, paragraphe 1, page 1). Prière aussi de mentionner la langue du cahier spécial des charges utilisée (la pagination peut différer d’une langue à l’autre).

mailto:[email protected]


P. 8

Pendant cette séance d'information, un bref aperçu de l'objet du marché sera présenté. Les réponses aux questions introduites dans les délais seront données verbalement lors de la séance d’information et seront ensuite publiées sur le site Internet du SPF Finances. Il est demandé aux sociétés intéressées de se faire connaître au préalable par courriel à l’adresse [email protected] et de communiquer le nom et la fonction de la (des) personne(s) qui les représentera (représenteront) à la séance d’information. Pour des raisons d’organisation, un maximum de 2 personnes par société intéressée sera admis. Le SPF Finances se réserve le droit de refuser aux personnes qui ne se sont pas fait connaître 24 heures à l'avance, de participer à la session d’information. Si les sociétés intéressées remarquent des incohérences, imprécisions, etc. dans le cahier spécial des charges, elles sont invitées à le faire savoir par écrit avant la séance d’information, suivant les mêmes modalités que pour l’envoi des questions. Le SPF Finances accorde une grande importance à l’égalité des soumissionnaires et rédige les spécifications de ses cahiers des charges en conséquence. Si une firme intéressée estime malgré tout que ses chances sont diminuées, voire réduites à néant, par certaines spécifications du présent cahier des charges, elle est invitée à en faire part par écrit au plus tard lors de la séance d’information. Le cas échéant, le SPF adaptera, s’il l’estime nécessaire, son cahier des charges afin d'en tenir compte.

I.9 Forme et contenu des offres

Le soumissionnaire est tenu d’utiliser le formulaire d’offre joint en annexe au présent cahier spécial des charges. Si toutefois d’autres documents sont utilisés, il supporte l’entière responsabilité de la parfaite concordance entre les documents qu’il a utilisé et le formulaire (article 80 de l’A.R. du 15 juillet 2011) .

L’offre et les annexes jointes au formulaire d’offre sont rédigées en français ou en néerlandais. Le soumissionnaire doit indiquer la langue à utiliser pour l’interprétation du contrat, c’est-à-dire le français ou le néerlandais. 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 à l’offre. Les soumissionnaires sont tenus de s'engager expressément sur toutes les clauses administratives et contractuelles du présent cahier spécial des charges. Toute réserve ou absence d’engagement sur l'une de ces clauses peut entraîner l'irrégularité de l'offre. Quant à la structure de l’offre: L'offre du soumissionnaire devra obligatoirement être présentée selon le schéma suivant :

Partie 1 – Partie administrative A. Formulaire d’offre (modèle: voir ci-dessous) B. Pouvoirs des mandataires C. Sélection qualitative

Critères d’exclusion

Critère de sélection relatif aux moyens économiques et financiers du soumissionnaire

Critères de capacité technique



P. 9

D. Informations relatives aux sous-traitants (si applicable) Partie 2 – Partie financière

L’inventaire : détailler et résumer les coûts (modèle: voir ci-dessous) Partie 3 – Proposition technique

L’offre suit la structure de la partie III du cahier des charges Partie 4 – Annexes obligatoires Annexe 1: Références de projets récents, aussi bien dans le secteur

privé que public (modèle: voir ci-dessous) Annexe 2: Curriculum Vitae (modèle: voir ci-dessous) Partie 5 – Annexes spécifiques Annexe A, B, C, … : Annexes que le soumissionnaire juge utile de joindre.

Chaque proposition du soumissionnaire qui ne suivrait pas la structure imposée par le pouvoir adjudicateur, peut être considérée comme irrégulière.

La Partie 3 - proposition technique ne peut contenir aucune indication administrative et/ou de prix. Il ne sera tenu aucun compte de toute mention administrative ou indication de prix apparaissant dans une autre partie que la partie 2. Il est demandé de réduire au minimum le nombre de fichiers à présenter. Ainsi par exemple des fichiers séparés peuvent être regroupés dans des documents plus importants. Il est également essentiel d’ordonner les fichiers au moyen d'une numérotation, de sorte que la structure de l’offre soit claire. Il est aussi demandé que dans chaque fichier les pages soient pourvues d’une numérotation ininterrompue. Signature de l’offre Le soumissionnaire signe l’offre, l’inventaire et les autres annexes jointes à l’offre (art. 82§1 A.R. 15/07/2011). Concernant les mandataires: Toute offre introduite par des mandataires doit indiquer l'entité au nom de laquelle agissent les mandataires.

Celui qui a signé l’offre doit, à la date de la signature, être habilité à engager le mandant au montant total de l’offre. Les mandataires joignent à l'offre une copie électronique d e l ’ acte authentique ou sous seing privé les habilitant, ou une copie de cet acte. Ils doivent également mentionner le numéro de l'annexe au Moniteur belge à laquelle sont publiés les mandats (article 82 A.R. 15/07/2011)

Concernant les sous-traitants Tout recours à des sous-traitants sera clairement indiqué dans l'offre du soumissionnaire. Celui-ci décrira le type de relation contractuelle qui le lie avec chacun de ses sous-traitants. Le nom et l'adresse des sous-traitants seront joints à l'offre, avec mention de la ou des parties du marché à réaliser par chaque sous-traitant.


P. 10

Concernant les documents d’ordre technique Les documents d’ordre technique (Pas de brochures publicitaires !) qui sont joints à l’offre dans la partie 5 - annexes spécifiques, peuvent être rédigés en anglais dans le cas où il n’existerait pas de traduction dans la langue de l’offre, les autres langues ne sont pas autorisées. Formulaires à utiliser (joints en annexe au présent cahier spécial des charges):

Le formulaire d’offre: voir “annexe: formulaire d’offre”

Le formulaire inventaire : voir “annexe: inventaire”

Le formulaire pour les références: voir “annexe: modèle de référence”

Le formulaire curriculum vitae: voir “annexe: curriculum vitae”

I.10 Groupement sans personnalité juridique La remise d'une offre par un groupement sans personnalité juridique momentanée est admise. Le formulaire d’offre (voir formulaire qui est repris dans le présent cahier spécial des charges : « annexe : formulaire d’offre ») est complété et signé par tous les membres du groupement sans personnalité juridique. Chaque membre du groupement sans personnalité juridique doit satisfaire au droit d’accès décrit ultérieurement dans le présent document. L'évaluation de la capacité économique, financière et technique porte sur le groupement sans personnalité juridique et non sur chaque membre séparément. Chaque membre du groupement sans personnalité juridique est solidairement responsable de toutes les obligations résultant du présent marché.

I.11 Incompatibilités Les soumissionnaires doivent être attentifs à l’article 7 de la loi du 15 juin 2006 et à l’article 64 de l’arrêté royal du 15 juillet 2011 concernant les incompatibilités : Article 64 § 1er. Le candidat ou le soumissionnaire se voit refuser l'accès à la procédure de passation d'un marché lorsqu'il a été chargé de la recherche, de l'expérimentation, de l'étude ou du développement de ce marché s'il retire de ces prestations un avantage qui empêche ou qui fausse les conditions normales de concurrence. Toutefois, avant de rejeter pour ce motif sa demande de participation ou son offre, le pouvoir adjudicateur invite le candidat ou le soumissionnaire, par lettre recommandée, à fournir par écrit les justifications pertinentes qui lui permettraient d'établir qu'il ne bénéficie pas d'un avantage au sens de l'alinéa 1er. Cette formalité ne s'impose pas si ces justifications ont été jointes à la demande de participation ou à l'offre. Pour être recevables, les justifications sont transmises au pouvoir adjudicateur dans les douze jours de calendrier à compter du lendemain de l'envoi de la lettre recommandée, à moins que celle-ci ne mentionne un délai plus long. La preuve de l'envoi de ces justifications incombe au candidat ou au soumissionnaire concerné. § 2. De même, est rejetée la demande de participation ou l'offre introduite par une entreprise liée à une personne qui a été préalablement chargée de la recherche, de l'expérimentation, de l'étude ou du


P. 11

développement du marché, si du fait de ce lien, cette entreprise bénéficie par ces prestations d'un avantage de nature à empêcher ou à fausser les conditions normales de la concurrence. Par " entreprise liée " au sens du présent paragraphe, on entend soit toute entreprise sur laquelle une personne visée à l'alinéa 1er peut exercer directement ou indirectement une influence dominante, soit toute entreprise qui peut exercer une influence dominante sur cette personne ou qui, comme celle-ci, est soumise à l'influence dominante d'une autre entreprise, du fait de la propriété, de la participation financière ou des règles qui la régissent. L'influence dominante est présumée lorsqu'une entreprise, directement ou indirectement, à l'égard d'une autre entreprise : 1° détient la majorité du capital souscrit de l'entreprise, ou 2° dispose de la majorité des voix attachées aux parts émises par l'entreprise, ou 3° peut désigner plus de la moitié des membres de l'organe d'administration, de direction ou de surveillance de l'entreprise. Toutefois, avant de rejeter la demande de participation ou l'offre d'une entreprise liée, le pouvoir adjudicateur invite cette dernière, par lettre recommandée, à fournir, par écrit, les justifications pertinentes qui lui permettraient d'établir que cette entreprise ne bénéficie pas d'un avantage au sens du présent article. Les justifications sont basées sur les liens de l'entreprise, sur son degré d'autonomie et sur toute autre circonstance probante. Elles établissent soit l'absence de toute influence dominante, soit si celle-ci est confirmée, qu'elle est sans effet sur le marché considéré. Pour être recevables, les justifications sont transmises au pouvoir adjudicateur dans les douze jours de calendrier à compter du lendemain de l'envoi de la lettre recommandée, à moins que celle-ci ne mentionne un délai plus long. La preuve de l'envoi de ces justifications incombe au candidat ou soumissionnaire concerné. Les soumissionnaires sont tenus de fournir dans leur offre les pièces nécessaires qui permettent d'attester qu'ils n'ont pas bénéficié d'un avantage de nature à fausser les conditions normales de concurrence.

I.12 Variantes Article 9 de l’arrêté royal du 15/07/2011. Les variantes libres ne sont pas autorisées. Aucune variante obligatoire ou facultative n'est prévue.

I.13 Options Article 10 de l’arrêté royal du 15/07/2011. La proposition « d’options libres » ne sont pas autorisées. Les options suivantes sont demandées : voir partie III.4.3 Exposé des besoins fonctionnels, niveaux de priorité P2. Si des options sont demandées, les dispositions suivantes sont d'application :

Les options obligatoires (développements, accessoires ou prestations complémentaires) dont la livraison est obligatoire par le cahier des charges, seront proposées par les soumissionnaires, sous peine d'irrégularité de leur offre


P. 12

Le pouvoir adjudicateur se réserve cependant le droit de ne pas lever ces options. Une option non levée ne peut donner lieu à aucune forme de dédommagement.

Lorsqu'un équipement demandé comme option obligatoire, est prévu initialement sur le matériel standard, le soumissionnaire le mentionnera expressément dans son offre.

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

I.15 Dépôt des offres

Le pouvoir adjudicateur impose dans le cadre du présent marché le recours aux moyens électroniques pour le dépôt des offres.

S'il s'avère que certains écrits ne peuvent être créés par des moyens électroniques, ou qu'il s'avère trop complexe de les créer par ces moyens, ces écrits peuvent être fournis sur un support papier et ce avant l’ouverture des offres. Le recours à des documents sur un support papier devra faire l'objet d'un accord préalable de la part du pouvoir adjudicateur. Cet accord est à demander à l’adresse suivante : SPF Finances Service d’Encadrement ICT – Cellule Marchés publics Boulevard du Roi Albert II 33 bte 95 1030 Bruxelles E-mail : [email protected] Afin de remédier à certains aléas de la transmission, de la réception ou de l'ouverture des demandes de participation ou des offres introduites par des moyens électroniques, le pouvoir adjudicateur autorise les soumissionnaires :

Soit, dans le cas où une demande de participation ou une offre peut entraîner la transmission de documents volumineux, et pour éviter tout retard consécutif aux aléas de transmission électronique qui pourraient en résulter, de transmettre leur demande de participation ou leur offre sous la forme d'un double envoi électronique.

En premier lieu, ils transmettent un envoi simplifié contenant leur identité, la signature électronique de leur demande de participation ou de leur offre complète et, le cas échéant, le montant de leur offre. Cet envoi est signé électroniquement. La réception de cet envoi vaut date certaine de réception de la demande de participation ou de l'offre.

En second lieu, ils transmettent la demande de participation ou l'offre proprement dite, signée électroniquement afin de certifier l'intégrité du contenu de la demande de participation ou de l'offre.

La réception de la demande de participation ou de l'offre proprement dite a lieu dans un délai ne pouvant excéder vingt-quatre heures à compter de la date et de l'heure limite de réception des demandes de participation ou des offres, sous peine du rejet de la demande de participation ou de l'offre.

Soit, à introduire à la fois une offre transmise par des moyens électroniques et, à titre de sauvegarde, une copie établie par des moyens électroniques ou sur support papier. Cette copie de sauvegarde est glissée dans une enveloppe définitivement scellée qui porte clairement la mention "copie de sauvegarde" et est introduite dans les délais de réception


P. 13

impartis. La copie de sauvegarde d'une offre est par ailleurs soumise aux règles du présent arrêté qui sont applicables aux offres (voir Arrêté royal 15/07/2011, chapitre 4, section 5).

Cette copie ne peut être ouverte qu'en cas de défaillance lors de la transmission, la réception ou l'ouverture de la demande de participation ou de l'offre transmise par des moyens électroniques. Elle remplace dans ce cas définitivement le document transmis par des moyens électroniques.

Afin d’éviter tout problème, les firmes intéressées sont invitées à tester le plus rapidement possible les applications e-procurement via le site de démo e-notification et e-Tendering. https://enotdemo.publicprocurement.be/ https://etendemo.publicprocurement.be/

Quant à l'introduction même: Avant leur ouverture, les offres électroniques sont déposées via le site Internet e-tendering https://eten.publicprocurement.be/, qui garantit le respect des conditions de l'article 52 de l'AR du 15 juillet 2011. Notons que l'envoi d'une offre par courriel ne répond pas à ces conditions. Il n'est dès lors pas autorisé d'introduire l'offre de cette façon. Indépendamment des variantes éventuellement autorisées, chaque soumissionnaire ne peut introduire qu'une seule offre par marché. L'offre doit parvenir au pouvoir adjudicateur avant la date limite de réception des offres. En soumettant son offre par la voie électronique, le soumissionnaire accepte que les données générées par le système de réception soient enregistrées. Il faut signaler que la signature doit se faire par voie électronique. Une signature manuscrite scannée n’est pas considérée comme une signature acceptable. Au besoin, les attestations demandées seront scannées afin de les joindre à l'offre. Vous trouverez de plus amples informations sur le site Internet suivant : http://www.publicprocurement.be Ou via le helpdesk e-procurement :

Tél.: 02 790 52 00

Mail: [email protected] Si un soumissionnaire souhaite modifier ou retirer une offre déjà envoyée: Cela doit s'effectuer selon les dispositions reprises à l'article 91 de l'AR du 15 juillet 2011. La modification ou le retrait d'une offre déjà introduite peut se faire par voie électronique satisfaisant à l'article 52 de l'AR du 15 juillet 2011 ou sur papier. Pour modifier ou retirer une offre déjà introduite, une déclaration écrite est nécessaire. Celle-ci doit être dûment signée par le soumissionnaire ou son mandataire. L'objet et la portée des modifications doivent, sous peine de nullité de l'offre, être mentionnés de manière précise. Le retrait doit être inconditionnel. Les dispositions des articles 80 et 90 de l’AR du 15 juillet 2011 sont applicables aux modifications et aux retraits.

https://enotdemo.publicprocurement.be/

https://etendemo.publicprocurement.be/

https://eten.publicprocurement.be/

http://www.publicprocurement.be/



P. 14

Le retrait peut également être signifié par télécopie ou par un moyen électronique qui n'est pas conforme à l'article 52, § 1er de l’AR du 15 juillet 2011, pour autant : 1° qu'il parvienne au président de la séance d'ouverture avant que cette séance ne soit déclarée ouverte, 2° et qu'il soit confirmé par lettre recommandée envoyée au plus tard la veille du jour de la séance d'ouverture. Le soumissionnaire peut indiquer dans sa nouvelle offre déposée régulièrement celles des annexes de l'offre retirée remises par des moyens autres qu'électroniques et qu'il entend maintenir.

I.16 Ouverture des offres La séance publique d'ouverture des offres au cours de laquelle les offres seront ouvertes se déroulera le 19 décembre 2013 à 14h30, à l'adresse suivante : SPF Finances NORTH GALAXY, Boulevard du Roi Albert II 1030 Bruxelles Salle de réunion B4.

I.17 Procédure d’attribution du marché

I.17.1 Droit d’accès

Par le simple fait de participer à la procédure d'attribution d'un marché public, le soumissionnaire déclare ne pas se trouver dans l'un des cas d'exclusion suivants, tels que mentionnés à l’article 61 l'Arrêté Royal du 15 juillet 2011 relatif à la passation des marchés publics dans les secteurs classiques. Le pouvoir adjudicateur procède dans ce cas à la vérification de la situation : 1° des candidats entrant en considération pour la sélection, avant de prendre la décision de sélection; 2° du soumissionnaire susceptible d'être désigné adjudicataire, avant de prendre la décision d'attribution.

§ 1. Conformément à l'article 20 de la loi, est exclu de l'accès au marché, à quelque stade que ce soit de la procédure, le candidat ou le soumissionnaire qui a fait l'objet d'une condamnation prononcée par une décision judiciaire ayant force de chose jugée dont le pouvoir adjudicateur a connaissance pour : 1° participation à une organisation criminelle telle que définie à l'article 324bis du Code pénal; 2° corruption, telle que définie à l'article 246 du Code pénal; 3° fraude au sens de l'article 1er de la convention relative à la protection des intérêts financiers des communautés européennes, approuvée par la loi du 17 février 2002; 4° blanchiment de capitaux tel que défini à l'article 3 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.


P. 15

En vue de l'application du présent paragraphe, le pouvoir adjudicateur demande aux candidats ou 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. Le pouvoir adjudicateur peut déroger à l'obligation visée au présent paragraphe pour des exigences impératives d'intérêt général.

La preuve que le candidat ou le soumissionnaire ne se trouve pas dans un des cas précités, peut être apportée par un extrait du casier judiciaire ou un document équivalent délivré par une autorité judiciaire ou administrative du pays d'origine ou de provenance et dont il résulte que ces exigences sont satisfaites;

§ 2. Conformément à l'article 20 de la loi, peut être exclu de l'accès au marché, à quelque stade que ce soit de la procédure le candidat ou le soumissionnaire : 1° qui est en état de faillite, de liquidation, de cessation d'activités, de réorganisation judiciaire ou dans toute situation analogue résultant d'une procédure de même nature existant dans d'autres réglementations nationales; 2° qui a fait l'aveu de sa faillite ou fait l'objet d'une procédure de liquidation, de réorganisation judiciaire ou de toute autre procédure de même nature existant dans d'autres réglementations nationales; 3° 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;

La preuve que le candidat ou le soumissionnaire ne se trouve pas dans un des cas précités, peut être apportée par un extrait du casier judiciaire ou un document équivalent délivré par une autorité judiciaire ou administrative du pays d'origine ou de provenance et dont il résulte que ces exigences sont satisfaites;

Pour les candidats et soumissionnaires belges, le pouvoir adjudicateur demandera directement cette information via le guichet électronique.

4° qui, en matière professionnelle, a commis une faute grave; 5° qui n'est pas en règle avec ses obligations relatives au paiement de ses cotisations de sécurité sociale conformément aux dispositions de l'article 62; Art. 62. § 1er. Le candidat ou le soumissionnaire employant 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 joint à sa demande de participation ou à son offre, selon le cas, une attestation de l'Office national de Sécurité sociale dont il résulte qu'il est en règle en matière de paiement de ses cotisations de sécurité sociale. L'attestation porte sur l'avant-dernier trimestre civil écoulé avant la date limite de réception des demandes de participation ou des offres, selon le cas. Est en règle par rapport aux obligations susmentionnées, le candidat ou le soumissionnaire qui : 1° a transmis à l'Office national de Sécurité sociale toutes les déclarations requises jusque et y compris celles relatives au trimestre civil visé à l'alinéa précédent, et 2° n'a pas pour ces déclarations une dette en cotisations supérieure à 3.000 euros, ou a obtenu pour cette dette des délais de paiement qu'il respecte strictement. Toutefois, même si la dette en cotisations est supérieure à 3.000 euros, le candidat ou le

http://www.ejustice.just.fgov.be/cgi_loi/loi_a1.pl?DETAIL=2011071511%2FF&caller=list&row_id=1&numero=3&rech=4&cn=2011071511&table_name=LOI&nm=2011021058&la=F&chercher=t&dt=ARRETE+ROYAL&language=fr&fr=f&choix1=ET&choix2=ET&fromtab=loi_all&sql=dt+contains++%27ARRETE%27%2526+%27ROYAL%27+and+dd+%3D+date%272011-07-15%27and+actif+%3D+%27Y%27&ddda=2011&tri=dd+AS+RANK+&trier=promulgation&dddj=15&dddm=07&imgcn.x=27&imgcn.y=1#Art.61



P. 16

soumissionnaire sera considéré comme étant en règle s'il établit, avant la décision de sélectionner les candidats ou d'attribuer le marché, selon le cas, qu'il possède, à la fin du trimestre civil visé à l'alinéa 2, à l'égard d'un pouvoir adjudicateur au sens de l'article 2, 1°, de la loi ou d'une entreprise publique au sens de l'article 2, 2°, de la loi, une ou des créances certaines, exigibles et libres de tout engagement à l'égard de tiers pour un montant au moins égal, à 3.000 euros près, à celui pour lequel il est en retard de paiement de cotisations.

Pour les candidats et soumissionnaires belges, le pouvoir adjudicateur demandera directement cette information via le guichet électronique.

§ 2. Le candidat ou le soumissionnaire employant du personnel relevant d'un autre État membre de l'Union européenne et qui n'est pas visé au § 1er, joint à sa demande de participation ou à son offre, selon le cas, une attestation délivrée par l'autorité compétente certifiant que, suivant compte arrêté au plus tard à la date limite de réception des demandes de participation ou des offres, selon le cas, il est en règle à cette date avec ses obligations relatives au paiement des cotisations de sécurité sociale selon les dispositions légales du pays où il est établi. § 3. Lorsque le candidat ou le soumissionnaire emploie du personnel visé tant par le § 1er que par le § 2, les dispositions des deux paragraphes sont applicables. § 4. La production des attestations visées aux §§ 1er et 2 n'est pas requise lorsque le montant estimé du marché n'excède pas 30.000 euros. Le pouvoir adjudicateur s'enquiert dans ce cas de la situation du candidat ou du soumissionnaire afin de vérifier s'il est en règle par rapport aux obligations prévues au présent article. § 5. Le pouvoir adjudicateur peut s'enquérir de la situation du candidat ou du soumissionnaire assujetti à la sécurité sociale des travailleurs indépendants afin de vérifier s'il est en règle avec ses obligations en matière de paiement de ses cotisations de sécurité sociale. § 6. La production des attestations prévues aux paragraphes précédents lors du dépôt de l'offre n'est pas requise si elles avaient déjà été jointes à la demande de participation, pour autant qu'elles concernent la même période. 6° qui n'est pas en règle avec ses obligations relatives au paiement de ses impôts et taxes selon la législation belge ou celle du pays dans lequel il est établi, conformément aux dispositions de l'article 63; Art. 63. Le candidat ou le soumissionnaire 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. L'attestation porte 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. Est en règle par rapport aux obligations susmentionnées applicables en Belgique, le candidat ou le soumissionnaire qui n'a pas pour l'ensemble de ses obligations fiscales professionnelles une dette supérieure à 3.000 euros, à moins qu'il n'ait obtenu pour cette dette des délais de paiement qu'il respecte strictement. Toutefois, même si la dette fiscale professionnelle est supérieure à 3.000 euros, le candidat ou le soumissionnaire sera 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, à la fin de la période fiscale visée à l'alinéa 1er, à l'égard d'un pouvoir adjudicateur au sens de l'article 2, 1°, de la loi ou d'une entreprise publique au sens de l'article 2, 2°, de la loi, une ou des créances certaines, exigibles et libres de tout engagement à l'égard de tiers pour un montant au moins égal, à 3.000 euros près, à celui pour lequel il est en retard de paiement de ses dettes fiscales professionnelles.




P. 17

Pour les candidats ou soumissionnaires belges, le pouvoir adjudicateur demandera directement cette information via le guichet électronique.

7° 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. Lorsqu'un document ou attestation visé aux 1° et 2° de l'alinéa premier de l’article 61 n'est pas délivré dans le pays concerné ou ne mentionne pas tous les cas visés au § 1er et au § 2, 1°, 2° ou 3° du même article 61, il peut être remplacé par une déclaration sous serment ou, dans les pays où un tel serment n'existe pas, par une déclaration solennelle faite par l'intéressé devant une autorité judiciaire ou administrative, un notaire ou un organisme professionnel qualifié du pays d'origine ou de provenance.

I.17.2 Critères de sélection qualitative

I.17.2.1 Critères de sélection relatifs aux moyens économiques et financiers du soumissionnaire

1° par des déclarations bancaires appropriées établies conformément au modèle figurant à l'annexe 3 de l’A.R 15/07/2011 ou, le cas échéant, par la preuve d'une assurance des risques professionnels; 2° par les comptes annuels ou les comptes annuels déposés, lorsque la législation du pays où est établi le candidat ou le soumissionnaire en prescrit le dépôt; 3°Le soumissionnaire fournit la preuve de sa capacité économique et financière par le biais de son chiffre d'affaires relatif aux activités sur lesquelles porte le marché et réalisées au cours des trois derniers exercices comptables. Minimum : 1.700.000 €/an

Si pour une raison justifiée, le candidat ou le soumissionnaire n'est pas en mesure de fournir les références demandées, il est admis à prouver sa capacité économique et financière par tout autre document considéré comme approprié par le pouvoir adjudicateur.

I.17.2.2 Critères de capacité technique

Dans le cas d'un marché de services/fournitures, la capacité technique ou professionnelle du candidat ou du soumissionnaire peut être justifiée d'une ou de plusieurs des façons suivantes, selon la nature, la quantité ou l'importance et l'utilisation des services/fournitures. Premier critère relatif à la capacité technique du soumissionnaire. Le soumissionnaire prouvera la réalisation de deux projets comparables au moins, pour un nombre d’utilisateurs internes comparable (les projets réalisés au sein de la société du soumissionnaire ou au sein de la/des société(s) du/des sous-traitant(s) ne sont pas pris en compte pour ce critère). À cet effet, il fournira une liste des marchés les plus importants accomplis au cours des trois dernières années. Il fournira également une liste des projets similaires réalisés au cours de la même période, et indiquera les instances publiques et privées pour lesquelles ces projets ont été réalisés. Lorsqu'il s'agit de services aux pouvoirs publics, la preuve sera fournie par des certificats qui seront émis ou signés par l'autorité compétente. Lorsqu’il s’agit de services à des personnes privées, la preuve sera fournie par des certificats émanant de ces personnes. À défaut de ces certificats, le soumissionnaire peut certifier lui-même la réalisation de ces prestations. Le soumissionnaire précisera la date, le montant total du marché, ainsi que les coordonnées d’une personne de contact au sein de la société ou de l’organisation concernée. L’utilisation du modèle « modèle de référence » (voir annexe du cahier de charges : modèle de référence ) est obligatoire pour la présentation des références.


P. 18

Deuxième critère relatif à la capacité technique du soumissionnaire. Le soumissionnaire mentionnera tout recours à la sous-traitance avec indication de la part du marché qui est sous-traitée ainsi que le nom des sous-traitants.

I.17.3 Régularité des offres

Les offres des candidats sélectionnés seront examinées sur le plan de leur régularité conformément aux articles 89 et suivants de l'arrêté royal du 8 janvier 1996 et aux dispositions du présent cahier spécial des charges. Les offres irrégulières seront exclues. Chaque proposition sera examinée afin de s’assurer qu’elle soit conforme aux besoins exprimés. S'il est déterminé qu'un besoin exprimé n'a pas été satisfait, l'offre peut être considérée comme étant irrégulière. La solution proposée dans l’offre du soumissionnaire doit satisfaire aux besoins techniques présupposés qui peuvent être trouvés dans ce cahier des charges. Chaque proposition financière ou offre de prix incomplète ou contenant des contradictions ou des erreurs importantes, ou qui ne respecte pas les exigences en matière de présentation du prix, telles que formulées dans le cahier spécial des charges, peut être considérée comme irrégulière. Seules les offres reconnues régulières seront prises en considération pour être confrontées aux critères d’attribution.

I.17.4 Critères d’attribution

Le choix de l'offre la plus avantageuse sera fait par le SPF Finances sur la base des données et des renseignements qui sont joints à l'offre par le soumissionnaire et sur la base des critères décrits ci-après. Le soumissionnaire joindra à son offre, tous les renseignements nécessaires à l'évaluation de son offre à la lumière des critères d'attribution et de leurs sous-critères éventuels, comme détaillé ci-dessous. Tous les critères (et tous les sous-critères éventuels) reçoivent un coefficient de pondération par lequel le score obtenu sera multiplié. Les critères mentionnés ci-dessous sont les seuls qui seront utilisés pour effectuer le choix parmi les offres. Les critères qui suivent sont d'application lors de l'attribution du marché :

Critères Pondération

Prix 35

Concrétisation fonctionnelle des besoins des utilisateurs apportée par la solution proposée (§ III.4.3)

32

relativement aux exigences nécessaires (P1) 27

relativement aux exigences souhaitées (P2) 3

garantie de réalisation des exigences futures (P3) 2

Approche de la coopération et le transfert des connaissances et de l'information 18

Transfert de connaissance (formations) (§ III.6) 3

Collaboration et coaching (§ III.6.2) 5

Transférabilité (§ III.6.4) 10

Concrétisation des aspects techniques (§ III.4.5) 8


P. 19

Maintenance et support (III.6.5), SLA (III.6.6) 5

Qualité générale de l'offre 2

Les offres suivantes n'entrent pas en ligne de compte pour l'attribution du marché : Les offres qui n’obtiennent pas 60 % de la totalité des points, à l’exception du critère prix.

Le critère « Prix» a été pondéré comme suit :

dont :

Prmin = prix le plus bas des offres jugées régulières entrant en ligne de compte pour l’attribution du marché

Proffre = prix de l’offre

P = points octroyés au critère « Prix »

Pmax = pondération du critère « Prix » La détermination du score final se fait comme suit: Les cotes relatives aux critères d’attribution susmentionnés, y compris celle du prix, seront additionnées. Le marché sera octroyé au soumissionnaire qui obtient le score final le plus élevé.

offre

P P Pr

Pr min max


P. 20

II. Dispositions contractuelles Cette deuxième partie fixe la procédure relative à l’exécution du marché. Pour autant qu’il n’y soit pas dérogé, l’Arrêté royal du 14 janvier 2013 et ses modifications ultérieures établissant les règles générales d’exécution des marchés publics de travaux, de fournitures et de services et des concessions de travaux publics est d’application, de même que les dispositions de l’annexe à cet arrêté royal relative au cahier général des charges, et ses modifications ultérieures.

II.1 Le bon de commande et ses modalités Le bon de commande est adressé à l’adjudicataire et ce, soit par courrier recommandé, soit par fax, soit via tout autre support permettant de définir la date d'envoi de façon certaine. Les échanges de correspondance subséquents relatifs au bon de commande (et à l’exécution des services) suivent les mêmes règles que celles prévues pour l’envoi du bon de commande chaque fois qu’une partie désire se ménager la preuve de son intervention. En cas de réception du bon de commande postérieure au délai de deux jours ouvrables, le délai de livraison peut être prorogé au prorata du retard constaté pour la réception du bon de commande, à la demande écrite et justifiée de l’adjudicataire. Si le service commandeur, après avoir examiné la demande écrite de l’adjudicataire, l’estime fondée ou partiellement fondée, il lui communique par écrit quelle prorogation de délai est acceptée. En cas de libellé manifestement incorrect ou incomplet du bon de commande empêchant toute exécution de la commande, l’adjudicataire en avise immédiatement par écrit le service commandeur afin qu’une solution soit trouvée pour permettre l’exécution normale de la commande. Si nécessaire, l’adjudicataire sollicite une prorogation du délai de l’exécution dans les mêmes conditions que celles prévues en cas de réception tardive du bon de commande. En tout état de cause, les réclamations relatives au bon de commande ne sont plus recevables si elles ne sont pas introduites dans les 15 jours calendrier à compter du premier jour qui suit celui où l’adjudicataire a reçu le bon de commande.

II.2 Fonctionnaire dirigeant L'exécution et la surveillance des services se déroulent sous le contrôle du fonctionnaire dirigeant : Nom : Noel Colpin, Administrateur général de l’Administration générale des Douanes et Accises Adresse : Boulevard du Roi Albert II 33, 1030 Bruxelles

II.3 Cautionnement Le cautionnement suivant est exigé : 5 % du montant initial du marché (hors TVA), arrondi à la dizaine supérieure. 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 loi du 22 mars 1993 relative au statut et au contrôle des


P. 21

établissements de crédit ou par une entreprise d’assurances satisfaisant au prescrit de la loi du 9 juillet 1975 relative au contrôle des entreprises d’assurances et agréée pour la branche 15 (caution). L’adjudicataire doit, dans les trente jours de calendrier suivant le jour de la conclusion du marché, justifier la constitution du cautionnement par lui-même ou par un tiers, de l’une des façons suivantes :

1° lorsqu'il s'agit de numéraire, par le virement du montant au numéro de compte de la Caisse des Dépôts et Consignations (CCP n° 679-2004099-79, IBAN: BE58 6792 0040 9979 , BIC: PCHQBEBB) ou d'un organisme public remplissant une fonction similaire à celle de ladite Caisse, ci-après dénommé organisme public remplissant une fonction similaire;

2° lorsqu'il s'agit de fonds publics, par le dépôt de ceux-ci entre les mains du caissier de l'État au siège de la Banque nationale à Bruxelles ou dans l'une de ses agences en province, pour compte de la Caisse des Dépôts et Consignations, ou d'un organisme public remplissant une fonction similaire;

3° lorsqu'il s'agit d'un cautionnement collectif, par le dépôt par un organisme exerçant légalement cette activité, d'un acte de caution solidaire auprès de la Caisse des Dépôts et Consignations ou d'un organisme public remplissant une fonction similaire;

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

Cette justification se donne, selon le cas, par la production au pouvoir adjudicateur :

1° soit du récépissé de dépôt de la Caisse des Dépôts et Consignations ou d'un organisme public remplissant une fonction similaire;

2° soit d'un avis de débit remis par l'établissement de crédit ou l'entreprise d'assurances; 3° soit de la reconnaissance de dépôt délivrée par le caissier de l'État ou par un organisme public

remplissant une fonction similaire; 4° soit de l'original de l'acte de caution solidaire visé par la Caisse des Dépôts et Consignations

ou par un organisme public remplissant une fonction similaire; 5° soit de l'original de l'acte d'engagement établi par l'établissement de crédit ou l'entreprise

d'assurances accordant une garantie. Ces documents, signés par le déposant, indiquent au profit de qui le cautionnement est constitué, son affectation précise par l’indication sommaire de l’objet du marché et de la référence du cahier spécial des charges, 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. Lorsque l'adjudicataire ne constitue pas le cautionnement dans le délai prévu à l'article 27, il est mis en demeure par lettre recommandée. Cette mise en demeure vaut procès-verbal au sens de l'article 44, § 2. Lorsqu'il ne constitue pas le cautionnement dans un dernier délai de quinze jours prenant cours à la date d'envoi de la lettre recommandée, le pouvoir adjudicateur peut : 1° soit constituer le cautionnement d'office par prélèvement sur les sommes dues pour le marché considéré. Dans ce cas, est appliquée une pénalité fixée à deux pour cent du montant initial du marché; 2° soit appliquer une mesure d'office. En toute hypothèse, la résiliation du marché pour ce motif exclut l'application de pénalités ou d'amendes pour retard. Lorsque le cautionnement a cessé d'être intégralement constitué et que l'adjudicataire demeure en défaut de combler le déficit, le pouvoir adjudicateur peut opérer une retenue égale au montant de celui-ci sur les paiements à faire et l'affecter à la reconstitution du cautionnement. Le délai de trente jours de 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ées et les jours de repos


P. 22

compensatoire prévus par voie réglementaire ou dans une convention collective de travail rendue obligatoire. Ces périodes sont mentionnées et prouvées dans l'offre ou sont immédiatement communiquées au pouvoir adjudicateur dès qu'elles sont connues. La preuve de la constitution du cautionnement doit être envoyée à l’adresse suivante :

SPF Finances Service d'encadrement B&CG Division Engagements Boulevard du Roi Albert II 33 bte 785 1030 Bruxelles

La demande par l'adjudicataire de procéder à la réception : 1° en cas de réception provisoire : tient lieu de demande de libération de la première moitié du cautionnement; 2° en cas de réception définitive : tient lieu de demande de libération de la seconde moitié du cautionnement, ou, si une réception provisoire n'est pas prévue, de demande de libération de la totalité de celui-ci. Dans la mesure où le cautionnement est libérable, le pouvoir adjudicateur délivre mainlevée à la Caisse des Dépôts et Consignations, à l'organisme public remplissant une fonction similaire, à l'établissement de crédit ou à l'entreprise d'assurances, selon le cas, dans les quinze jours qui suivent le jour de la demande. Au-delà de ce délai, l'adjudicataire a droit au paiement : 1° soit d'un intérêt qui, en cas de versement en numéraire ou en fonds publics, est calculé sur les montants déposés conformément à l'article 69, § 1er, déduction faite, s'il échet, de l'intérêt versé par la Caisse de Dépôts et Consignations ou par un organisme public remplissant une fonction similaire. La demande de mainlevée du cautionnement vaut, dans ce cas, déclaration de créance pour le paiement dudit intérêt; 2° soit des frais exposés pour le maintien du cautionnement, en cas de cautionnement collectif ou d'une garantie accordée par un établissement de crédit ou par une entreprise d'assurances.

II.4 Caractère livrable du système proposé Les éventuels appareils, le logiciel système (sauf les pièces spécifiques développées au cours du projet) et les programmes d'application proposés doivent être officiellement disponibles et livrables lors de l'introduction de l'offre. Leur entretien éventuel doit également être disponible (il ne peut dès lors pas s'agir de versions β du logiciel, de pré-releases, etc. …).

II.5 Exécution du marché

II.5.1 Clause d’évolution technologique

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

II.5.2 Délais d’exécution


P. 23

Dans ce projet, un certain nombre de décisions GO/NO GO ont été incluses (voir à ce sujet la partie III.5.2 du cahier spécial des charges). Celles-ci peuvent par conséquent donner lieu à la cessation du marché, mais sans préavis. La cessation du contrat à la condition susmentionnée n'entraîne pas de droit, pour l'adjudicataire, à une indemnité.

II.5.3 Lieu d’exécution du marché et particularités

II.5.3.1 L’exécution des services

L'exécution du marché se déroulera principalement à Service d'Encadrement ICT. Si, au cours de certaines périodes, il fallait travailler en autres lieux, les frais de déplacement ne seraient en principe pas remboursés par le SPF Finances. Une partie des services peut aussi être exécutée dans les locaux de l’adjudicataire si la prestation n’est pas possible ailleurs ou si le SPF Finances en tire un avantage particulier. 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 des Finances. Par “heures de bureau normales”, nous entendons les jours ouvrés, du lundi au vendredi, de 7h30 à 18h00, 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 chaque année.

II.5.3.2 Livraisons

Livraisons et installation L’adjudicataire doit fournir au SPF Finances tous les renseignements et facilités nécessaires pour que la préparation et l’exécution des livraisons puissent être contrôlées. Aucune livraison ne peut être faite sans qu'un avis en ait été donné, par écrit, aux services destinataires au moins quatre jours ouvrables avant la date d'expédition des marchandises ou de l’installation du logiciel, sauf avis contraire explicite du pouvoir adjudicateur. L'équipement (logiciel) sera fourni et installé par l'adjudicataire, conformément à un calendrier détaillé à convenir de commun accord après l'avis d'adjudication du marché. Les locaux d’installation seront aménagés par le SPF Finances conformément aux prescriptions énoncées dans l’offre remise par l’adjudicataire. Spécifications techniques Les livraisons et services doivent correspondre en tous points avec les plans, documents et domaines applicables à ce marché. Même en cas de défaut de spécification technique contractuelle, les livraisons et services doivent satisfaire à toutes les exigences et règles de bonne exécution. Emballages Les emballages éventuels demeurent la propriété de l’adjudicataire et sont enlevés par lui dans les dix jours calendrier à compter de la date de livraison. Passé ce délai, le SPF Finances est en droit de renvoyer ces emballages aux frais de l’adjudicataire. Le matériel sera déballé dans les locaux désignés par le destinataire et selon ses instructions. Lieu


P. 24

Les livraisons se feront à Service d'Encadrement ICT

II.5.4 Personnel de l’adjudicataire

Pour ce marché, l’adjudicataire devra désigner un chef de projet (également décrit, dans le cadre de PMfin

2, 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 et de support technique doit en outre pouvoir :

communiquer avec aisance dans les deux langues.

Le personnel de l’adjudicataire devra satisfaire à toutes les dispositions légales en vigueur en Belgique en matière d'immigration et de permis de travail. L’adjudicataire garantira le SPF Finances contre tout dommage généralement quelconque que le SPF Finances pourrait subir du fait du non-respect par l’adjudicataire ou les membres de son personnel des dispositions légales en question.

L’adjudicataire doit disposer de suffisamment de personnel possédant les connaissances nécessaires et adaptées à l’exécution des tâches. Le personnel concerné doit également disposer d'une connaissance suffisante des outils utilisés dans le cadre du projet. Les adjudicataires doivent être capables de répondre immédiatement aux besoins résultant de l’attribution du marché. L’équipe de projet mise à disposition par l’adjudicataire doit être suffisante afin de mener à bien les missions qui lui sont confiées. Le personnel affecté à l'exécution du marché doit être le même que celui proposé dans l'offre. A défaut, le personnel mis à disposition pour l'exécution sera de niveau et d’expérience équivalents. Le SPF Finances devra marquer son accord sur la composition de l'équipe proposée pour le projet. 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.

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

Le changement devra intervenir dans les 10 jours ouvrables de la demande du SPF Finances, et ce sans frais à dater de la notification de l’incident au soumissionnaire. Les soumissionnaires doivent joindre à leur offre, le curriculum vitae (obligatoire selon le modèle de « curriculum vitae ») des personnes amenées à réaliser le marché. L’offre devra contenir une

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

reconnue Prince2


P. 25

proposition claire concernant la composition réelle de l’équipe de projet et le type de profils qui participeront à la réalisation du marché.

Un certain nombre de personnes pourront être proposées par profil, mais le soumissionnaire devra indiquer combien et quels membres du personnel feront partie de l’équipe de projet réelle. La liste des membres du personnel proposés (effectifs et suppléants éventuels) sera considérée comme une liste exhaustive comprenant tous les membres du personnel susceptibles de faire partie de l’équipe de projet.

II.5.5 Sous-traitants

Le fait que l'adjudicataire confie tout ou partie de ses engagements à des sous-traitants ne dégage pas sa responsabilité envers le pouvoir adjudicateur. Le pouvoir adjudicateur n'a aucun lien contractuel avec ces tiers. Toutefois, le pouvoir adjudicateur exige que les sous-traitants de l'adjudicataire satisfassent en proportion de leur participation au marché aux exigences minimales de capacité financière et économique et de capacité technique et professionnelle imposées par les documents du marché. L'adjudicataire reste, dans tous les cas, seul responsable vis-à-vis du pouvoir adjudicateur. Dans les cas suivants, l'adjudicataire a l'obligation de faire appel à certains sous-traitants, le recours à d'autres sous-traitants étant soumis à l'autorisation du pouvoir adjudicateur : 1° lorsque l'adjudicataire a, pour sa sélection qualitative, utilisé la capacité de certains sous-traitants conformément à l'article 74 de l'arrêté royal secteurs classiques; 2° lorsque l'adjudicataire a proposé certains sous-traitants dans son offre conformément à l'article 12 de l'arrêté royal secteurs classique. 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.

II.5.6 Moyens mis à disposition par le SPF Finances

II.5.6.1 Moyens techniques

L’adjudicataire mettra à disposition de son personnel tout le matériel nécessaire à l’exécution de sa mission (ordinateur portable, etc.). On applique le principe que le SPF Finances mettra simultanément à la disposition des membres du personnel au cours de leur mission, au maximum 4 bureaux de type "shared desk", sans armoires. Le personnel de l’adjudicataire dispose d’un accès limité au réseau du SPF Finances, ainsi que d’une adresse e-mail. Le SPF Finances ne dispose pas d’emplacements de parking pour le personnel de l’adjudicataire. Le SPF Finances n'effectuera aucune adaptation aux postes de travail des membres du personnel de l'adjudicataire afin de les faire mieux fonctionner au sein de l'infrastructure du SPF Finances. L'adjudicataire ne peut en aucun cas modifier, perturber ou surcharger l'infrastructure du SPF Finances par l'ajout de postes de travail pour son personnel dans cette infrastructure, sauf pour ce qui est directement associé au développement de l'application concernée.


P. 26

L'adjudicataire est intégralement responsable de la protection des postes de travail concernés contre les virus et de la gestion de ces postes. Il utilisera de manière prioritaire les outils mis à sa disposition par le SPF Finances. Au cas où d'autres logiciels devraient être utilisés dans le cadre du projet, leur utilisation se déroulera, après acceptation par le comité de pilotage, sous la responsabilité de l'adjudicataire et le coût de cette utilisation sera compris dans le prix des services. Le personnel de l’adjudicataire devra suivre les procédures internes et les règlements relatifs à l’utilisation des moyens mis à sa disposition et à leur accès, et ne peut exiger aucun ajout ou modification à l’environnement de travail du pouvoir adjudicateur. Si des manquements dans le soutien logistique entraînent des perturbations de service, il devra être fait appel aux moyens d’arbitrage décrit dans le point « Moyens d’actions de l’administration – Litiges » avant de faire appel au droit.

II.5.6.2 Tâches des collaborateurs du SPF Finances

Les collaborateurs du SPF Finances participent au(x) projet(s) pour ce qui concerne :

la définition du contenu du projet ;

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

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

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

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

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

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

II.5.7 Normes et standards à respecter

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

les normes techniques pour logiciels ;

la méthode de gestion de projet (PMFin, une méthodologie de projet unique au sein du SPF Finances qui est basée sur la méthode internationalement reconnue Prince2) ;

la tenue de la documentation ;

les règles de programmation (création, structures des codes, commentaires, conventions en matière de dénomination, standards de développement conformément aux fondements ICT, y compris les standards ouverts, etc.);

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

les procédures pour les garanties de base Toutes les normes utilisées par le SPF Finances figurent dans un document explicatif, disponible sur http://minfin.fgov.be/portail2/fr/modernisation/ict.htm#B (sous « Fondements

http://minfin.fgov.be/portail2/fr/modernisation/ict.htm#B


P. 27

ICT (SPF Finances) ») et http://minfin.fgov.be/portail2/nl/modernisation/ict.htm#B (sous “ICT Fundamenten (FOD Financiën)”) . Toute référence à quelque norme ou méthodologie que ce soit dans le présent cahier des charges dépend de la description exacte dans le document officiel présent sur ce site. Seul le comité tactique est compétent au sein du SPF Finances pour modifier ou ajouter des normes et méthodologies. Si l’adjudicataire a besoin de l’approbation d’une nouvelle norme, il devra en introduire la demande auprès du comité tactique et entièrement se soumettre à sa décision.

II.5.8 Gestion des changements (« change management »)

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

L’adjudicataire ne facturera aucun coût additionnel pour l’étude ou la préparation d’un

rapport sur une proposition de modification. Procédure Sous réserve de l’article 37 de l’arrêté royal du 14 janvier 2013, une modification de contrat ne sera contraignante que si elle a été proposée, traitée et entérinée conformément à la présente disposition. Si une des parties désire apporter des modifications au contrat, elle devra transmettre les détails de cette modification à l’autre partie par écrit.

Article 37 Quel que soit le mode de détermination des prix, le pouvoir adjudicateur a le droit d'apporter unilatéralement des modifications au marché initial pour autant qu'il soit satisfait aux conditions cumulatives suivantes : 1° l'objet du marché reste inchangé; 2° hormis l'application des articles 26, § 1er, 2°, a) et b), et 3°, b) et c), et 53, § 2, 2° et 4°, a) et b), de la loi, la valeur de la modification est limitée à quinze pour cent du montant initial du marché;

http://minfin.fgov.be/portail2/nl/modernisation/ict.htm#B


P. 28

3° une juste compensation est accordée à l'adjudicataire, s'il y a lieu. Il ne peut toutefois être dérogé aux clauses et conditions essentielles du marché que de façon motivée, et ce : 1° soit par un ordre modificatif ou toute autre décision unilatérale du pouvoir adjudicateur; 2° soit par un avenant.

Si le SPF Finances propose une modification, l’adjudicataire devra transmettre au SPF Finances, dans un délai raisonnable et sans surcoût, une estimation du temps nécessaire prévu pour la mise en œuvre de la modification et de l’effet attendu de ladite modification au niveau du contrat. Si le SPF Finances décide de ne pas appliquer cette modification, aucune modification ne sera apportée au contrat. Si le SPF Finances désire appliquer cette modification et si les deux parties acceptent la proposition de modification, elles définiront conjointement la modification ainsi que les conséquences de cette modification au niveau des modalités d’acceptation dans une « annexe au contrat » qu’elles signeront. L’adjudicataire exécutera immédiatement la modification convenue conformément aux stipulations de cette annexe. Si l’adjudicataire propose une modification en vue de l’amélioration du résultat du marché, le SPF Finances devra examiner cette proposition. Si les deux parties acceptent la proposition de modification, elles définiront conjointement la modification ainsi que les conséquences de cette modification au niveau des modalités d’acceptation dans une « annexe au contrat » qu’elles signeront. L’adjudicataire exécutera immédiatement la modification convenue conformément aux stipulations de cette annexe.

II.5.9 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'il aurait pu obtenir lors de l'exécution de ce marché. Ces informations ne pourront en aucun cas être communiquées à des tiers sans accord écrit de la part du pouvoir adjudicateur. L’adjudicataire est autorisé à mentionner le présent marché dans ses références. Tous les renseignements dont le personnel de l ’adjudicata ire 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.


P. 29

L’adjudicataire se porte garant du respect de la confidentialité de ces informations par son personnel et ses sous-traitants. Il s’engage à ne pas les divulguer à des tiers, en ce compris les filiales et autres entreprises liées à l’adjudicataire. Il ne communiquera à son personnel et à celui de ses sous-traitants directement impliqués au marché, uniquement les données nécessaires à l'exécution de leur tâche, dans le cadre du présent marché. Les obligations énoncées ci-dessus ne sont pas applicables aux informations du SPF Finances :

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

qui, au moment où elles ont été connues par le SPF Finances, étaient déjà publiques ;

qui, après qu'elles aient été connues par le SPF Finances, ont été rendues publiques autrement que par le fait de l’adjudicataire ; ou

que l’adjudicataire a obtenues d'un tiers qui disposait de bonne foi des informations du SPF Finances et qui était autorisé à les communiquer à l’adjudicataire.

L’adjudicataire s'engage :

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

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

Toute l'information mise à la disposition de l’adjudicataire par le SPF Finances et tout support d'information, contenant de l'information du SPF Finances, mis à la disposition de l’adjudicataire par le SPF Finances reste l'entière propriété du SPF Finances. Même si l’adjudicataire a copié ou consigné ces informations ou une partie de celles-ci, elles demeurent la propriété intégrale du SPF Finances. Le SPF Finances a le droit, à tout moment, de demander à l’adjudicataire de lui remettre tout ou partie des supports d’information sur lesquels l’adjudicataire aura stocké de l’information du SPF Finances. L’adjudicataire s’engage à remettre immédiatement les supports réclamés sans les copier. L’adjudicataire s’engage à remettre au SPF Finances, à l’issue de l’exécution du marché et sans délai, tous les supports d’information qui contiennent de l’information du SPF Finances et qui ont été mis à la disposition de l’adjudicataire pour l’exécution du marché, pour autant que ces supports d’information n’aient pas déjà été remis au SPF Finances. Toute information du SPF Finances restera la propriété du SPF Finances. Par la mise à disposition d’informations du SPF Finances, celui-ci ne concède à l’adjudicataire, ni explicitement ni implicitement, aucun droit à licence sur les droits de brevet, droits d’auteur ou autres droits intellectuels. L’adjudicataire s'engage à ne pas appliquer industriellement l'information du SPF Finances et à ne pas l'utiliser pour d'autres fins que l'exécution du présent marché ou d'une mission à lui confiée par le SPF Finances dans le cadre du présent marché. L’adjudicataire est responsable de tout dommage dont le SPF Finances serait victime du fait du non-respect par lui-même ou par les membres de son personnel d’obligations qui lui incombent en vertu du présent article.


P. 30

II.5.10 Responsabilités

Responsabilité Fournitures Le fournisseur est responsable de ses fournitures jusqu'au moment où les opérations de vérification de la livraison sont effectuées, sauf si les pertes ou avaries survenant dans les dépôts du destinataire sont dues à des faits ou circonstances visés aux articles 54 et 56 de l’Arrêté royal du 14 janvier 2013. Responsabilité Services L’adjudicataire assume la pleine responsabilité des fautes et des omissions constatées dans les services fournis, spécialement dans les études, les calculs, les plans ou toute autre pièce qu’il fournit dans le cadre de l’exécution du marché. Les services qui ne satisfont pas aux clauses et conditions du marché ou qui ne sont pas exécutés conformément aux règles de l'art sont recommencés par le prestataire. A défaut, ils le sont d'office, à ses frais, risques et périls, sur l'ordre du pouvoir adjudicateur, suivant l'un ou l'autre des moyens d'action prévus à l'article 155. En outre, le prestataire de services est passible des amendes et pénalités pour inexécution des clauses et conditions du marché.

L’adjudicataire garantit que tous les services qui devront être exécutés dans le cadre du contrat seront exécutés conformément aux meilleures normes professionnelles, par un personnel suffisamment formé et compétent, en respectant les délais et budget prévus. L’adjudicataire a donc une obligation de résultat.

II.6 Suivi des services prestés et contrôles par des tiers

II.6.1 Suivi de la bonne exécution du marché

Le SPF Finances a le droit de maintenir une surveillance permanente sur les livraisons et les services qui sont exécutés par l’équipe impliquée dans l’exécution du marché. L’équipe d’exécution doit fournir aux représentants du SPF Finances tous les renseignements et facilités afin de remplir cette tâche. Les plans, spécifications, dossiers, etc. sont établis, dans le cadre de ce marché, par le personnel de l’adjudicataire. Ils doivent avoir été approuvés par le SPF Finances avant exécution. Le SPF Finances dispose d’un délai de 20 jours calendrier afin d’approuver ces documents ou de formuler des remarques. En cas de remarques, les documents concernés doivent être corrigés avant l'exécution et sans que ces corrections n'aient comme conséquence une révision des délais d'exécution planifiés, à moins que les remarques ne proviennent de nouvelles exigences de la part du SPF Finances. Tout dépassement du terme planifié pour l’acceptation d’un document mène, à la demande de l’adjudicataire concerné, à un prolongement du délai d’exécution. Le fait qu'un retard puisse être imputé au SPF Finances ne dégage pas l'adjudicataire de son obligation de veiller à en réduire les conséquences. L’adjudicataire ne peut pas faire appel au fait que cette surveillance a été exécutée, dans le but de se soustraire à sa responsabilité au cas où les fournitures ou les prestations seraient refusées pour cause de manquements de quelque nature que ce soit et que dès lors des délais d’exécution prolongés en découleraient.


P. 31

II.6.2 Contrôles par des tiers

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

II.7 Évaluation des services prestés et opérations de vérification Le SPF Finances procédera aux opérations de vérification complète des équipements constitutifs de chacune des étapes de réalisation telles qu’elles sont définies dans le calendrier de réalisation du projet dans les 20 jours calendrier qui suivent la notification, par l’adjudicataire, de leur achèvement. Ces opérations porteront sur l'adéquation et sur le bon fonctionnement des équipements. La vérification d’aptitude a pour but de constater que les installations répondent aux quantités et spécifications imposées par le SPF Finances. Le contrôle du bon fonctionnement a pour but de constater que les équipements sont capables d’assurer un fonctionnement correct dans des conditions normales d’exploitation (en d’autres termes que l’installation satisfait aux niveaux de services préétablis). Les activités de contrôle comprennent notamment :

L’établissement du fait que les livraisons et les services associés ont été effectués;

Le contrôle que toutes les fonctionnalités sont opérationnelles et paramétrées;

Le contrôle des capacités de prestation en termes de performance, de sécurité, de robustesse, de capacité de charges, etc.

L’installation éventuelle d’outils de test afin de pouvoir exécuter les contrôles mentionnés plus haut

Le contrôle de la livraison de la documentation. Si les équipements satisfont aux contrôles prévus à cette fin dans les délais fixés, ils seront considérés comme appropriés et fonctionnant bien. Le calendrier des activités de contrôle sera fixé de commun accord.

Si lors des opérations de vérification, les performances et/ou des fonctionnalités requises dans le cahier spécial des charges et/ou annoncées dans l’offre ainsi que dans ses documents complémentaires, ne sont pas rencontrées ou ne le sont que partiellement, l’adjudicataire s’engage à effectuer à ses frais les modifications ou compléments nécessaires ou à remplacer tout ou partie des fournitures logicielles par la livraison de fournitures conformes, ceci dans les 20 jours calendrier qui suivent la date du procès-verbal de constatation de l’impossibilité de prononcer la réception provisoire. Au-delà de ce délai, le SPF se réserve le droit d’appliquer les amendes pour retard. Dans cette hypothèse, après que l’adjudicataire aura effectué les modifications, les compléments ou remplacements nécessaires, l’ensemble des tests de réception devra être ré-exécuté. Si les équipements sont jugés inappropriés et/ou ne fonctionnent pas bien dans les délais fixés, le SPF Finances peut :


P. 32

soit appliquer les mesures d’office prévues aux articles 47 et 124 (fournitures) / 47 et 155 (services) de l’arrêté royal du 14 janvier 2013 ;

soit convenir avec l’adjudicataire de dispositions particulières.

II.8 Réception provisoire A l’issue des opérations de vérification qui se sont déroulées avec succès, le SPF Finances dressera un procès-verbal de réception provisoire des équipements couverts par l'étape concernée. Le procès-verbal de livraison provisoire sera signé par les deux parties. A noter qu’aucune réception ne pourra être accordée si les tests de régression ne sont pas concluants. Si les services qui font partie de ce marché se composent de prestations purement intellectuelles, telles que des études, analyses ou autres rapports de consultance, la réception provisoire sera considérée comme réception définitive. La (les) réception(s) provisoire(s) (partielle(s)) aura (auront) lieu au(x) moment(s) suivant(s) : - Itération R0 - Itération R1 - Itération R2 Dans le cas où la réception provisoire partielle d'un nouveau module a un impact sur un module qui a été réceptionné avant, les modifications devront être apportées à celui-ci aux frais de l’adjudicataire avant que le SPF Finances accepte la réception provisoire partielle de ce nouveau module. La (Les) réception(s) provisoire(s) (partielle(s)) sera (seront) actée(s) dans un procès-verbal signé par l’adjudicataire et par le SPF Finances. La demande de l’adjudicataire comportera au moins une proposition de procès-verbal pour cette (ces) réception(s) provisoire(s) (partielle(s)). Le SPF Finances dispose d’un délai de 30 jours calendrier, à dater de la demande de l’adjudicataire, pour approuver, amender ou refuser le procès-verbal proposé. L’acceptation signifie que la réception est accordée.

II.9 Garantie

Toute constatation d'avarie ou de mise hors service fait l'objet d'un procès-verbal daté et signé par le fonctionnaire dirigeant. Ce procès-verbal est dressé avant l'expiration du délai de garantie et notifié au plus tôt à l'adjudicataire dans un délai de trente jours de la constatation. La mise en cause de la responsabilité de l'adjudicataire est subordonnée à l'accomplissement de ces formalités.

Dans cette section, le terme « élément » fait référence à toute méthodologie, équipement ou logiciel et, par extension, à tout ce qui relève de la période de garantie et/ou de maintenance et qui a été développé/livré par l’adjudicataire et fait partie du présent marché. Après chaque réception provisoire partielle, la période de garantie d’un élément débute ; elle se termine 1 année après la dernière réception provisoire. Cela signifie donc que, par exemple, la garantie de l'itération R0 dure jusqu'à un an à compter de la livraison de R2. La garantie de chaque réception se termine donc un an après la réception provisoire globale. Si des éléments sont défectueux, si les fonctions et/ou les prestations et/ou le respect du SLA (Service Level Agreement – accord sur le niveau des services), prescrits dans le cahier des charges ou annoncés dans l’offre de l’adjudicataire, ne sont pas satisfaisants ou ne le sont qu’en partie, dans


P. 33

la mesure où les défauts ne sont pas la conséquence d’une utilisation anormale des éléments, l’adjudicataire s'engage à effectuer toutes les réparations ou corrections nécessaires à ses frais ou à remplacer, le cas échéant, les éléments défectueux dans les délais indiqués dans les spécifications du SLA. Pendant les périodes de garantie, les sanctions relatives au SLA s’appliquent. La garantie couvre notamment :

la réparation ou le remplacement, sur site, des éléments défectueux ;

la correction des paramètres ;

la durée des travaux prestés ;

les déplacements du personnel de l’adjudicataire. Les produits fournis en remplacement sont soumis au délai intégral de garantie. Le délai de garantie est prolongé, le cas échéant, à concurrence du laps de temps pendant lequel le produit n'a pu être utilisé du fait d'avarie. Le soumissionnaire doit veiller à mettre à jour les éléments pendant la période de garantie. Ces mises à jour se rapportent tant à d’éventuelles ‘corrections’ qu’aux évolutions de l’élément installé.

II.10 Réception définitive La réception définitive sera prononcée, à la demande de l’adjudicataire, après l’expiration de la période de garantie. La réception définitive sera enregistrée dans un procès-verbal signé par l’adjudicataire et par le SPF Finances. Le SPF Finances dispose d'un délai de 15 jours calendrier, à compter de la demande, pour dresser le procès-verbal d'acceptation qui donne l'autorisation de réception.

II.11 Modalités et frais de réception Modalités de réception Les services seront suivis de près pendant leur exécution et ce, par un ou plusieurs représentants du pouvoir adjudicateur. L'identité de ce(s) représentant(s) sera communiquée à l’adjudicataire au début de la prestation des services. Frais de réception Tous les frais se rapportant à la livraison et à la (aux) réception(s) provisoire(s) et/ou définitive(s) sont à charge de l’adjudicataire.

II.12 Propriété des softs développés L’adjudicataire reconnaît et accepte que tous les droits de propriété industrielle et intellectuelle (notamment, sans s’y limiter, les droits d'auteur, les droits sur les banques de données et les droits sur les modèles), ainsi que tous les droits de propriété et tous les autres droits relatifs aux services ou produits dans le cadre de la mission à exécuter, notamment, sans s’y limiter, les études, les schémas, les analyses, les plans, les rapports, les résultats d’enquêtes, la documentation, les méthodes, les banques de données, les concepts et tout autre développement, protégés ou non par un droit de propriété intellectuelle, deviennent la propriété exclusive du SPF Finances à partir du paiement des factures y afférents.


P. 34

L’adjudicataire s’engage à fournir au SPF Finances toute l’assistance requise, à remplir les formalités qui s’imposent et à entreprendre les démarches nécessaires afin d’assurer et de prouver la validité de la cession des droits précités. L’adjudicataire s’engage à et se fait fort de faire respecter cette obligation par ses employés, ses préposés et d’éventuels sous-traitants. Sans porter préjudice à l’obligation de l’adjudicataire de garder secrètes les informations sur le présent marché et les informations confidentielles, l’adjudicataire a le droit de réutiliser le savoir-faire ou l’expérience qu’il a acquis(e) dans le cadre de l’exécution du marché à d’autres fins que l’exécution du marché.

II.13 Facturation, paiement et révision des prix

II.13.1 Facturation et paiement

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 :

Pour les fournitures et services, tout le montant dû est facturé à la réception provisoire. Les acomptes ne sont pas possibles ; les paiements ne peuvent être effectués qu’a posteriori, pour des fournitures ou services déjà livrés et acceptés.

Les paiements périodiques relatifs à la maintenance seront facturés par échéances annuelles. Les droits de licence sont facturés chaque année au début du terme.

Les coûts relatifs aux services (complémentaire/de soutien) peuvent être facturés sur la base du temps presté (hommes-heures ou hommes-jours), dès leur accomplissement et leur acceptation. Une preuve des prestations fournies doit être jointe à la facture.

Pour les itérations R0 et R1 (suivant la description de la partie III), 60% du montant facturé seront payés après réception. Les 40% restants seront payés à la mise en production effective de SHERLOCK, après réception de l’itération R2.

La facture doit être établie en euros. L'adjudicataire envoie ses factures (en deux exemplaires) à l'adresse suivante : SPF Finances Service central de facturation Boulevard du Roi Albert II 33 bte 788 1030 Bruxelles Pour les fournitures Le paiement du montant dû au fournisseur est effectué dans les trente jours à compter de l'échéance du délai de vérification visé à l'article 120, alinéa 2, pour autant que le pouvoir adjudicateur soit, en même temps, en possession de la facture régulièrement établie ainsi que des autres documents éventuellement exigés. Pour les 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 visé à l'article 150, alinéa 3, conformément aux modalités fixées dans les documents du marché. Intérêt pour retard dans les paiements et indemnisation pour frais de recouvrement §1. Lorsque les délais fixés pour le paiement en vertu des articles 68, 95, 127, 141 et 160 sont dépassés, l'adjudicataire a droit au paiement, de plein droit et sans mise en demeure à un intérêt au prorata du nombre de jours de retard. Cet intérêt simple est soit le taux d'intérêt appliqué par la

http://www.ejustice.just.fgov.be/cgi_loi/loi_a1.pl?DETAIL=2013011409%2FF&caller=list&row_id=1&numero=8&rech=8&cn=2013011409&table_name=LOI&nm=2013021005&la=F&chercher=t&dt=ARRETE+ROYAL&language=fr&fr=f&choix1=ET&choix2=ET&fromtab=loi_all&sql=dt+contains++%27ARRETE%27%2526+%27ROYAL%27+and+dd+%3D+date%272013-01-14%27and+actif+%3D+%27Y%27&ddda=2013&tri=dd+AS+RANK+&trier=promulgation&dddj=14&dddm=01&imgcn.x=50&imgcn.y=17#LNKR0067


P. 35

Banque centrale européenne à ses opérations principales de refinancement les plus récentes soit le taux d'intérêt marginal résultant de procédures d'appel d'offres à taux variable pour les opérations principales de refinancement les plus récentes de la banque centrale européenne. Pour les marchés conclus à partir du 16 mars 2013, l'intérêt de retard visé est majoré de huit pour cent. Le ministre ayant les Finances dans ses attributions publie semestriellement le taux d'intérêt simple applicable pour chaque semestre dans le Moniteur belge. §2. Si, pour les marchés conclus à partir du 16 mars 2013 un intérêt de retard est dû conformément au paragraphe 1er, l'adjudicataire a droit au paiement, de plein droit et sans mise en demeure, d'une indemnité forfaitaire de quarante euros pour les frais de recouvrement. Outre ce montant forfaitaire, l'adjudicataire est en droit de réclamer une indemnisation raisonnable pour tous les autres frais de recouvrement éventuels encourus par suite du retard de paiement. §3. L'introduction de la facture régulièrement établie ou de la déclaration de créance conformément aux articles 95, 127, 141 et 160 vaut le cas échéant déclaration de créance pour l'intérêt visé au paragraphe 1er et pour les frais de recouvrement visés au paragraphe 2 mais ne porte pas préjudice au point de départ du cours de cet intérêt.

II.13.2 Révision des prix

Pour les fournitures, aucune révision de prix n'est autorisée. La révision des prix des services est possible. Les règles de révision sont les suivantes :

Les prix peuvent être revus annuellement. Chaque année, le prestataire demande la révision du prix par lettre recommandée adressée

au Pouvoir Adjudicateur, Service d'encadrement B&CG, Division Engagements, bd Roi Albert II 33 bte 785, 1030 Bruxelles.

La révision des prix entre en vigueur :

o le jour anniversaire de l'avis d'attribution du marché si le prestataire a introduit sa demande de révision avant cette date. La révision des prix ne concerne que les services effectivement prestés après l'anniversaire de l'attribution du marché.

o le 1er jour du mois qui suit l'envoi de la lettre recommandée si le prestataire a laissé passer un ou plusieurs anniversaires. La révision des prix ne concerne que les services effectivement prestés après la date visée ci-dessus (attention : l’adjudicataire doit introduire une nouvelle demande pour la révision des prix des services à prester après l'anniversaire suivant).

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

2.0*8,0*

0

0S

SPP

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


P. 36

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

Le pouvoir adjudicateur se réserve le droit de revoir les prix en cas de baisse de l'indice. Dans ce cas, la révision suit les règles ci-dessus, sauf que la lettre recommandée émane du pouvoir adjudicateur.

II.13.3 Clause du client le plus avantagé

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

II.14 Publicité - référencement Aucun avis, communiqué de presse, rapport informationnel de recherche, et/ou avis public semblable concernant ce projet ne peut être publié par l’adjudicataire ou par ses sous-traitants sans approbation écrite préalable d'un représentant autorisé du SPF Finances.

II.15 Livraisons en retard L'adjudicataire peut se prévaloir des carences, lenteurs ou faits quelconques qu'il impute au pouvoir adjudicateur ou à ses agents et qui lui occasionnent un retard et/ou un préjudice, en vue d'obtenir la prolongation des délais d'exécution, la révision ou la résiliation du marché et/ou des dommages-intérêts (articles 54 et 55, A.R. 14 janvier 2013). Le pouvoir adjudicateur peut se prévaloir des carences, lenteurs ou faits quelconques qu'il impute à l'adjudicataire ou à son personnel et qui lui occasionnent un retard et/ou un préjudice, en vue d’appliquer des amendes pour retard (article 46 A.R. 14 janvier 2013) ou d’appliquer les mesures d’offices prévues aux articles 47, 124 (fournitures) et 155 (services) de l’arrêté royal du 14 janvier 2013 Sous réserve des prescriptions concernant les mesures prévues d’office aux articles 47, 124 (fournitures) et 155 (services) de l’arrêté royal du 14 janvier 2013, et si la livraison d’une phase déterminée n’a pas eu lieu trois mois après la date d’exécution convenue, et si l’adjudicataire n’a pas, dans l’intervalle, obtenu une prolongation du délai de livraison, l’Administration se réserve le droit de résilier unilatéralement le marché (cf. article 47§2, 1° de l’arrêté royal du 14 janvier 2013). Dans ce contexte, la livraison doit être considérée comme une livraison de biens et de services.

II.16 Moyens de défense de l’administration - Litiges Les moyens d'actions du SPF Finances sont ceux prévus aux articles 44 et suivants de l’arrêté royal du 14 janvier 2013.

http://www.agoria.be/


P. 37

Le marché doit être élaboré, interprété 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 découlant des dispositions qui régissent le marché doivent être réglés en concertation.

Les parties devront préalablement à tout autre recours, essayer de régler l'affaire à l'amiable. A cette fin, la partie la plus diligente notifiera à l'autre partie par simple lettre recommandée la mauvaise exécution du contrat. Un mode de solution sera, si possible, joint à la notification. L'autre partie disposera d'un délai de 15 jours de calendrier à compter de l'envoi de la lettre recommandée pour en accuser réception et donner son accord sur la solution proposée.

A défaut d'accord et avant de faire valoir leurs droits en justice, les parties s'efforceront de trouver un compromis par la voie des négociations qui seront engagées dès qu'il est apparu que l'affaire ne peut être réglée à l'amiable. Les négociations se tiendront à l'adresse indiquée au point « fonctionnaire dirigeant » de la partie II en présence des personnes désignées à cette fin par les deux parties. Sauf accord contraire, les négociations ne pourront excéder une durée de 30 jours à dater 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 dégâts aux personnes ou aux 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 à cet égard.


P. 38

III. Description des exigences techniques

III.1 Introduction Le marché se compose de la fourniture d’un système informatique intégré, SHERLOCK, qui permettra aux agents des Douanes & Accises (D&A) de standardiser, de gérer efficacement et de suivre de manière ciblée l’enregistrement des infractions ainsi que le traitement des litiges correspondants et des dossiers de recouvrement. Le projet est motivé par plusieurs nécessités, dont:

maintenir voire améliorer la qualité des prestations;

faire face à la diminution des ETP en facilitant le travail des agents;

accélérer le traitement des dossiers;

supprimer les tâches répétitives et peu valorisantes;

unifier les méthodes de travail;

faciliter l’obtention et l’exploitation de statistiques fiables;

Cet outil vise essentiellement deux groupes cibles:

1. les agents de l’AGDA qui constatent et rapportent des infractions, que l’on qualifiera ci-dessous de « verbalisants », indépendamment de leur fonction et de leur rôle dans l’organisation;

2. les agents de l’Administration du Contentieux et du Recouvrement qui traitent les dossiers qui relèvent de leur compétence

3;

Les objectifs business à atteindre sont, en résumé:

1) Pour l’enregistrement des infractions:

o faciliter le travail des verbalisants en leur permettant de créer l’acte de constatation et de rassembler toutes les pièces du dossier infractionnel en un seul lieu virtuel, tout en limitant les encodages multiples actuels;

o s’assurer, autant que possible, du respect des formes, délais et prescrits légaux dans le traitement des infractions – en particulier, améliorer la qualité et la complétude des dossiers transmis à l’Administration du Contentieux et du Recouvrement;

2) Pour le traitement des dossiers contentieux et recouvrement:

o faciliter le travail des agents du contentieux en réalisant à leur place le plus grand nombre possible de tâches administratives et en évitant les encodages multiples actuellement pénalisants;

o s’assurer du respect des formes, délais et tous prescrits légaux dans le traitement des dossiers de contentieux;

o permettre aux chefs de service ou d’équipe de mieux gérer la charge de travail;

3) Mettre à disposition des statistiques opérationnelles fiables pour la gestion de l’Administration, le contrôle interne et l’analyse de risques;

4) Uniformiser autant que possible les documents et les procédures au niveau des constatations et du traitement du contentieux;

5) Améliorer la collaboration entre les services de contrôle et les services du contentieux et du recouvrement;

6) Participer à la mise à jour en temps réel de la comptabilité des dettes et des paiements ;

3 Les dossiers traités incluent, outre les infractions : les recours administratifs, l’assistance mutuelle, les

irrégularités, les citations émanant de tiers.


P. 39

Ce dernier objectif justifie la conception d’un système unique, un outil doté de deux interfaces, une pour chaque public cible :

L’interface FIODA destinée aux verbalisants pour la constatation et le rapportage des infractions ;

L’interface TIBODA destiné aux agents de l’Administration du contentieux et du recouvrement pour la gestion et le traitement des dossiers ;

Ce système sera intégré dans le système informatique des Douanes et Accises et du SPF Finances selon les standards et normes en vigueur.

III.2 Remarques quant à la structure du volet technique du cahier spécial des charges

III.2.1 Définitions

Une infraction est la violation d’une disposition légale ou réglementaire – on se limitera aux infractions pour la constatation desquelles l’AGDA est compétente ; dans le contexte du présent projet, on ne prendra en compte que la dimension répressive : l’infraction est alors considérée comme le motif qui justifie réclamation de la part de l’AGDA

Un acte de constatation est un document par lequel est constatée et actée une infraction à une législation pour laquelle les agents de l’AGDA sont compétents

Le dossier qui rassemble l’ensemble des informations et documents associés à une procédure administrative ou judiciaire

Une partie du dossier est constituée du dossier infractionnel qui reprend le ou les actes de constatation et les autres documents établissant la constatation des faits à l’origine de la procédure ; l’interface FIODA se focalise sur ce sous-dossier

Le(s) contrevenant(s) sont la ou les personnes physiques ou morales, à qui sont réclamées des montants à titres divers et/ou des actions correctrices (p.ex. mise en conformité) suite à la constatation d’une ou plusieurs infractions

Le contribuable : la personne physique ou morale qui demande à l’administration de prendre une disposition (p.ex. autorisation, supplément) ou contre qui l’administration prend une disposition

La procédure (transactionnelle, recours administratif, civile, pénale et mesures conservatoires) est un ensemble coordonné d’actions définies dans leur forme par la loi et qui vise à un objectif bien défini dans le contexte du recouvrement des montants réclamés, du respect des obligations légales et/ou de la gestion des contestations (recours administratifs). Chaque dossier peut donner lieu à une ou plusieurs procédures.

Pour la liste complète des notions propres au domaine en question et de la terminologie utilisée dans le contexte du marché, nous renvoyons à l’annexe F.

III.2.2 Acronymes et abréviations

Acronyme Signification

AGDA / D&A Administration Générale des Douanes et Accises, décomposée en cinq administrations : KLAMA, TCV, BUEK, O&O et CTX / Douane en Accijnzen, bestaande uit vijf administraties: KLAMA, TCV, BUEK, O&O en CTX

BCE / KBO

Banque Carrefour des Entreprises / Kruispuntbank van Ondernemingen


P. 40

BUEK Administration Bureau Unique / Enig Kantoor

CAMADA CAse Management Douane & Accises / CAse Management Douane en Accijnzen Outil utilisé par l’Administration des Enquêtes et Recherches pour suivre leurs dossiers d’enquêtes.

DIV Direction pour l’immatriculation des véhicules / Directie Inschrijving Voertuigen

FIODA Fraudes Infractions Onregelmatigheden Douanes et Accises Module d’enregistrement des infractions du système à développer.

TIBODA Traitement des infractions Douanes et Accises / Behandeling Overtredingen Douane en Accijnzen

KLAMA Gestion des clients et Marketing / Administratie Klanten Management en Marketing

MODA Douane et Accises Mobile / Mobiel toezicht Douane en Accijnzen Logiciel de planification des activités des agents de TCV et KLAMA.

PLDA Paperless Douanes et Accises / Paperless Douane en Accijnzen L'application pour le traitement électronique des déclarations et des dettes. Cette application est aussi la référence pour les données comptables relatives, en particulier, aux droits, taxes, amendes, etc.

SCGI / CDIB

Service central de gestion de l’information et analyse de risque (fait partie de l’AGDA) / Centrale Dienst voor InformatieBeheer

SITRAN Signalétique Transversale / Transversale Signaletiek Une base de données regroupant les informations de sources authentiques, dont : le Registre national, la BCE et la Centrale des Bilans de la Banque Nationale

STIPAD Système de Traitement Intégré de la documentation Patrimoniale

TCV Surveillance, contrôle et constatations / Administratie Toezicht, Controle en Vaststelling

TFR Tax Fraud Reporting

DAU / ED

Document Administratif Unique / Enig Document

FINADA / NAKADA

Fichier National en matière de Douanes et Accises / Nationaal Kaartsysteem inzake Douane en Accijnzen

VLABEL Vlaamse Belastingdienst

MRN Movement Reference Number

O&O Enquête et Recherche / Administratie Onderzoek en Opsporing

CTX Infractions et Recouvrement / Overtredingen en Invordering

CCFF Communication Centre for Federal Fiscality

IAM Identity and Access Management

PID Project Initiation Document

SOA Service Oriented Architecture

XML Extensible Mark-up Language


P. 41

FUP Finance Unified Process

ETP / VTE

Equivalent Temps Plein / Voltijds Equivalenten

TVA / BTW

Taxe Sur La Valeur Ajoutee / Belasting over de Toegevoegde Waarde

SPF / FOD

Service Public Fédéral / Federale Overheidsdienst

WBS Work breakdown structure

SLA Service Level Agreement

QUAC Quality Assurance Control Comité

PMO Project Management Office

PV Procès-verbal / Proces Verbaal

WSDL Web Service Description Language

ESB Enterprise Service Bus

LDAP Lightweight Directory Access Protocol

RUP Rational Unified Process

CV Curriculum Vitae

III.3 Contexte du marché Dans ce paragraphe informatif, le soumissionnaire trouvera les renseignements nécessaires pour formuler sa réponse aux besoins exposés dans les paragraphes ci-dessous.

III.3.1 Contexte général

III.3.1.1 Douane et Accises (D&A)

L’Administration des Douane et Accises assure la protection de la société et la promotion du commerce international par la gestion des frontières extérieures et la sécurité de la chaîne logistique. Voici les principales tâches de la Douane :

garantir la sécurité des citoyens en contrôlant la nature des marchandises et en empêchant les marchandises suspectes de pénétrer dans l’Union européenne ;

protéger les intérêts financiers de la Communauté et des États membres par la perception et le contrôle des droits d'importation, des accises et de la TVA d'une part, par la perception et le contrôle des droits d'exportation et des restitutions sur les produits agricoles ;

protéger la Communauté contre le commerce illégal et déloyal et promouvoir les activités économiques légitimes ;

renforcer la position concurrentielle des entreprises européennes par un environnement douanier électronique facile d'accès.

Pour accomplir ces missions, nous collaborons au niveau national et international avec les autres services publics, en particulier les services de maintien chargés de la lutte contre la fraude, le crime organisé et le terrorisme. Les services de l’AGDA veillent notamment à la perception et au contrôle des :

accises belges sur des produits comme le café et les boissons non alcoolisées ;

produits soumis aux accises qui sont harmonisés à l’échelle communautaire, à savoir les produits énergétiques, l’alcool, les boissons alcoolisées et les produits au tabac.


P. 42

III.3.1.2 Rôle et mission des services concernés

Constatation des infractions Les agents de l’Administration Générale des Douanes et Accises (AGDA) constatent des infractions dans différents contextes : aux frontières aériennes ou maritimes, lors de contrôles routiers ou dans les firmes, etc. Soit de façon directe lors de contrôles de moyens de transport ou de marchandises, soit de façon indirecte par l’analyse des documents douaniers. Lorsqu’une infraction est constatée, et selon le type d’infraction, l’agent sera amené à rédiger un ou plusieurs actes de constatation (Constat, Procès verbal, etc.) et documents accessoires. Ces documents peuvent être d’une structure de complexité variable. En outre, lors du contrôle par le chef de service, ou lors du traitement ultérieur par l’Administration du Contentieux et du Recouvrement, des documents complémentaires peuvent être requis. Litiges et recouvrement Les agents de l’Administration du Contentieux et du Recouvrement doivent traiter toute une série de dossiers, dont les dossiers d’infractions, mais aussi les recours administratifs, l’assistance mutuelle, les irrégularités, les citations émanant de tiers, etc. Ces dossiers donnent lieu à diverses procédures dont la nature et le déroulement dépend des décisions prises par les agents de l’Administration du Contentieux et du Recouvrement, en fonction de leurs interactions avec les parties tierces. Bien que ces décisions et les actions des agents soient régies par des règles strictes définies par la loi, les procédures elles-mêmes sont extrêmement flexibles. Toute procédure de contentieux ou de recouvrement est susceptible de donner lieu entre autres à une invitation à payer, une transaction, un recours administratif et/ou à une action en justice. Cette dernière peut elle-même être interrompue si une transaction intervient, et réciproquement. Il n’y a donc rien qui ressemble à une procédure linéaire de bout en bout.

III.3.1.3 Situation actuelle

Au stade actuel, l’AGDA ne dispose pas d’une application informatique intégrée supportant l’ensemble des tâches et responsabilités visées sous § III.3.1.2. Les dossiers sont traités et suivis à la main, à l’aide d’applications bureautiques standard. Le soumissionnaire doit fournir une solution apportant une réponse à une série de problèmes essentiels et de limitations propres à la procédure actuelle. Sur cette base, des objectifs métier sont définis, ainsi que la plus-value que l'on compte tirer de la solution demandée.

Fortes divergences dans le traitement concret des dossiers entre les services régionaux. Il faut uniformiser le traitement des dossiers.

Échange limité de connaissances et de résultats entre dossiers de même nature.

Le contrôle interne est entravé par un manque d’informations statistiques exploitables concernant le traitement des dossiers.

Le traitement manuel des dossiers génère un grand nombre de tâches administratives complexes qui réduisent l’efficacité.

Évolution de l’effectif : personnel moins nombreux mais plus qualifié.


P. 43

III.3.2 Contexte technique

III.3.2.1 Normes et standards à respecter

Le SPF Finances souhaite exploiter au maximum les licences acquises dans le passé, et ne pas payer deux fois pour des fonctionnalités comparables. Pour cette raison, le SPF Finances exige la conformité aux standards ICT déjà en usage depuis plusieurs années. Si des développements s'imposent, le soumissionnaire est prié de faire appel aux outils de développement standard existants. Il doit également s'en tenir aux méthodologies standard d'analyse (FUP), de support au développement et de gestion de projet (PMFin, la méthodologie de projet exclusive des Finances, basée sur la norme internationale Prince2) La description complète de ces standards et de FUP se trouve sur le site http://minfin.fgov.be/portail2/nl/modernisation/ict.htm#B (rubrique « ICT fundamenten (FOD Financiën) ») et http://minfin.fgov.be/portail2/fr/modernisation/ict.htm#B (rubrique « Fondements ICT (SPF Finances) »).

III.3.3 Contexte organisationnel

III.3.3.1 Gestion du projet et méthodologie

PMFin L'adjudicataire aura recours à PMFin, notre méthodologie et la procédure de gestion des projets. PMFin est la méthodologie de projet unique et standard du SPF Finances. Elle repose sur la norme internationale Prince 2. La méthodologie est appuyée par l’outil de projet ProjectMaster.

http://minfin.fgov.be/portail2/nl/modernisation/ict.htm#B

http://minfin.fgov.be/portail2/fr/modernisation/ict.htm#B


P. 44

Figure 1 – Métaprocessus PMFin

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

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

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

Description du contexte du projet, définition du projet, de ses objectifs, de son périmètre.

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

Une WBS (« work breakdown structure ») complète, un planning détaillé et réaliste du projet

avec ses jalons (GANTT) et la durée des différentes phases, sous-phases, activités et tâches,

les moyens à mobiliser par phase (financiers, humains et autres). Ce planning sera tenu à

jour.

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

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

Dépendances avec d'autres projets

Plan de qualité

Plan de communication (avec aspects « change management »)

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

Après la réunion de coup d'envoi (« kick-off »), le PID est finalisé, complété, enfin soumis à la validation du comité de pilotage, sponsor compris. Le soumissionnaire doit décrire sa structure et ses capacités en termes d'organisation des services professionnels : services offerts, portée géographique, niveaux et qualités du personnel. Le plan doit spécifier les tâches, leur durée et le nombre de personnes concernées, pour chaque (partie de) phase. Le plan doit aussi détailler la collaboration attendue de la part du personnel du SPF Finances. Après l'attribution du projet, le soumissionnaire élaborera un PID et un plan de projet complets et détaillés, qu'il présentera à la structure de gestion du projet du SPF Finances.


P. 45

L'approbation formelle du PID (planning de projet compris) ci-dessus par le comité de pilotage du projet est indispensable avant d'entamer la phase suivante. Il appartient au soumissionnaire de veiller à la tenue à jour du PID pendant toute la durée du projet. Toute modification du plan de projet doit être approuvée formellement par le comité de pilotage du projet. Le PID du soumissionnaire constituera pour notre propre PID une source d'information à propos des produits et des unités de travail dont le soumissionnaire aura la charge. Structures de gouvernance Tous les projets sont pilotés et gérés au sein des structures de gestion de projet du SPF Finances. Celles-ci sont représentées dans le schéma suivant :

Figure 2 – Structures de gouvernance

Chef de projet Chaque projet du SPF Finances est dirigé par un chef de projet interne (business). Celui-ci est nommé par le Sponsor, en concertation avec le comité de pilotage. Le soumissionnaire désignera son propre coordinateur de projet externe (chef de projet externe). Celui-ci et le chef de projet assument l'entière responsabilité de la bonne exécution du projet. Comité de pilotage Le comité de pilotage détient de larges compétences : il surveille le scope et les objectifs du projet, approuve le PID et le plan de projet détaillé ainsi que toutes leurs modifications, surveille l'avancement du projet, confirme l'acceptation des livrables (produits, livraisons partielles), évalue la qualité des produits partiels et finaux, et se prononce dans tous les litiges et/ou problèmes soulevés par le chef de projet. Il s'occupe de tous les aspects contractuels, administratifs et techniques de l'exécution du marché (garantie, respect des SLA, qualité de l'exécution, etc.) À cette fin, le chef de projet et le coordinateur de projet externe feront régulièrement rapport au comité de pilotage : situation, progression, risques et problèmes… Le comité de pilotage se compose du sponsor, du chef de projet et d’un représentant des utilisateurs. Un profil senior du soumissionnaire et le coordinateur de projet externe participent aux réunions du comité de pilotage, afin d’informer celui-ci et de discuter des litiges/problèmes soulevés par le chef de projet.


P. 46

D'autres personnes peuvent être invitées, notamment le PMO opérationnel, le coordinateur de projet ICT, le responsable du ‘work package’ ou des personnes travaillant sur des aspects spécifiques du projet. Équipe de projet L'équipe de projet se compose de différents profils (internes et externes), dont chacun rapporte au

responsable de son unité de travail (‘work package’) ou au chef de projet.

Idéalement, les rôles suivants font partie de l'équipe : coordinateur de projet ICT (qui assure la liaison avec le service d'encadrement ICT), change coordinator (chargé de la gestion des changements) (P&O et Communication), coordinateur externe (contractant). PMO opérationnel Le PMO opérationnel peut aider le chef de projet à gérer et à maîtriser le projet, à appliquer la méthodologie PMFin, à utiliser l'outil de projet ProjectMaster, et à rédiger les rapports destinés au comité de pilotage ou au comité de direction. Réunion de coup d’envoi Dans un délai maximum de 2 semaines suivant l'attribution du marché, l'adjudicataire et le SPF Finances doivent tenir une première réunion du comité de pilotage, appelée réunion de coup d'envoi (ou de kick-off). La réunion officialise le début du projet. Au cours de cette première rencontre, si cela s’impose au vu du cahier des charges, on examine le PID, on présente la composition des équipes et leurs compétences professionnelles, l'agenda des réunions de rapportage et des réunions du comité de pilotage, les modalités de gestion de projet, le planning de la réalisation du marché, on explique les principes du SLA, etc. Un document rédigé en deux exemplaires par l'adjudicataire et validé par le pouvoir adjudicateur entérine officiellement le début du projet dès que la réunion de coup d'envoi a eu lieu. Réunion du comité de pilotage Après la réunion de coup d'envoi, le premier comité de pilotage fixe la date de ses réunions suivantes. Le sponsor ou le chef de projet peuvent toujours convoquer un comité de pilotage en dehors des dates fixées. Autres réunions Une fois par semaine, le chef de projet rencontre l'équipe du projet et rédige un rapport décrivant la situation du projet. Le rapport est distribué aux parties concernées importantes (à déterminer au coup d’envoi). Qualité Le PID réserve une large place à la qualité. Dans le PID, le soumissionnaire explique comment il entend surveiller la qualité. Par ailleurs, le SPF Finances peut demander au QUAC (Quality Assurance Control Comité) un contrôle supplémentaire du respect des normes et des standards. Un contrôle de qualité par des tiers fait également partie des possibilités. Rapports À l'occasion des réunions visées ci-dessus, ainsi qu'à des moments convenus, l'adjudicataire établira les rapports nécessaires concernant les moyens mobilisés (personnel, méthodes, matériel, logiciels), l'avancement du projet, sa situation. Périodiquement, à savoir une fois par mois, suivant un calendrier mis au point de commun accord lors de la réunion de coup d'envoi, l'adjudicataire rédigera un rapport complet d'avancement du projet (situation de chaque phase de la réalisation) à l'intention du comité de pilotage. Le rapport évoquera les problèmes éventuels et les solutions proposées.


P. 47

L'adjudicataire rédigera aussi des rapports de coordination et de travail sur l'avancement du projet (situation de chaque phase de la réalisation), les problèmes éventuels et les solutions proposées. Les réunions auront lieu ponctuellement, à la demande des parties. Le rythme de ces rencontres dépendra de la progression des phases du projet. Le lieu des réunions sera précisé par le SPF Finances avec les dates. Le soumissionnaire et le coordinateur de projet désigné par lui mettront à la disposition du chef de projet toutes les informations nécessaires pour surveiller le déroulement réel des activités du soumissionnaire et la situation par rapport au planning.

Ce rapportage destiné au chef de projet suivra une fréquence hebdomadaire, sur la base d'une situation représentée sur le schéma Gantt du projet, complétée d'une brève description écrite, avec les points principaux, les problèmes éventuels et leur solution. Tous les détails des modalités de rapportage doivent être communiqués au début du projet. Tous les aspects relatifs au fond (planning, risques, qualité, réception, ressources) seront d'abord évoqués au sein de l'équipe de projet. Si le chef de projet le juge nécessaire, les problèmes seront soumis à l'examen et à la délibération du comité de pilotage. Chaque mois, le chef de projet remettra au comité de pilotage un rapport mensuel sur l'avancement du projet. Le cas échéant, le chef de projet peut inviter le coordinateur de projet externe à la réunion du comité de pilotage afin de l'éclairer plus en détail sur certains points.

III.3.3.2 Gestion des changements

Tout changement (scope, résultats/produits visés, planning, budgets) au projet doit faire l'objet d'une demande de changement spécifiant le motif et l'impact du changement. Le comité de pilotage évalue le bien-fondé et l'opportunité du changement envisagé. Il peut se faire assister du PMO (opérationnel) et/ou d'un expert (externe). L'exécution des changements envisagés n’ayant pas d’impact sur le coût requiert l’accord formel du fonctionnaire dirigeant. L’exécution des changements ayant un impact sur le coût requiert l’accord formel de l’ordonnateur. Le cas échéant, l’adjudicataire devra actualiser le PID.

III.4 Description du marché Le soumissionnaire est prié de préciser les éléments suivants dans son offre. Cela signifie que l’offre doit formuler une réponse claire et complète aux dispositions et besoins exposés dans chacun des paragraphes suivants du présent chapitre. Le soumissionnaire doit aussi faire preuve d’une bonne compréhension des besoins du métier. Le marché se compose de la fourniture d'une application informatique à laquelle la suite du texte fera référence sous le nom le SHERLOCK. SHERLOCK est une application qui est :

soit entièrement le résultat d’un développement spécifique et sur mesure, réalisé par l’adjudicataire suivant les spécifications de ce cahier spécial des charges ;

soit essentiellement un package/outil « off-the-shelf » prêt à l’emploi, paramétrable, suffisamment personnalisable et extensible pour que les spécifications de ce cahier des charges soient réalisées aussi complètement que possible ;

soit une combinaison de ces deux options ;


P. 48

La partie réalisée sera entièrement conforme aux résultats de l'analyse fonctionnelle à exécuter (voir PHASE 1 « Elaboration » in § III.5.1). Pour tous les logiciels et les composants qui seront mis en œuvre, le soumissionnaire doit inclure dans son offre une description technique de la solution proposée. La solution offerte en réponse à ce cahier spécial des charges formera la base du Project Initiation Document (PID) à établir au début du projet.

III.4.1 Généralités

De façon extrêmement résumée et simplifiée, deux processus globaux d’utilisation sont possibles : Processus 1 : constatation d’une infraction, suivie d’un traitement par le contentieux

Le (ou les) verbalisant(s) constate(nt) une ou plusieurs infractions ;

Il rédige et annexe les documents nécessaires à son traitement, afin de constituer un dossier infractionnel ;

Lorsque son dossier est complet :

o Il le transmet aux autorités compétentes (externes à l’AGDA) s’il s’agit d’une infraction pour laquelle l’AGDA n’est pas compétente pour recouvrer et/ou poursuivre (p.ex. transmission papier vers le parquet, vers Vlabel, etc.) ;

o Il le transmet à l’Administration du Contentieux et du Recouvrement s’il s’agit de matières pour lesquelles l’AGDA est compétente pour recouvrer et/ou poursuivre ;

Dans ce dernier cas, un agent du contentieux ouvre un dossier contentieux pour traiter l’infraction ;

o Il engage les procédures requises jusqu’à la conclusion du dossier (p.ex. paiement) ;

o Quand c’est nécessaire, il requiert des compléments au dossier infractionnel ;

Processus 2 : création de dossiers sans infraction préliminaire

Il est aussi possible pour un agent de l’Administration du Contentieux et du Recouvrement de créer un dossier en l’absence de dossier infractionnel (p.ex. recours administratif, assistance mutuelle, citations par des tiers) ;

Pour supporter ces deux processus, on considérera que, d’un point de vue purement fonctionnel, le système sera constitué des composants principaux suivants (Figuur 3 - Blocks fonctionnels) :

1. La base de données des dossiers et documents, qui contient toutes les informations manipulées par les agents ;

2. L’interface FIODA pour l’enregistrement des infractions et la gestion du dossier infractionnel ;

3. L’interface TIBODA pour le traitement des dossiers ;

4. La librairie de modèles qui contient les maquettes de documents, ainsi que les modèles de dossiers, de procédures et d’actions (cf infra) ;

5. Le moteur de workflow qui détermine le cours des actions selon le contexte des dossiers ;

6. L’interface de configuration qui permet de configurer le comportement du système, en particulier d’éditer les modèles de la librairie et le comportement du moteur de workflow ;


P. 49

Sources Externes de

données de référence

(SITRAN, STIPAD,

etc.)

PLDA

SystèmeSources Externes de

données de référence

(SITRAN, STIPAD,

etc.)

SCGI

PLDA

Webservice pour

autres systèmes

d'entrée

(CAMADA,

MODA)

FIODA Workflow DA

BD Dossiers et

Documents

Verbalisant (incl.

équipe / chef)

Agent du

Contentieux et

Recouv rement

Librairie Modèles Moteur Workflow

Interface

d'administration

Gestionnaire du

système

Figuur 3 - Blocks fonctionnels

Le système interagit vers l’extérieur par cinq canaux principaux :

1. Recherche d’information auprès de sources de données externes (p.ex. Sitran, Stipad) ;

2. Fournitures de données au Service Central de Gestion de l’Information (SCGI) ;

3. Interaction avec le système PLDA de gestion des dettes et paiements ;

4. Échanges de mails par le système de messagerie du SPF Finances ;

5. Web service à disposition des applications clients (p.ex. CAMADA, MODA) afin de leur permettre d’introduire électroniquement des dossiers infractionnels ; Ces interactions sont détaillées ci-après.

Les concepts de base sont l’acte de constatation, le dossier, la procédure, le document et la tâche. A chaque dossier sont associés : un ensemble structuré de documents, un historique des tâches effectuées et un agenda des tâches à réaliser. Ces éléments sont détaillés ci-après. L’enchaînement des tâches sera avant tout décidé par l’agent. Le système l’assistera en proposant les tâches les plus probables (selon des règles à définir, et configurables, cf section III.4.3.5) en fonction des caractéristiques du dossier et des procédures en cours – mais l’agent pourra toujours choisir une tâche non proposée. Les utilisateurs attendent de l’outil :

qu’il rassemble dans un lieu virtuel unique l’ensemble des informations sur les dossiers en cours – ce qui inclut, entre autres :

une connexion à des sources d’informations externes ;

une vue d’ensemble de tous les paramètres du dossier ;

qu’il les assure du respect des délais et des prescrits en termes d’échanges d’informations ;

qu’il prépare les actions administratives standard ;

qu’il prenne en charge le rapportage et les statistiques, en particulier aux fins de contrôle interne et de planification ;

qu’il assure l’interconnexion avec PLDA auquel il sous-traite le calcul des droits, taxes et intérêts ;


P. 50

III.4.2 Utilisateurs du système

Les agents

Les utilisateurs finaux sont ceux qui utilisent le système pour leur travail quotidien, cela comprend en particulier :

Les agents verbalisants ;

Les agents du service contentieux ;

Leurs responsables ;

Leurs différents droits sont gérés par le système. Les gestionnaires de la configuration Les gestionnaires du système sont ceux qui ont pour mission de gérer la configuration « fonctionnelle » du système, dont :

réalisation des maquettes de documents ;

définition des métadonnées enregistrées dans le système ;

configuration des règles de comportement du système ;

mise à jour du carnet d’adresses du système ;

droits des utilisateurs à l’intérieur du système ;

La liste des éléments configurables gérés par ces utilisateurs est reprise en section III.4.3.5. Les gestionnaires du système font partie de l’AGDA. Ils agissent suivant les décisions qui seront prises par le comité de gestion fonctionnelle de l’outil, selon une gouvernance qui sera définie en temps utile. Les administrateurs du système Les administrateurs du système sont des membres du service informatique qui ont tous les accès et la connaissance nécessaires à la maintenance de l’infrastructure et de l’application. Voir en section III.4.3.1.10. pour les besoins fonctionnels liés à la gestion des utilisateurs.

III.4.3 Exposé des besoins fonctionnels

La suite de ce paragraphe esquisse plus en détail les caractéristiques fonctionnelles auxquelles la solution à réaliser doit se conformer suivant l'administration des D&A. On trouvera aussi ci-dessous une indication de l’importance et du caractère prioritaire des fonctionnalités respectives. Nous distinguons les niveaux de priorité suivants :

P1 – « Nécessaire » : Ces fonctionnalités sont considérées comme cruciales pour la plus-value escomptée et la réalisation des objectifs métier. L’application proposée par le soumissionnaire doit apporter une solution adéquate à chacune de ces exigences.

P2 – « Souhaité »: Caractéristiques des indicateurs d’intérêts pour lesquels une mise en oeuvre éventuelle peut être réalisée en tenant compte de la faisabilité technique, du coût de revient et de l’impact sur le planning. Chaque exigence de niveau prioritaire P2 est considérée comme une partie de l’option (voir I.13). Le soumissionnaire devra formuler une solution pour chacune de ces exigences. Pendant l'exécution du contrat la possibilité de réalisation de chaque P2 sera prise sur base d'une analyse coût / bénéfice.

P3 – « Futur » : Ces exigences sont mentionnées à titre d’information et ne font pas partie du marché. Leur réalisation effective est prévue pour des releases ultérieurs. Il est cependant essentiel que la solution proposée n’exclue pas la réalisation future de ces exigences.


P. 51

À la fin de chaque sous-section, un tableau récapitule les besoins fonctionnels décrits en précisant leur niveau de priorité.

III.4.3.1 Cycle de vie des objets

III.4.3.1.1 Le dossier contentieux/recouvrement

Un nouveau dossier contentieux/recouvrement peut être créé de deux manières :

Par la transmission depuis FIODA d’un dossier infractionnel ;

Manuellement, par un agent du contentieux (p.ex. pour les recours administratifs, l’assistance mutuelle, les citations émanant de tiers) ;

Il n’y a pas à proprement parler de typologie des dossiers. Un dossier est caractérisé par un certain nombre d’informations : sa matière, sa phase (transactionnelle, juridique), sa date d’ouverture, son statut, etc. Certaines de ces informations seront saisies manuellement, d’autres peuvent être calculées à partir des premières; d’autres encore peuvent être récupérés à partir de systèmes extérieurs (exemple : coordonnées des contrevenants, informations comptables). Ces informations structurées servent aussi au système pour proposer des actions aux utilisateurs (voir la notion d’action III.4.3.1.4). Outre ces informations, les dossiers contiennent des documents (cf III.4.3.1.3), qui peuvent être organisés en sous-dossiers. Toutes les informations structurées relatives au dossier et à ses parties (document et sous-dossiers) sont collectivement appelées « métadonnées ». Parmi ces métadonnées, on trouvera le numéro d’identification unique du dossier, dont la structure sera définie lors de la phase d’analyse (p.ex. codage par type, direction régionale, date). La liste des métadonnées qui caractérise un dossier sera définie par l’Administration du Contentieux et du Recouvrement. Cette liste est sujette à évolution et le système permettra aux gestionnaires de l’étendre et/ou d’adapter la description des informations ainsi que les règles pour leur calcul. Parmi ces métadonnées, on trouve « l’état » du dossier : un nouveau dossier est initialement dans l’état « Nouveau » jusqu’à ce qu’il soit affecté à un agent du contentieux. Il passe alors à l’état « assigné » (en attente d’être pris en charge) puis « actif». Il y restera jusqu’à sa clôture par l’agent en charge ou son chef de service. Éventuellement, un dossier ouvert peut être temporairement suspendu. Un dossier clôturé peut être rouvert (p.ex. clôture suite à un PV de carence suivi d’une ouverture de règlement collectif de dettes ou encore un dossier recouvrement qui fera suite à un dossier contentieux clôturé). La liste des états pourra être amendée au cours de la phase d’analyse complémentaire, et sera figée à ce moment-là. L’accès au dossier et sous-dossier est régi par une matrice de droits d’accès configurable par les gestionnaires. Il sera possible de définir des modèles complets de dossiers et sous-dossiers. Ces modèles pourront être utilisés par les utilisateurs, par exemple dans le cas où ils entament certaines procédures qui imposent une organisation définie de l’information. Et il sera aussi possible que ces modèles soient automatiquement appliqués pour certains types de dossiers (donc, en fonction des métadonnées présentes lors de la création du dossier).


P. 52

III.4.3.1.2 Le dossier infractionnel

Le dossier infractionnel est la partie du dossier qui contient les documents liés à la constatation de l’infraction. Il ne se différentie d’un dossier contentieux/recouvrement que par l’usage qui en est fait. Le dossier infractionnel est créé par des verbalisants qui y enregistrent les données propres à une ou plusieurs infractions, ainsi que les documents afférents. Le contenu du dossier infractionnel est sous la responsabilité de l’équipe de verbalisants qui l’a créé : il ne peut être modifié que par les agents de leur service, selon une matrice d’autorisations précise. Une fois validés, les données et documents qu’il contient sont figés. Il peut être consulté par les agents de l’Administration du Contentieux et du Recouvrement qui en assurent le traitement ultérieur. Lorsque le ou les verbalisants estiment qu’un dossier est complet, ils déclenchent son transfert vers l’Administration du Contentieux et du Recouvrement. Le système crée alors un dossier contentieux, dont le dossier infractionnel va devenir un sous-dossier. L’agent de l’Administration du Contentieux qui en aura la charge complètera sa partie au fil des procédures engagées, mais ne pourra pas modifier le sous-dossier infractionnel. Un agent verbalisant pourra – s’il le juge nécessaire – donner accès à un agent du contentieux afin que ce dernier puisse vérifier la qualité du dossier avant son transfert. Le dossier infractionnel restera en général en l’état jusqu’au terme de la procédure, sauf dans le cas où l’Administration du Contentieux et du Recouvrement réclame des devoirs complémentaires, auquel cas un des verbalisants, ou un autre agent autorisé (selon les règles définies), pourra compléter le dossier infractionnel (sans pour autant pouvoir modifier les pièces existantes, voir ci-dessous). Chaque sous-dossier (et document) d’un dossier infractionnel peut-être dans un des états suivants : Nouveau (vide), En cours, Terminé (en attente de validation), Validé (documents en lecture seule), Transmis (avec indication du destinataire et de la date de transmission), Annulé (avec motif). Les changements d’état sont régis par des règles configurables (p.ex. validation obligatoire ou optionnelle par le supérieur hiérarchique). Voir ci-dessous (III.4.3.1.4) pour la définition de ce qu’est une « action ». La liste définitive des états sera confirmée au début du projet.

# Description du besoin Priorité

DS1 Création de dossiers et sous-dossier, édition de métadonnées, gestion du cycle de vie P1

DS2 Gestion des droits d’accès par dossier et sous-dossier P1

DS3 Création de dossier à partir de modèles complets (dossier et sous-dossiers) P2

DS4 Création de dossiers contentieux à partir de dossiers infractionnels P1

III.4.3.1.3 Le document

Types de documents Par document, on entend tout document papier scanné, tout fichier de traitement de texte ou tableur, tout fichier PDF, tout courriel qui accompagne le dossier. La liste des types de documents sera établie préalablement aux développements. Un document peut être mis dans l’un des états suivants : Nouveau (document en entrée, non lu), Ouvert (document en cours de création), Terminé (en attente de validation), Validé (lu et/ou imprimé, non modifiable) ou Obsolète (p.ex. annulé).


P. 53

Maquettes Le système contient un certain nombre de maquettes de documents-type créées par les gestionnaires de configuration et qui seront utilisées par les utilisateurs finaux pour créer des documents reprenant une partie de l’information du dossier. Ces maquettes contiennent une mise en page fixe, des zones à compléter et, le cas échéant, des zones « libres ». Certaines zones peuvent être complétées par l’utilisateur, d’autres peuvent faire référence à des éléments du dossier. Chaque maquette est donc constituée d’une partie fixe – créée et mise à jour par les gestionnaires de la configuration – et d’une partie variable constituée des données propres aux dossiers. La mise en page de la partie fixe des maquettes sera limitée à du texte simple avec un enrichissement par gras, italiques, souligné, listes et tableaux. Il sera néanmoins possible de définir la page de fond avec le logo de l’Administration, ainsi que des en-têtes/pieds de page standard contentant des informations spécifiques (date, page, etc.). Lorsqu’un agent souhaite produire un document à partir d’une maquette, le système lui présentera un masque de saisie dont les champs seront pré-remplis à partir des données déjà présentes dans le système. L’utilisateur aura la possibilité de compléter les autres champs, et ils seront enregistrés dans le système. Les champs seront disposés de façon cohérente avec leur positionnement sur les documents papier. Il n’est cependant pas nécessaire de refléter exactement la mise en page définitive d’impression. En particulier, il n’est pas requis que les logos et/ou les en-têtes soient visibles lors de la saisie des données. Ceux-ci ne devront être visibles qu’à partir de la prévisualisation avant impression. Il est à noter que toutes les données ne sont pas nécessairement saisies lors de l’édition de documents à partir de maquettes. Certaines données seront saisies dans des formulaires, indépendamment de toute création ou impression de documents. Par exemple, l’identification des contrevenants, description des infractions, les amendes, etc. D’autres données seront récupérées à partir de systèmes externes tels que SITRAN ou PLDA. Les données peuvent donc être renseignées par différentes méthodes (édition de documents, formulaires, interconnections). Une fois renseignées par une méthode, elles seront disponibles et éventuellement modifiables pour les autres. Par exemple, une donnée encodée dans un formulaire ne devra pas l’être une seconde fois lors de l’édition d’un document à partir d’une maquette qui fait usage de cette donnée. Les maquettes pourront être constituées de parties conditionnelles activées ou pas par les agents, en particulier pour les documents contenant des alternatives ou pour les documents contentant des sections optionnelles en fonction des champs remplis ou choisis et/ou de décisions de l’agent. Par exemple : dans les actes de constatation d’infraction aux accises, il est nécessaire de faire figurer uniquement les sections correspondant aux infractions constatées (p.ex. tabac, alcool, etc.). Pour cela, on envisagera l’utilisation de « formlets » : fragments de formulaires que l’on peut conditionnellement insérer dans un formulaire à des endroits prédéterminés. Par exemple, un fragment « cigarettes » avec quelques champs spécifiques à remplir si la marchandise saisie consiste en des cigarettes (p.ex. nombre de cigarettes). Cette fonctionnalité sera utile pour éviter d’immenses formulaires dont seulement une petite partie serait utilisée. Elle permettra aussi de gérer facilement le cas fréquents des infractions multiples par l’ajout d’autant de « formlets » qu’il y a d’infractions constatées. Il n’est pas requis que les agents puissent définir le lieu où les formlets seront insérés. Ceux-ci font partie de la définition de la maquette et leur structure et leur emplacement sont prédéfinis dans la maquette. Il n’est pas requis qu’un même formlet soit utilisable sur plusieurs maquettes différentes.


P. 54

Métadonnées Deux sortes d’informations sont associées aux documents :

Leur contenu, p.ex : le texte d’un courrier, une image scannée ;

Leurs métadonnées, qui sont d’une part des données à propos du document (p.ex. date de création, auteur, sujet, nature, état) et d’autre part l’ensemble des données présentes dans le document (p.ex. nature de l’infraction, identification du contrevenant).

La relation entre le contenu et les métadonnées dépendra donc de l’origine du document :

Soit il s’agit d’un document produit par le système à partir des métadonnées du dossier, selon des modèles enregistrés. Dans ce cas, les métadonnées préexistent et sont injectées dans le document.

Soit il s’agit de documents créés hors du système et importés. Dans ce cas, les métadonnées sont extraites du document (manuellement ou automatiquement, selon les possibilités).

La liste des métadonnées qui accompagnent chaque type de document sera fournie au début du projet. Cette liste restera sous le contrôle de l’Administration du Contentieux et du Recouvrement. Elle sera sujette à évolution et les gestionnaires pourront étendre ou adapter la liste et la description des informations, les règles pour leur calcul, etc. Verrouillage des documents Dans le cycle de vie d’un document produit par le système, il arrive un moment où il est considéré comme complet. Il est alors validé et transmis officiellement à ses destinataires, soit par voie électronique, soit par courrier papier. A partir de ce moment-là, une version « officielle » du document est verrouillée et ne pourra plus être ni modifiée ni effacée. Certaines métadonnées pourront continuer à être modifiées, mais la version verrouillée n’en dépendra plus. La question se pose aussi pour les documents importés sous forme électronique modifiable (traitement de texte ou tableur). Le système ne permet pas de les modifier directement mais l’utilisateur pourra les éditer dans le logiciel qui a servi à les créer, jusqu’à ce qu’il les valide et donc les verrouille. La version enregistrée à ce moment-là dans le système ne sera alors plus modifiable, ni effaçable. Les documents PDF ne sont de toute façon pas modifiables. Néanmoins, leur verrouillage aura pour effet de les rendre non-effaçables. On veillera à ce que cette fonctionnalité fondamentale de verrouillage soit claire et simple pour les utilisateurs afin d’éviter toute erreur. Stockage et édition Qu’il s’agisse de documents générés ou importés, ils seront réellement stockés dans le système (c’est à dire dans un espace de stockage sous son contrôle). Il ne peut s’agir de liens vers des documents localisés sur la machine de l’utilisateur. Le système doit permettre à l’utilisateur d’ouvrir les documents importés dans le logiciel d’origine (p.ex. traitement de texte ou tableur) et il doit gérer de façon transparente leur mise à jour s’ils ont été modifiés dans l’opération. En ce qui concerne les documents numérisés, on prévoira que la localisation des pièces originales (PV et annexes) soit enregistrée (comme métadonnée associée au document). Une action toujours disponible sera de demander au possesseur actuel de communiquer les pièces originales à l’agent (p.ex. via une action d’envoi de mail ou de courrier). A réception des pièces, l’agent mettra à jour l’information de localisation.


P. 55

Sous-dossiers, liens symboliques Les documents peuvent être organisés en sous-dossiers par les utilisateurs. Les documents peuvent être déplacés ou copiés d’un sous-dossier à l’autre (le système devra gérer la cohérence des métadonnées quand un document est copié). En outre, chaque document peut être placé par les utilisateurs dans plusieurs sous-dossiers à la fois sans pour autant être dupliqué (par l’équivalent d’un lien symbolique).

On pourra aussi définir des dossiers dynamiques, c’est à dire regroupant des documents sur base d’une règle, par exemple :

date du document dans une période ;

lien avec une procédure (p.ex. procédure pénale) ;

lien avec une personne (p.ex. auteur) ;

type du document ;

Valeur d’une métadonnée (p.ex. public/privé) ;

Effacement Un document peut être effacé selon des règles strictement définies :

les versions « brouillon » des documents générés par le système ;

les documents importés ;

L’effacement sera impossible pour les documents verrouillés et pour les documents importés qui ont été marqués comme à conserver, selon des règles configurables. Par exemple, il serait possible de définir qu’un document de type « copie de procès verbal » ne puisse être effacé. L’utilisateur a la possibilité de verrouiller manuellement un document, ce qui empêche définitivement son effacement. Néanmoins, on doit pouvoir qualifier un document d’obsolète, ce qui le déplace vers un dossier d’archivage (lequel ne peut pas être supprimé). Cette opération doit être tracée pour des motifs de contrôle interne. Résumé des besoins relatifs aux documents


DC1 Stockage des documents en dossier et sous-dossiers, avec liens symboliques, statut et verrouillage.

P1

DC2 Enregistrement de documents venant d’autres sources (scan, word, excel, etc.) et encodage manuel de leurs métadonnées

P1

DC3 Edition des documents importés dans leur logiciel d’origine P1

DC4 Transfert de documents (et de leurs métadonnées) d’un dossier à un autre P3

DC5 Extraction automatique de métadonnées à partir de certains types de documents électroniques importés

P3

DC6 Sous-dossiers dynamiques (documents ajoutés automatiquement) P3

DC7 Dossier « archive » pour les documents effacés P1

DC8 Création de documents à partir de maquettes et des données contenues dans le dossier. P1

DC9 Maquettes avec sections conditionnelles P1


P. 56

III.4.3.1.4 Les actions

Principes de base A chaque dossier est associée une série d’« actions ». Ce terme est réservé aux actions effectuées par des utilisateurs, il s’agit donc que « quelque chose à faire par l’agent » par opposition à quelque chose à faire par le système. Une action peut-être initiée par le système ou par un utilisateur, à partir d’une bibliothèque de modèles d’actions-type. Les actions seront dans l’un des états suivants :

a. les actions potentielles : leur exécution est possible (ou probable ou recommandée) étant donné l’état du dossier ;

b. les actions initiées : leur exécution est requise mais pas encore commencée, l’affectation de l’action à une personne n’est pas encore confirmée ;

c. les actions en cours d’exécution : leur exécution a commencé ;

d. les actions terminées : leur exécution est terminée ;

Les changements d’état des actions seront déterminés par l’application de règles définies par l’Administration du Contentieux et du Recouvrement – voir ci-dessous en section III.4.3.1.4) pour la configuration du déclenchement des actions. Néanmoins, les agents auront toujours la possibilité de changer manuellement l’état d’une action. Les règles seront rédigées selon un formalisme qui permettra aux gestionnaires de la modifier et d’en créer de nouvelles avec un risque minimal d’erreur. Délais et notifications Toutes les actions en cours ont un délai de réalisation. Le délai peut-être raccourci ou rallongé, mais ne peut pas être supprimé (c’est à dire que l’action serait reportée à une date indéterminée). Il est donc possible de reporter une action, mais il y a toujours un moment où l’agent devra effectuer le suivi la concernant. Le délai maximum autorisé est configurable par les gestionnaires de configuration ; il sera initialement de 1 an. Dans la configuration du modèle des actions, il sera possible de préciser un délai par défaut et un délai maximum (selon une gouvernance définie par l’Administration). Lors de l’exécution de l’action, les agents en charge pourront modifier les délais effectifs dans le respect des délais maximaux). Le système prévoira une notification anticipée des délais arrivant à expiration : il est en effet peu utile de signaler qu’un délai légal est expiré. Il faut donc le signaler à l’avance à l’utilisateur en charge de l’action. Celui-ci confirmera qu’il a pris connaissance de la notification et éventuellement fixera un nouveau délai de notification s’il ne lui est pas possible d’agir dans l’immédiat. En cas d’inaction endéans les délais prévus, le système notifiera d’abord l’agent par mail, puis son responsable hiérarchique (afin d’éviter que des absences causent un non-respect des prescrits légaux).


P. 57

Attribution des actions Lors du passage de l’état « potentiel » à l’état « initié », une action est affectée à un ou plusieurs utilisateurs selon des règles d’affectation configurables – ces règles seront basées sur les métadonnées du dossier, dont :

type de dossier, procédures en cours ;

type de marchandise ;

complexité de l’action (elle-même déterminée à partir d’autres métadonnées) ;

rôles, localisation et compétences des agents (métadonnées sur les utilisateurs) ;

disponibilité des agents (accès à la base myPO) ;

charge de travail des agents dans le système (nombre d’actions en attente).

Si aucun agent individuel ne peut être identifié ou n’est disponible alors l’action sera attribuée à un agent par défaut (backup ou le chef de service). C’est le travail effectif de l’agent sur l’action qui la fait passer de l’état « initié » à l’état en cours. Le système peut détecter que l’action a commencé, puis qu’elle est terminée, soit parce que l’agent l’indique via l’interface, soit sur base de règles telles que, par exemple, le changement de valeur de certaines métadonnées du dossier. Une action peut-être affectée à plusieurs agents. Cela signifie que cette action peut être réalisée par n’importe lequel de ces agents. Cela ne correspond pas à une division des tâches entre agents, car alors il faudrait des actions différentes pour chacun d’entre eux. Tous les agents à qui une tâche est affectée la voient dans leur liste d’actions, ainsi que son état ; en particulier, ils doivent facilement voir si un autre agent a commencé à exécuter l’action. Quand un des agents la marque comme « terminée », elle est terminée pour tous les agents. Un agent peut toujours :

1. réattribuer une de ses propres actions à un autre agent ;

2. prendre pour lui une action d’un autre agent ;

3. s’il est chef, changer l’attribution d’une action entre deux collaborateurs de son équipe, par exemple :

a. en cas d’absence d’une personne ;

b. en cas de non réaction d’un agent à des notifications lorsqu’un délai approche de l’expiration ;

La réattribution peut se faire pour une action, un groupe d’actions sélectionnées ou toutes les actions du dossier. Un chef de service aura la possibilité de transférer un dossier d’un agent à un autre, ce qui aura pour effet de transférer les droits d’accès ainsi que la responsabilité des actions en cours au nouvel agent en charge. On se référera utilement aux exemples de scénarios fournis en annexe B (0) et annexe C (0). Attribution de nouveaux dossiers Lorsqu’un nouveau dossier est créé, une action par défaut sera créée par le système, qui correspond à la prise en charge du dossier par un agent. Les règles d’attribution de cette action suivent exactement les principes décrits dans la section précédente. Par conséquent, il sera possible de définir les règles d’attribution des nouveaux dossiers.


P. 58

Cela sera en particulier utilisé lorsqu’un agent veut transférer un dossier vers un autre agent. Par exemple :

un verbalisant transfère vers le contentieux, un dossier infractionnel complet ;

un agent chargé d’une phase transactionnelle, transfère le dossier pour entamer une phase judiciaire ;

Dans ces deux exemples, le transfert n’est pas nécessairement la seule action impliquée : dans le premier cas, il y a aussi la création d’un dossier contentieux contenant le dossier infractionnel. Quoi qu’il en soit, l’agent qui transmet le dossier ne connaît pas nominalement l’agent qui doit le recevoir. C’est donc au système d’attribuer le dossier au bon agent, sur base de règles configurables. Ces règles prévoiront un routage vers les directions régionales des administrations compétentes, et une affectation par défaut à un manager qui pourra décider de l’attribution du dossier à un agent en particulier. Lors de l’attribution d’un dossier, un chef de service a la possibilité d’indiquer un objectif en termes de délais, par exemple en utilisant un facteur multiplicatif sur le délai standard de traitement en fonction de son estimation de la complexité du dossier. Dans le même ordre d’idées, l’action de prise en charge du dossier, aura un délai par défaut qui donnera lieu, comme pour les autres actions, à des notifications en cascade. Configuration des modèles d’actions Afin d’être en mesure de proposer des actions à l’utilisateur, le système contiendra une bibliothèque de modèles d’actions. A chaque modèle d’action sont associés :

La liste des métadonnées qui décrivent les actions créées à partir de ce modèle particulier, et qui s’ajoutent aux métadonnées standard (lesquelles incluent : date de début, personne en charge, prochaine échéance,...) ;

des règles qui permettent au système de déterminer quand l’action est à proposer ;

des règles qui indiquent au système ce qu’il doit faire en fonction des choix de l’utilisateur lors de la réalisation de l’action ;

des opérations à effectuer par le système ;

Les types d’événements qui peuvent être utilisés dans les règles menant à la proposition d’une action seront dans un premier temps ceux listés au paragraphe III.4.3.9.1 «La zone actions» . Les mêmes types d’événements pourront être utilisés pour définir quand le système peut considérer qu’une action est terminée. Les déclencheurs de ces règles peuvent être, en autre, mais pas seulement :

Création de certains types de documents ;

Consultation d’un document ;

Modification d’une métadonnée du dossier ou de l’un de ses éléments ;

Réception de messages ;

Événements dans un système connecté (p.ex. réception d’un paiement dans PLDA, détection d’une faillite via SITRAN) ;

Procédures en cours – changement d’état des procédures (cf III.4.3.1.5) ;

Réalisation d’une action connexe (p.ex. autorisation par un supérieur) ;

Échéance de délais ;


P. 59

Par exemple :

si un document de type X est ajouté dans le dossier, l’action « valider le document » doit être proposée ;

si un utilisateur (autorisé) change le statut du document à « validé », alors le système marque l’action « valider le document » comme terminée (et il verrouille le document) ;

si une action de type « valider le document » est terminée pour un document de type Y alors l’action « imprimer et envoyer le document » doit être proposée ;

si un utilisateur active l’action « imprimer et envoyer le document », alors le système imprime le document (et donc le verrouille, si ce n’est déjà fait) ;

Les opérations que le système peut effectuer lorsqu’une action est acceptée par l’utilisateur, ou terminée sont, entre autres :

Créer des documents d’un certain type ;

Créer d’autres actions, éventuellement pour d’autres utilisateurs ;

Envoyer un message à un autre utilisateur;

Clôturer d’autres actions ;

Lancer des modules logiciels (p.ex. lancer un calcul avec PLDA, recherche d’informations sur des systèmes extérieures, etc.) ;

Effectuer des calculs (p.ex. calculer et communiquer à l’utilisateur le calcul des récompenses dues pour un dossier) ;

Le système sera conçu pour faciliter le développement et l’ajout de modules logiciels supplémentaires utilisables comme opération dans les actions. On cherchera à trouver un équilibre entre la capacité de configuration et la simplicité, en prenant en compte le fait qu’un système de configuration plus puissant est nécessairement plus complexe. Il conviendra donc d’intégrer dans les éléments configurables du système :

la liste des modèles d’actions ;

les critères selon lesquels les actions sont proposées ;

les critères permettant de détecter la réalisation d’une action ;

les opérations que le système doit exécuter quand une action est activée ;

Récapitulatif des besoins liés aux actions


AC1 Suivi des délais et notification anticipée P1

AC2 Notification en cascade en cas de non réaction P2

AC3 Attribution manuelle d’une action à un agent par un autre agent P1

AC4 Attribution automatique d’une action sur base de règles P2

AC5 Réattribution d’une action par un chef P1

AC6 Attribution ou réattribution manuelle d’un dossier à un agent par un chef P1

AC7 Attribution automatique de nouveaux dossiers à des agents P2

III.4.3.1.5 Les procédures

Une procédure (au sens de l’AGDA) est un ensemble coordonné d’actions. Il s’agit d’étapes administratives qui se traduisent notamment par la production de documents administratifs officiels. Les procédures administratives ne se traduisent pas nécessairement en procédures informatiques ou informatisables. Elles se traduisent en revanche par un certain nombre d’actions à exécuter (cf III.4.3.1.4). On se référera au glossaire en annexe F pour la définition des différentes sortes de procédures.


P. 60

Toutes les procédures partagent un ensemble commun de métadonnées (date de début, état, liens vers les intervenants, liens vers les documents, etc.) dont la liste est configurable. Pour les agents, l’implémentation de la notion de procédure se traduira concrètement par la possibilité de sélectionner dans une bibliothèque des modèles complets de dossiers, qui incluent : dossiers et sous-dossiers types, document types (maquettes instanciées), création de certaines métadonnées et/ou initialisation de certaines actions. La liste des types de procédures, des documents que chaque type de procédure est censé produire ou utiliser ainsi que la liste des métadonnées associées à chaque type de procédure sont configurables. Mais aussi, le fait qu’une procédure ait été activée depuis la bibliothèque est une information en soi qui peut être utilisée pour le déclenchement d’actions. Par exemple : « si une procédure de type xyz est active dans le dossier, alors … ». Il est important de garder à l’esprit que, dans le contexte de ce projet, la notion de procédure est une notion propre du métier et ne correspond ni au sens courant du terme (marche à suivre, succession d'opérations à exécuter pour accomplir une tâche déterminée) et encore moins à son sens « informatique ».


PR1 Bibliothèque de procédures P2

III.4.3.1.6 Les intervenants

A chaque dossier sont associés un certain nombre d’intervenants avec lesquels les agents de l’AGDA vont collaborer :

les agents de l’AGDA qui sont intervenus dans le dossier ;

les avocats, les agents des autres SPF, les huissiers de justice et autres prestataires mandatés par l’AGDA ;

les greffes, tribunaux, policiers qui sont intervenus dans le dossier ;

Pour la plupart d’entre eux, le système fournira des informations de contact et offrira la possibilité de leur envoyer un mail avec des pièces attachées issues du dossier, ou d’imprimer un ou plusieurs documents à leur intention. Seules les versions officielles et verrouillées des documents peuvent être envoyées par mail ou par courrier.


IN1 Gestion d’un carnet d’adresses des intervenants extérieurs P1

IN2 Ajout d’un intervenant sur un dossier P1

IN3 Impression d’un document à destination d’un intervenant avec suivi de l’envoi P1

IN4 Envoi d’un mail avec pièce attachée à un intervenant P1

III.4.3.1.7 La partie adverse

A chaque dossier sont associés un certain nombre de contribuables, contrevenants ou requérants, selon que l’action des agents de l’AGDA vise à recouvrer une taxe, réprimer une fraude ou à répondre à une requête.

La ou les personnes physiques ou morales qui sont à l’origine du dossier ;

les avocats de la partie adverse ;

le ou les tiers propriétaires des marchandises ou moyens de transport saisis ;


P. 61

En ce qui les concerne, le système permettra :

de leur envoyer des documents (impression papier et/ou envoi électronique) ;

de vérifier leur identité et leur résidence (ou leur siège dans le cas des sociétés) ;

d’identifier le contentieux passé ou en cours de chacun d’entre eux ;

d’identifier le contentieux indirect, c’est-à-dire celui lié à des entreprises dont ils sont actionnaires ou gérants, dans la mesure où l’information est disponible ;

de connaître les infractions constatées antérieurement à leur encontre, ainsi que leur statut ;


AD1 Vérification des données d’identité d’une partie adverse par l’interrogation du service SITRAN (personne physique ou morale)

P1

AD2 Ajout d’une partie adverse à un dossier P1

AD3 Impression d’un document à destination d’un intervenant avec suivi de l’envoi P1

AD4 Envoi d’un mail avec pièce attachée à une partie adverse P1

AD5 Identification des biens immobiliers d’une partie adverse (interrogation de STIPAD) P3

AD6 Consulter l’historique infractionnel d’une partie adverse P1

III.4.3.1.8 Infractions, taxes, amendes, paiements, saisies

La plupart des dossiers (mais pas tous) trouvent leur origine dans une ou plusieurs infractions, auquel cas l’infraction a été enregistrée dans le système FIODA. Les infractions sont qualifiées par les agents qui les ont constatées ; elles peuvent être requalifiées par un agent de l’Administration du contentieux. Par conséquent, la liste des infractions associées à un dossier peut être modifiée (par suppression et/ou ajout). A ces infractions sont associées des dettes, notamment : des amendes, des taxes, des intérêts de retard, des frais de justice. Aux infractions sont aussi associés des paiements de diverses natures :

Paiement au comptant (éventuellement par carte ou virement) ;

Vente des marchandises saisies, ou des moyens de fraude saisis ;

Réalisation d’hypothèques ou autres ventes de biens ;

Réalisation de la garantie constituée ;

Pendant la période d’activité du dossier, l’agent verbalisant ou celui du contentieux peut procéder à des saisies qui seront réalisées (ou pas) lors de la phase de recouvrement. Dettes, paiements et saisies sont enregistrés dans le système, lequel devra assurer la cohérence de l’information avec PLDA, soit en reflétant dans PLDA les modifications effectuées dans le système, soit en mettant à jour les données du système à partir de PLDA.


DP1 Ajout d’une infraction au dossier à partir d’une liste structurée, liée à un ou plusieurs contrevenants. Suppression, modification d’une infraction et/ou d’une dette.

P1

DP2 Interrogation du système PLDA pour connaître l’état de paiement d’une dette P1

DP3 Enregistrement par le système d’une nouvelle dette dans le système PLDA P1

DP4 Interrogation du système PLDA pour calculer le montant d’une taxe, d’un droit, etc. P1

DP5 Enregistrement (manuel) des saisies et des hypothèques dans le système P1

DP6 Interrogation du système HYPO pour identifier les hypothèques sur les biens d’une partie adverse.

P3

III.4.3.1.9 Traçabilité


P. 62

Le système gardera une trace (historique) des modifications apportées aux dossiers et aux documents. La liste des opérations historicisées sera définie et configurable par l’Administration du Contentieux et du Recouvrement, certaines opérations ne nécessitant pas d’être traçables. En particulier, on enregistrera :

L’ajout, la modification, la validation, l’impression, l’envoi des documents ;

Les changements de statut des dossiers, des documents, des actions ;

La modification de certaines métadonnées ;

L’historique sera consultable :

par dossier : historique des actions prise dans le dossier, qui a fait quoi et quand ;

par agent : sur quels dossiers il travaille ou a travaillé, quels sont les dossiers en cours, quelles sont ses tâches en attente ;

Ces informations étant sujettes aux règles de protection de la vie privée, l’accès aux historiques sera limité aux agents intervenant sur le dossier (historique du dossier), à leurs responsables hiérarchiques et au contrôle interne. L’historique doit pouvoir être consulté en deux modes :

Pour l’audit et le contrôle interne : visualisation complète de toutes les modifications ;

Pour le suivi des dossiers : visualisation des actions « importantes » (liste configurable), telles que p.ex. finalisation d’un document, validation par un supérieur, transmission à un intervenant, en excluant les détails tels que les modifications de chaque métadonnée.

L’historique n’a pas pour objectif de permettre d’annuler une opération (dans le sens de revenir à un état antérieur du système).


TR1 Historiciser les modifications des documents et des métadonnées dans le système P1

TR2 Interface de consultation de l’historique brut, avec droits d’accès spécifiques. P1

TR3 Interface de consultation de l’historique sous forme de ligne du temps simplifiée P2

III.4.3.1.10 Utilisateurs

Le système associe à chaque utilisateur un certain nombre de droits d’accès. Le système dispose, via LDAP, des données concernant le service auquel les utilisateurs appartiennent, et peut donc identifier leur localisation et leur responsable hiérarchique. Ces informations génériques seront complétées par des informations spécifiques gérées dans le système (profil utilisateurs). La liste des informations est configurable. Des droits par défaut seront accordés aux utilisateurs. Les profils seront initialisés et mis à jour à partir de LDAP. Les utilisateurs pourront consulter les données spécifiques les concernant et en modifier certaines (liste configurable).


UT1 Gestion des droits d’accès des utilisateurs sur les dossiers et documents P1

UT2 Gestion de profils utilisateurs P1


P. 63

III.4.3.2 Impression des documents

Les documents imprimés seront d’abord produits en PDF, enregistrés dans le système, puis imprimés via le système d’exploitation, selon les standards ICT du SPF. Le système permettra d’imprimer aussi bien les documents créés à partir de maquettes que les documents importés (dans la mesure où le logiciel qui a servi à les créer est connu et permet de générer une version imprimable). Le système permet deux sortes d’impression :

Impression « draft » : le document est imprimé aux fins de relecture par l’agent, sous une forme non officielle. Dans ce cas, pour éviter toute confusion, la nature du brouillon doit être extrêmement visible sur le document imprimé : filigrane « brouillon » (dans la langue de l’utilisateur), ni en-têtes ni mentions légales, zones de signatures barrées, etc. Le PDF n’est alors pas conservé.

Impression « officielle » : le document est imprimé pour signature, avec en-têtes et mentions légales. Cette impression valide implicitement le document et donc le verrouille en lecture seule (document et métadonnées imprimées). Les fichiers PDF sont enregistrés dans le système et ni supprimables, ni modifiables.

Dans le cas des versions officielles, le système permettra d’imprimer et d’importer ensuite une version signée (et scannée) du document qui sera associée à la version officielle. Ainsi, si l’on combine avec l’emploi des langues (voir section III.4.3.4), un document aura plusieurs versions : l’officielle, la signée, et éventuellement des traductions.

III.4.3.3 Envoi des documents

Les documents qui doivent être communiqués à des tiers peuvent l’être par deux canaux principaux : email et courrier papier. L’envoi d’un document par l’un ou l’autre canal présuppose la validation des documents : seules des versions officielles peuvent être communiquées. L’envoi par mail de documents générés par le système se fera uniquement au format PDF avec texte sous image. L’envoi par courrier d’un document sera enregistré (p.ex. dans une métadonnée) ainsi que les informations de suivi (recommandés). L’agent pourra scanner un accusé de réception et l’associer au document. Éventuellement, cela peut exiger que le concept « d’envoi » soit implémenté. En effet, il doit aussi être possible d’envoyer plusieurs documents dans un même mail, ou de suivre l’envoi de plusieurs documents dans un même courrier.


DC10 Génération de documents à partir d’une maquette et de métadonnées P1

DC11 Impression « draft » P1

DC12 Impression officielle avec verrouillage du document, gestion des versions signées P1

III.4.3.4 Multilinguisme

L’interface utilisateur doit être disponible dans les trois langues nationales. L’AGDA fournira les textes et aura la possibilité de les configurer ultérieurement sans recourir aux services du fournisseur. La langue à utiliser pour l’interface est définie par la localisation du système d’exploitation du poste du client. En outre, les maquettes de documents existeront aussi dans plusieurs langues, éventuellement autres que les trois langues officielles, en prévision des interactions avec des intervenants étrangers. Toutes ces maquettes sont réalisées par l’AGDA. Le système doit permettre à un agent de spécifier, pour chaque document, la langue dans laquelle il doit être produit, en fonction des maquettes disponibles et des métadonnées du dossier (dont, entre autres, la langue des intervenants). Par exemple : dans certains cas, un courrier vers un contrevenant


P. 64

doit lui être adressé dans sa langue, quelle que soit la langue de l’agent. Si plusieurs contrevenants sont impliqués, un même document doit pouvoir être envoyé dans plusieurs langues. Le système doit donc, d’une manière ou d’une autre, gérer l’existence de plusieurs versions d’un même document officiel (une version par langue). Cela signifie que les valeurs possibles de certaines métadonnées sont elles aussi multilingues. Par exemple : imaginons une métadonnée intitulée « décision » peut prendre plusieurs valeurs prédéfinies, telles que « accepté » ou « rejeté », alors le système doit utiliser une traduction de ces mots clés dans la langue choisie pour le document, pour peu que cette traduction existe. Il est de la responsabilité de l’Administration du Contentieux et du Recouvrement d’encoder les traductions pour les différentes valeurs possibles des métadonnées. Le système doit signaler une erreur (non bloquante) quand un document est produit dans une langue pour laquelle il n’existe pas de traduction pour une métadonnée qui doit y figurer car cela peut influencer la valeur légale du document produit. Enfin, il peut arriver que :

Un traducteur externe traduise un document produit par le système dans la langue de son destinataire. Dans ce cas, la version du traducteur pourra être scannée et intégrée dans le système, attachée au document original ;

Un document soit fourni dans une langue non-officielle, scanné et qu’une traduction (officielle ou non) lui soit attachée ;


LN1 Interface dans la langue de l’utilisateur définie par la localisation P1

LN2 Gestion de maquettes multilingues P1

LN3 Importer une traduction externe d’un document et l’attacher à celui-ci en tant que version officielle

P2

III.4.3.5 Configuration des fonctionnalités

L’AGDA pourra paramétrer elle-même certains aspects du comportement du système sans devoir recourir à un service technique informatique (ni externe, ni interne) : ce sont ses gestionnaires fonctionnels qui le feront. Seront configurables les éléments suivants (liste non exhaustive) :

création et modification de maquettes de documents, ce qui inclut, entre autres ;

o mise en page avec champs ;

o identification des métadonnées utilisées pour remplir le document ;

o identification des champs obligatoires ou optionnels ;

o règles de validation des documents par un supérieur ;

o règles de verrouillage, le cas échéant ;

définition de types d’actions et de la liste des métadonnées associées, ce qui inclut, entre autres :

o règles de déclenchement et de changement d’état de l’action ;

o délais par défaut et maximum ;

définition de métadonnées, ce qui inclut, entre autres :

o indication des cas dans lesquels la métadonnée fait sens ;

o définition du champ d’application (dossier, document, action, utilisateurs, etc.) ;

o règles permettant éventuellement d’en calculer la valeur ;


P. 65

définition de procédures ;

Une interface permettra de réaliser les configurations. Une formation spécifique pourra être requise pour former une équipe limitée de gestionnaires fonctionnels à la configuration du système via cette interface (voir III.6.1 – formation « power user / application administrator »).


MQ1 Création et édition de maquettes de documents, de modèles de procédures, de types d’actions et de métadonnées.

P1

III.4.3.6 Exportation de données

Le système exportera une partie de l’information sur les infractions, les recouvrements et les procédures contentieuses vers le SCGI aux fins de l’établissement de statistiques. Exemples de données à exporter, pour chaque constatation : numéro de dossier, identification de la direction régionale, date d’inscription, service concerné, type d’acte, matricule de l’agent, montant, date de paiement, nombre de paiements enregistrés, etc. La liste des données sera définie en cours de projet (sur base de la liste des données qui étaient auparavant encodées dans FINADA et TFR). Il est déjà acquis qu’il s’agira d’une base de données d’exportation uniquement, utilisant un nombre minimal de tables et de relations. La simplicité sera favorisée par rapport à l’optimisation. Le système doit permettre de configurer l’exportation au moyen d’un tableau d’association entre les métadonnées et les tables cibles. La mise à jour doit être quotidienne mais pas en temps réel.


ST1 Exportation de métadonnées vers une base de données « plate » P1

III.4.3.7 Base de connaissances

Les agents souhaitent pouvoir rechercher des informations dans l’ensemble des dossiers afin que le travail effectué puisse servir de précédent administratif, voire de jurisprudence. La recherche doit pouvoir porter sur la valeur de certaines métadonnées, sur des mots-clés ou sur le contenu des pièces. Par ailleurs, des documents choisis par les agents doivent pouvoir être spécifiquement marqués pour constituer une base de connaissance structurée consultable par les autres agents de l’Administration du Contentieux et du Recouvrement. Le système devra donc prévoir l’indexation des documents, pièces et métadonnées des dossiers.


KB1 Recherche dans les données et documents, avec indexation P2

KB2 Sélection pour la constitution d’une base structurée de connaissances, avec indexation P3

III.4.3.8 Interface d’enregistrement des infractions (FIODA)

FIODA fournit une interface pour le traitement des infractions à destination des agents qui les constatent, les verbalisants. En pratique FIODA permet à ces agents de :

1. Créer des actes de constatation (PV, constats), organisés en dossiers infractionnels ;

2. Compléter ces dossiers avec des documents accessoires ;


P. 66

3. Transmettre le dossier aux services compétents, internes ou externes à l’AGDA ;

4. Compléter le cas échéant les dossiers à la demande desdits services ;

5. Suivre l’état des dossiers quand ceux-ci sont traités par l’Administration du Contentieux et du Recouvrement. Dans le cas où un dossier a été transmis à un autre service public (p.ex. SPF Justice), il n’y a pas de suivi automatique mais le système permettra à l’utilisateur d’enregistrer manuellement des notes sur le suivi des dossiers.

FIODA fournit deux interfaces :

1. une interface utilisateur conviviale pour la création de dossiers infractionnels ;

2. un web service pour les services de l’AGDA qui disposent de leur propre système (p.ex le système CAMADA de l’Administration Enquêtes et Recherches).

Que ce soit par l’interface utilisateur ou par le web service, FIODA est l’unique canal permettant d’introduire des dossiers infractionnels dans le système. La valeur ajoutée de FIODA réside dans l’assistance aux utilisateurs, afin de :

ne pas encoder deux fois la même information ;

rechercher l’information dans des bases de données plutôt que de l’encoder (p.ex. accès au registre national via SITRAN) ;

grouper les documents en un dossier virtuel ;

savoir si une personne (physique ou morale) a déjà fait l’objet d’un acte de constatation de la parte de l’AGDA.

III.4.3.8.1 L’interface utilisateur

Généralités L’interface utilisateur de FIODA permet de faciliter et contrôler la création, le remplissage et la transmission des formulaires au moyen d’une assistance la plus contextualisée possible. Les explications données ci-dessous le sont à titre indicatif et illustratif. L’interface définitive sera définie et validée lors de la phase d’analyse. Une fois l’utilisateur connecté, le système accède à son profil et établit un lien avec la liste des activités qu’il est susceptible d’effectuer. Une partie des données vient du LDAP du SPF finances (p.ex. matricule, code service), une autre sera enregistrée dans le système et modifiable par les utilisateurs autorisés (p.ex. unité, types de missions) (voir section III.4.3.1.10). Ayant ainsi réduit la liste des possibilités, le système peut proposer un écran sur lequel un petit nombre de larges icônes permettent à l’agent de choisir rapidement l’opération à effectuer. Par exemple, un agent de l’aéroport de Bierset pourrait se voir proposer comme choix initial : contrôle de marchandises aéroportuaires, contrôles de personnes ou travail de bureau. Si par exemple, il choisit la première option, alors les différentes catégories de contrôles lui seraient proposées. Une approche contextualisée est nécessaire au vu du grand nombre d’actes de constatation et/ou de variantes qui existent. L’idée est de réduire le nombre d’étapes avant d’entamer la phase de remplissage des formulaires, tout en réduisant le nombre de choix présentés à l’écran. Les types d’actions dans FIODA sont en pratique limités à :

Créer un nouveau dossier (multiplié par autant de types de dossiers) ;

Créer un document dans un dossier (multiplié par autant de types de documents) ;

Consulter un dossier ;

Valider un dossier (par un responsable hiérarchique) ;

Envoyer un dossier pour traitement par le service compétent ;


P. 67

Login

Login

Password

Selection

Saisie de données

DonnéeDonnée

Donnée

Valider

Dossier

Formulaire rempli de l 'acte / fac simile

Enregistrer

Imprimer

Env oyer

+

Document en construction interactive

Icone

Icône

Icône«navigate»

«navigate»

«navigate»

«navigate»

«navigate»

Figuur 4 - Navigation dans FIODA

L’écran de sélection L’écran de sélection est le premier qui apparaît après le login. Son rôle est de permettre à l’agent d’accéder le plus rapidement possible à l’action qu’il souhaite réaliser. Cela pourrait se faire en tenant compte du fait que chaque agent est amené, de par son affectation, à réaliser en général un nombre limité d’actions par rapport à tout ce qui est théoriquement possible. L’accès aux actions les plus probables peut donc être facilité, sans empêcher pour autant l’accès aux autres actions. Le profil de l’utilisateur contient les informations nécessaires pour effectuer une partie du filtrage. Les critères définissant les jeux d’icônes à proposer en fonction du profil, ainsi que la liste des actions associées à chaque icône, sont configurables par les gestionnaires. On peut aussi envisager que les utilisateurs aient la possibilité d’influer sur ces listes, de la même manière qu’un utilisateur d’ordinateur personnel peut configurer les icônes de son bureau. Dans l’exemple donné en Figuur 4 - Navigation dans FIODA, la sélection se fait en 3 étapes :

Identification du groupe de tâches en fonction du lieu de travail (contrôle aéroportuaire, contrôle routier, bureau, etc. – cette liste dépendant de l’affectation de l’agent : on n’affichera pas l’aéroport pour des agents affectés au port d’Anvers, et réciproquement) ;

Identification du type d’action : PV, Constat, etc. – en général identifié par un code (614, 359) dont les agents sont supposés connaître la signification ;

Identification du type d’infraction (avec les références légales) ;


P. 68

Le principe est que le choix fait dans la première zone restreint le contenu de la seconde, et ainsi de suite. Le choix d’un élément de la troisième zone lance l’action, en l’occurrence, par exemple : création d’un dossier d’infraction contenant un premier document et assistance au remplissage de ce document avec la marchandise sélectionnée. L’objectif est de rendre le travail plus efficace en mettant en avant les actions « standard », sans pour autant empêcher les utilisateurs de traiter les cas particuliers ou inhabituels. L’écran de saisie de données L’écran de saisie est fondamental : c’est là où l’agent reçoit l’assistance nécessaire pour le remplissage d’un modèle de document. On privilégiera une approche « semi-WYSIWYG » : il est utile que la disposition de l’écran de saisie reflète globalement la disposition des informations sur le document papier, mais il n’est pas nécessaire que l’apparence du document papier soit strictement reproduite à l’écran. Concrètement, cela peut prendre la forme d’un formulaire dont les champs sont positionnés approximativement au même endroit que sur le document officiel. Les autres fonctionnalités attendues sont :

1. Le système appliquera des règles (configurables) pour remplir certains champs à partir d’autres. Par exemple :

o coordonnées du contrevenant à partir de son numéro d’identification du registre national ou de son numéro d’entreprise (interrogation du système SITRAN) ;

o caractéristiques du véhicule à partir du numéro de plaque d’immatriculation ou de châssis (interrogation de la DIV) ;

2. Réutilisation des données d’un formulaire à l’autre, p.ex. entre un constat validé et un nouveau PV.

3. Utilisation de « formlets » ainsi que décrit en section III.4.3.1.3.

Les documents peuvent être enregistrés dans le système et modifiés jusqu’à leur validation et/ou leur impression en version officielle (cf III.4.3.2). L’écran de gestion du dossier infractionnel L’écran de gestion du dossier infractionnel représenté en Figuur 4 - Navigation dans FIODA contient une zone « documents » dans laquelle la liste des documents du dossier apparaît, ainsi que leur statut, leur auteur et éventuellement d’autres métadonnées configurables. Chaque document peut être visualisé en cliquant dessus. Il est possible d’ajouter des documents crées par d’autres moyens, tels que : fichiers Word, Excel ou PDF (p.ex. scan). Il est aussi possible d’importer directement des mails et leurs pièces attachées. Les fichiers ne doivent pas nécessairement être visualisés par le système lui-même mais peuvent l’être par des outils externes (MS Word, Adobe Reader, etc.). Dans le cas de l’importation de documents, une métadonnée permettra de renseigner – quand cela fait sens – où se trouve le document original (p.ex. l’original papier d’un document scanné). Les documents validés ne peuvent plus être modifiés mais ils peuvent servir de modèle pour créer, par copie, un nouveau document dans le même dossier. Le nouveau document est indépendant de l’ancien, il est simplement initialisé avec les données contenues dans le document d’origine – néanmoins, sa date de création change (cf III.4.3.1.3). La modification de métadonnées ne doit pas avoir d’impact sur les documents verrouillés : ils le sont avec les données présentes au moment du verrouillage. Le système prévoira une manière simple de visualiser les différences entre la version verrouillée et les données éventuellement modifiées (cf III.4.3.1.3).


P. 69

Le document d’origine et sa version plus récente coexisteront donc dans le système. L’utilisateur peut décider de marquer la première version comme obsolète, ce qui a pour effet de la déplacer vers un sous-dossier d’archivage. Cette opération doit être tracée aux fins de contrôle interne. Les documents d’un même dossier d’infraction peuvent avoir des statuts différents. Chaque sous-dossier peut être communiqué à un destinataire qui dépend du type d’infraction, de la localisation du service de l’agent et/ou d’autres métadonnées. Les documents d’un dossier peuvent être envoyés à plusieurs destinataires différents. Les règles de routage seront configurables par les gestionnaires. L’envoi se matérialise soit :

a) par l’impression des documents, qui seront mis sous enveloppe et expédiés par l’agent ;

b) par la création d’un dossier contentieux/recouvrement ;

c) par l’envoi du dossier au chef hiérarchique (selon des critères configurables) ;

On pourra aussi bénéficier de la possibilité de placer un même document dans plusieurs dossiers en créant des « dossier d’envoi » dont les documents seront imprimés et validés collectivement. Ces actions seront bien sûr historicisées. En outre, le fait qu’un document ait été transmis à un tiers sera marqué de façon visuelle afin que l’agent connaisse immédiatement le statut d’un dossier et des documents qui le composent. L’historique sera visuellement présenté à l’écran de façon claire et synthétique afin que les agents puissent voir les actions qui ont marqué la vie du dossier, y compris leur date et leur auteur. Cette ligne du temps intégrera les échéances futures du dossier (prochains délais arrivant à expiration). Actions dans FIODA FIODA utilisera le système de gestion des actions pour, entre autres :

La notification au chef hiérarchique qui doit valider certains dossiers avant leur communication à l’Administration du Contentieux et du Recouvrement (validation conditionnelle, selon le type de dossier et/ou certaines caractéristiques telles que les montants en jeux ou le type de marchandises, etc.) ;

La notification de la part de l’Administration du Contentieux et du Recouvrement pour la demande de corrections de documents, ou de documents complémentaires.

III.4.3.8.2 L’interface technique (web service)

FIODA fournira un web service permettant à des applications tierces de transférer des dossiers infractionnels. Par exemple, cela servira à CAMADA pour transférer des dossiers de l’Administration des Enquêtes et Recherches vers l’Administration du Contentieux et du Recouvrement. Le processus de base est le suivant :

1. L’utilisateur utilise son application usuelle pour son travail ;

2. Au moment où il souhaite communiquer les infractions à l’Administration du Contentieux et du Recouvrement, il demande à son application de créer et initialiser un dossier infractionnel ;

3. Son application communique les données à FIODA au moyen du Webservice ;

4. Le webservice FIODA crée le dossier infractionnel et renvoie le numéro de dossier créé, ainsi que le lien vers ce dossier ;

5. L’application bascule vers le client FIODA grâce auquel l’agent peut consulter le dossier infractionnel, le compléter et le valider ;


P. 70

Le web service FIODA ne permet pas de réaliser toutes les opérations de FIODA, mais uniquement :

a. Créer un dossier infractionnel vide ;

b. Ajouter des documents à un dossier infractionnel ;

c. Clôturer un dossier infractionnel et le transmettre au TIBODA;

d. Obtenir le statut d’un dossier infractionnel ;

Le webservice est crypté et sécurisé.

III.4.3.9 Interface pour la gestion des litiges et du recouvrement

Cette section décrit ce qui pourrait constituer les grandes lignes fonctionnelles de la solution. Les explications données ci-dessous le sont à titre indicatif et illustratif. L’interface définitive sera définie et validée lors de la phase d’analyse. Outre un écran d’accueil pour l’identification de l’agent, le système fournit deux écrans :

1. un écran de synthèse donne à chaque agent une vue d’ensemble de ses dossiers en cours, avec signalement des événements récents et des retards potentiels ou avérés. Une variante est disponible pour les chefs d’équipe, qui leur permet de visualiser l’ensemble des dossiers de leur équipe. A partir de cet écran, l’agent peut ouvrir un dossier ou en créer un nouveau.

2. un écran de travail permet d’interagir avec un dossier donné.

Trav ail sur un dossier

(from Travail sur un dossier)

Login Selection de la tâche

(from Selection de la tâche)

Recherche de dossier

«navigate»

«navigate»

«navigate»

«navigate»«navigate»

«navigate»

Figuur 5 - Navigation dans l’interface TIBODA

D’une manière ou d’une autre, le système permet de consulter plusieurs dossiers simultanément (fenêtres, onglets, basculement rapide, etc.).

III.4.3.9.1 L’écran de travail sur un dossier

L’écran de travail pourrait être divisé en zones dédiées aux informations ci-dessous :

1. les documents du dossier, groupés en dossiers définis par l’utilisateur ;

2. les procédures en cours, leur état d’avancement ;

3. les intervenants du dossier :

o une zone pour les représentants des services publics et les prestataires qu’ils mandatent pour les représenter (huissiers de justice, avocats, etc.);

o une zone pour la ou les parties adverses.

4. les actions en cours ;

5. les actions « futures » ;


P. 71

6. la « ligne du temps » des actions réalisées jusqu’à présent et des actions planifiées ;

Trav ail sur un dossier

Historique

Interventants

Services Publics

Contrevenant(s)

Infractions Paiements,

ventes et saisies

Procédures

passées et en

cours

Taxes, amendes,

frais

Autres...

+ -+ - + -

Documents

DOSSIER

Tâches en

cours

Tâches

suggérées

+

+

Figuur 6 - L'écran de gestion du dossier de contentieux

La zone « documents » La zone « Documents » reprend tous les documents produits au moyen de l’outil, ainsi que ceux qui ont été enregistrés dans l’outil : fichiers office, mails, pages web ou documents PDF scannés. Chaque document peut être placé (par lien, sans recopie) dans un ou plusieurs dossiers, de préférence par un simple glissement. La visualisation d’un document mettra en évidence les métadonnées encodées ou à encoder et en permettra un encodage rapide (éventuellement un encodage dans le corps du texte, couplé à un encodage dans une zone formulaire). Le système permettra de visualiser les fichiers dans une fenêtre séparée, soit directement, soit par l’ouverture d’une application (p.ex. MS Word ou Acrobat Reader, voir aussi III.4.3.1.3). La zone « Procédures » La zone procédures reprend la liste des procédures qui ont été initiées pour ce dossier. Elles sont par défaut triées par date décroissante. Dans le cas où la place viendrait à manquer, les procédures clôturées ou les plus anciennes ne seront pas nécessairement visibles, ou alors avec des icônes plus petites. Un signe visuel simple indiquera aux utilisateurs l’état de la procédure, c.-à-d. essentiellement le temps restant avant une action de leur part. Cela pourrait être visualisé au moyen d’une jauge. Une interaction avec l’icône d’une procédure (p.ex. clic ou survol curseur) permettra d’afficher les documents qui y sont liés (dans la zone documents), et cela pourra aussi avoir un effet de mise en évidence des autres parties de l’écran liées à cette procédure (acteurs, montants, etc.). Une autre interaction (p.ex. double clic) permettra de voir l’ensemble des métadonnées de la procédure. Le changement de l’état d’une procédure (ou de manière générale, de toute métadonnée d’une procédure) peut donner lieu à la modification de la liste des actions proposées par le système (voir ci-dessous).


P. 72

La zone « actions » La zone des actions est double :

1. actions en cours d’exécution ;

2. actions proposées par le système ;

Les actions en cours Les actions en cours d’exécution correspondent à des actions entamées par l’utilisateur et qui doivent être complétées endéans un certain délai (visualisé sur l’icône de l’action par une jauge). Les actions proposées par le système Le système maintient une liste des actions qui seraient pertinentes pour la suite du dossier. Cette liste d’actions sera établie sur base de règles faisant intervenir l’ensemble des métadonnées du dossier. Ces règles sont configurables. Voir sections III.4.3.1.4 et III.4.3.5. L’utilisateur pourra activer une des actions proposées ou bien masquer une action de la liste des propositions si elle n’est pas d’application dans son cas concret. Par ailleurs, l’utilisateur pourra à tout moment initier une action qui n’est pas dans la liste (bouton « autres » ou équivalent). En particulier, une action non-typée pour des actions qui ne sont pas prévues dans le flux habituel des opérations. Il sera possible de marquer manuellement une action comme effectuée, par exemple quand l’exécution se passe hors du champ du système. En effet, les tâches assignées aux agents ne sont pas nécessairement toutes des tâches informatisées. En cas d’erreur de manipulation, il est possible de marquer une tâche effectuée comme à nouveau active. La zone « Intervenants » La zone « Intervenants » est divisée en deux sections :

1. une zone pour les intervenants : les personnes physiques ou morales qui interviennent au nom, pour le compte ou sur ordre d’un Service Public et qui collaborent sur le dossier ;

2. une zone pour la partie adverse : les personnes physiques ou morales requérantes ou contrevenantes et leurs représentants ou associés éventuels ;

Il est possible d’interagir avec les symboles des intervenants pour :

voir la liste des documents qui leur sont liés (filtre dans la zone Documents) ;

voir leur coordonnées, leur envoyer un message (archivé dans les documents) ou leur adresser un courrier ;

pour les contrevenants, inspecter leur historique :

o dossiers contentieux impliquant le contrevenant ;

o idem pour les relations du contrevenant : employeur, employé, firmes dont il est gérant ou actionnaire – dans la mesure où une telle information est disponible ;

o cette liste indique le rôle du contrevenant dans chaque dossier sans qu’il soit besoin de consulter le dossier ; elle contient aussi un lien vers le dossier.

L’historique du dossier L’historique du dossier reprend toutes les opérations qui ont été effectuées dans le dossier par un utilisateur (voir aussi section III.4.3.1.9).


P. 73

Pour des raisons de lisibilité, on cherchera à éviter un long listing d’opérations atomiques mais on les regroupera les actions de façon hiérarchique et logique (p.ex. « Ajout, modification et impression de document », « actions de la semaine du … », etc.). Un effort particulier sera fait pour présenter l’historique sous la forme d’une ligne du temps claire et lisible. Cette ligne du temps intégrera les échéances futures du dossier (prochains délais arrivant à expiration). La zone infractions La zone infraction reprend la liste des infractions retenues contre chacun des contrevenants. Initialisée à partir de FIODA mais modifiable par l’agent du contentieux et recouvrement en charge du dossier. Les zones financières Deux zones donnent des informations sur la dimension financière du dossier.

1. La zone « Droits, Taxes et Amendes » liste les droits, les taxes diverses, les amendes, les intérêts et autres montants réclamés au(x) contrevenant(s). Le montant peut varier d’un contrevenant à l’autre dans un dossier. La nature des montants doit être précisée. Les montants peuvent être modifiés, ou supprimés et remplacés par de nouveaux montants en cas de requalification des faits ou de négociation. Ces montants sont enregistrés dans PLDA.

2. La zone « Paiements » donne la liste des paiements déjà effectués, soit à titre définitif, soit à titre de caution. Dans le cas de plusieurs paiements échelonnés, le total seul est repris, avec possibilité d’accéder aux détails des paiements. La source de ces informations est PLDA. On y trouve aussi la liste des marchandises retenue, saisies et/ou vendues (avec leur contrevaleur estimée ou obtenue), ainsi que celle des hypothèques prises (idem). Le système permet d’accéder à la liste des biens hypothécables de chaque contrevenant (via Stipad), ou d’autres biens identifiés par enquête mais non encore saisis.

Calendrier Le calendrier reprend les grandes étapes passées du dossier et les jalons futurs. On définira ultérieurement quels événements (p.ex. début/fin de procédure, types d’actions, etc.) doivent figurer dans le calendrier afin de ne pas le surcharger. Cette fonctionnalité est aussi disponible dans FIODA.

III.4.3.9.2 L’écran de sélection des dossiers

Une fois connecté sur le système, l’agent voir la liste des dossiers ouverts, avec une synthèse des informations importantes à propos de ce dossier (métadonnées). En particulier, l’existence d’échéances proches doit être marquée de façon visuelle, par exemple par une pastille rouge sur l’icône du dossier indiquant le nombre de jours ouvrables restant pour réaliser la prochaine action, quand ce nombre de jours est inférieur à une certaine valeur (configurable). Cet écran permet aussi de créer de nouveaux dossiers, éventuellement à partir d’une bibliothèque de dossiers types.

III.4.3.10 Interface pour le management

Les responsables d’équipe et de services auront une utilisation complémentaire spécifique du système afin qu’ils puissent superviser le travail effectué par leurs équipes. Leurs besoins sont :

1. Identifier les dossiers traités par un agent donné ;

2. Mesurer le temps moyen de traitement d’un dossier, ainsi que l’écart-type ;

3. Identifier les dossiers en retard, ou sur lesquels aucune action n’a été prise ;


P. 74

4. Réaffecter un dossier complet d’un agent vers un autre ;

Ces besoins seront satisfaits si le système propose aux agents identifiés comme managers, une interface complémentaire qui permette de consulter ces informations. Cette interface doit lister les dossiers du service du manager, de façon récursive dans le cas des managers de rang supérieur. Chaque entrée de la liste doit comporter, outre l’intitulé du dossier, des informations telles que le nom de l’agent en charge, la date d’ouverture et la date de la prochaine action, ainsi que la valeur de certaines métadonnées choisies. Il est possible de trier la liste sur n’importe laquelle des informations ci-dessus (donc : par agent, par date, par statut ou par toute métadonnée). Lorsque les informations sont triées, elles sont affichées de façon groupée par valeur et indentée de façon à en augmenter la lisibilité. Il sera aussi possible de trier sur plusieurs champs (p.ex. par agent, et pour chaque agent, par état). Pour chaque regroupement, le système affichera le nombre total d’entrées – il sera donc possible de visualiser de cette façon le nombre de dossiers ouverts par agent. Les managers peuvent choisir la ou les dispositions qu’ils jugent plus utiles et les enregistrer. Il est possible d’accéder directement au dossier depuis la liste, et ainsi de le consulter et/ou de le modifier. En particulier, on veillera à ce que d’une manière ou d’une autre, il soit relativement simple de réaffecter un dossier d’un agent à un autre. L’ensemble de ces fonctionnalités sera disponible aussi bien pour les managers des verbalisants que pour les managers de l’Administration du Contentieux et du Recouvrement.

III.4.3.11 Interface de configuration et administration

Il est fondamental que le comportement du système puisse être configuré sans programmation. Cela concerne en particulier :

la liste des métadonnées ;

la liste des actions et leur comportement : selon quelles règles sont-elles proposées ? quels sont les délais par défaut ;

les règles d’affectation des dossiers et des actions en fonction des métadonnées du dossier ;

la création et la mise en page des maquettes de documents, en ce y compris la définition des métadonnées qui y sont insérées ;

tous les points mentionnés comme « configurables » dans ce document.

Il est donc impératif de définir et implémenter :

une interface utilisateur spécifique aux gestionnaires de la configuration ;

une formation pour ces utilisateurs ;

une procédure technique qui permette d’intégrer les modifications dans le système en minimisant les perturbations :

o Ajout de nouveautés ;

o Modification de règles existantes ;

o Modification de maquettes – en prenant garde à l’impact sur les documents passés ;

o Procédure de test et de contrôle de l’impact avant intégration dans le système en production


P. 75

L’AGDA définira une gouvernance qui clarifiera qui peut décider de modifications de la configuration, qui peut les effectuer et selon quels processus. Par exemple :

les règles d’affectation sont du ressort régional ;

les modèles de documents sont par défaut du ressort central.

III.4.3.12 Récapitulatif des besoins en interfaces


IN1 Interface Fioda P1

IN2 Interface Contentieux et Recouvrement P1

IN3 Interface Managers P2

IN4 Interface pour les gestionnaires de configuration P1

III.4.3.13 Points d’accès

Pour la partie TIBODA, le système sera utilisé par les agents de l’Administration du Contentieux et du Recouvrement depuis leur bureau. Ils disposent de postes fixes connectés par un réseau filaire. Pour la partie FIODA, le système sera utilisé soit depuis des bureaux de l’AGDA (postes fixes), soit depuis des postes de contrôle mobiles, tels que des camionnettes. Du fait que les accès mobiles se feront en utilisant la technologie 3G, les débits seront plus lents. L’interface FIODA devra donc prévoir un mode de fonctionnement qui réduise les échanges de données au strict minimum. L’AGDA envisage de doter ses agents en déplacement de tablettes. Le système devra donc pouvoir évoluer vers ce type d’interfaces avec le moins de redéveloppements possible.


EN10 Interface simplifiée pour l’accès en connectivité dégradée (3G) P2

III.4.3.14 Échanges de données avec systèmes externes

III.4.3.14.1 Interface avec SITRAN

SITRAN est une base de données destinée aux collaborateurs du SPF Finances regroupant les informations de différentes bases de données externes identifiées comme sources authentiques, en l’occurrence : le Registre national, la Banque-Carrefour des Entreprises de la Sécurité Sociale et la Centrale des Bilans de la Banque Nationale. Sur base du nom et prénom ou du numéro de registre national d’une personne physique, on doit pouvoir consulter toutes les informations la concernant, en vue de la vérification de son identification et de sa localisation correctes. L'administration a ainsi un résumé complet sur l’individu, en ce qui concerne la date de naissance, le lieu de naissance, l'historique des adresses et de la composition de la famille. La recherche doit aussi pouvoir s’effectuer en intégrant le code postal et la date de naissance si nécessaire. Des informations comparables sont aussi disponibles pour les personnes morales : à partir d’une recherche sur les données fournies (p.ex. nom, numéro d’entreprise, code postal), on retrouvera depuis SITRAN l’intégralité des coordonnées de l’entreprise. En particulier, on vérifiera via SITRAN le statut des sociétés (actives ou en faillite). La mise à jour des données enregistrées dans le système à partir des sources authentiques rassemblées par SITRAN doit se faire uniquement aux moments opportuns :


P. 76

ajout d’une nouvelle partie adverse à un dossier (en particulier, lors de la création d’un nouveau dossier)

envoi d’un courrier à une partie adverse (vérification de l’adresse) ;

à la demande expresse d’un agent qui demande une vérification (pour un dossier) ;

On envisagera la possibilité d’interroger SITRAN de façon asynchrone (p.ex. la nuit) pour identifier les sociétés impliquées dans des dossiers qui auraient été mises en faillite. SITRAN dispose d’un webservice fournissant les informations requises. Les coupures de connexion de ce système ne doivent pas être bloquantes.

III.4.3.14.2 Interface avec STIPAD

STIPAD est le Système de Traitement Intégré de la Documentation Patrimoniale. Il reprend toutes les données concernant la composition (actif et passif, biens mobiliers et immobiliers) et la valeur du patrimoine de toutes les personnes physiques et morales belges. Dans le cadre des mesures conservatoires ou exécutoires, l’administration, à tout moment du traitement d’un dossier, doit pouvoir, via le système, prendre connaissance des biens immobiliers du contrevenant. Cela concerne à la fois les personnes physiques et les personnes morales. La consultation doit être possible à partir du nom du contrevenant et de son numéro national ou numéro d'entreprise. À partir des informations obtenues de STIPAD, l’administration doit pouvoir décider s'il est rentable de procéder à la saisie (conservatoire ou exécutoire) ou de prendre une inscription hypothécaire. Tous les aspects du bien immobilier doivent pouvoir être consultés : copropriétaires, type et taux des droits, RC, inscriptions hypothécaires des autres débiteurs… STIPAD dispose d’un webservice fournissant les informations requises. Les coupures de connexion de ce système ne doivent pas être bloquantes.

III.4.3.14.3 Interface avec Hypo

On récupérera les informations sur les biens immobiliers déjà hypothéqués. Les coupures de connexion de ce système ne doivent pas être bloquantes.

III.4.3.14.4 Interface avec KBO/BCE

À partir du nom d’un contrevenant personne morale, toute l’information relative à cette personne morale doit être consultable, en vue de l’identification correcte, de la localisation et de la détermination de la solvabilité du contrevenant personne morale. Si le nom de la personne morale ne suffit pas, la recherche peut être étendue au code postal ou au numéro d’entreprise. L’administration a besoin d’une vue complète sur les statuts (situation, sièges d’exploitation, gérants, historique) et sur les comptes annuels. Cette interface ne sera à considérer que dans la mesure où les données de la Banque Carrefour des Entreprises ne sont pas déjà disponibles via SITRAN. Les coupures de connexion de ce système ne doivent pas être bloquantes.


P. 77

III.4.3.14.5 Interface avec la DIV

On récupérera auprès de la DIV les données sur un véhicule (propriétaire, taxes payées, etc.) au moyen d’une recherche sur le numéro de plaque ou sur le numéro de châssis. Les coupures de connexion de ce système ne doivent pas être bloquantes.

III.4.3.14.6 Interface avec PLDA

« Paperless Douanes et Accises » est l'application pour l’introduction et le traitement électronique des déclarations. Elle comprend, entre autres, la base de données des dettes dues par les contrevenants auprès de l’AGDA, en raison de la constatation d’une infraction ou d’une irrégularité, mais aussi l’enregistrement de tous les paiements liés à des opérations commerciales sujettes à des droits de douane, des taxes, des accises, etc. Afin de permettre le suivi correct et actualisé des dossiers contentieux, il est donc nécessaire d’encoder les dettes évoquées, et de suivre l’évolution des paiements qui s’y rapportent, ainsi que des modifications apportées par les agents pour diverses raisons, par exemple : modification du montant des amendes suite à une transaction ou à une décision judiciaires, etc. Actuellement, les données sont encodées manuellement par agents de l’AGDA. Il est souhaité que le système puisse se connecter automatiquement avec PLDA, afin de réaliser au moins les opérations suivantes :

création automatique d’une dette à partir des données du dossier ;

modification d’une dette dans PLDA suite à sa modification dans le système ;

aperçu des dettes d’un particulier ou d’une entreprise ;

aperçu global des paiements arrivés jour par jour pour l’ensemble des dossiers d’une Direction régionale ;

aperçu des paiements dossier par dossier pour chaque agent traitant ;

aperçu général des dettes payées et des dettes non payées par agent traitant, et mise à jour du système ;

recherche des informations structurées du DAU à partir d’un numéro de MRN et enregistrement dans le système ;

Deux modes d’accès sont à prévoir :

lors de la consultation d’un dossier donné, ou lors de la modification de données financières dans le dossier, la consultation/modification de PLDA est effectuée en temps réel, pour peu que PLDA le permette ;

le système consulte PLDA la nuit pour rechercher les nouveaux paiements liés à des dossiers ouverts, afin de pouvoir éventuellement signaler aux agents en charge l’arrivée d’un paiement ou le dépassement d’un délai de paiement – toute modification de données dans le système lors de cette mise à jour doit être notifiée à l’agent en charge du dossier.

L’adaptation de la version actuelle de PLDA afin de fournir un web service supportant l’ensemble des opérations décrites ci-dessus est de la responsabilité de l’AGDA. Les coupures de connexion de ce système ne doivent pas être bloquantes.


P. 78

III.4.3.14.7 Récapitulatif des besoins en collecte d’information auprès de systèmes externes


EN1 Interface avec PLDA P1

EN2 Interface avec SITRAN P1

EN3 Interface avec la STIPAD P3

EN4 Interface avec la Hypo P3

EN5 Interface avec KBO/BCE P3

EN6 Interface avec la DIV P2

III.4.3.15 Envoi et réception des e-mails

Le SPF finances utilise IBM Lotus Notes pour l’envoi de mails entres ses collaborateurs et avec les intervenants extérieurs au SPF. Le système sera capable d’envoyer des e-mails par ce canal. Il créera les mails et attachera les pièces jointes sans que l’utilisateur doive interagir avec Lotus Notes. Les pièces jointes seront en PDF. On envisagera de se prémunir contre les modifications frauduleuses du fichier PDF autant que possible. Le système pourra aussi récupérer des documents envoyés à l’agent par mail ; d’une part le corps du mail et d’autre part les pièces jointes. L’opération doit être la plus simple possible, par exemple par un accès du système à la boîte mail de l’agent, ou encore en permettant à l’agent de faire suivre le mail vers une boîte spécifique au système (avec, p.ex., une référence du dossier dans lequel le mail doit être intégré). L’utilisateur pourra ensuite classer le mail et ses pièces et les annoter avec des métadonnées, comme tout document importé. Enfin, le système pourra envoyer des mails de synthèse à des moments prédéfinis et configurables (p.ex. chaque jour ou semaine) dans lesquels il aura rassemblé des informations spécifiques. Par exemple : envoi quotidien aux responsables des recettes de la liste des dossiers pour lesquels une décision définitive a été prise (aux fins de compensation). Les critères de sélection font référence aux métadonnées, de même que l’information présente dans ces mails de synthèse.


EN7 Interface avec le système de mail pour l’envoi de documents (éventuellement groupés) P1

EN8 Réception de mails depuis la boîte de l’utilisateur, y compris fichiers attachés P1

EN9 Analyse du mail pour identification automatique du dossier P2

III.4.3.16 Gestion des absences

Le système récupèrera auprès du système de gestion des absences du SPF finances (myP&O) les informations sur la non-disponibilité des agents. A titre d’alternative, tant que la connexion avec myP&O ne sera pas disponible, le système permettra à un agent de renseigner ses absences prévues ou à un chef de le faire à sa place. Cela sera possible à l’agent par un lien depuis sa page d’accueil, et au chef sur une page de gestion de l’équipe qui affichera une synthèse des présences et absences prévues sur une période glissante de 30 jours.


EN11 Interface avec le système de gestion des absences du SPF Finances P3

III.4.4 Exigences non fonctionnelles

III.4.4.1 Performance

Il va de soi que la performance de SHERLOCK doit, jusqu’au niveau de l’utilisateur final, répondre aux critères d’une application moderne qui favorise l’efficience des utilisateurs. En conséquence, l’utilisation en ligne doit générer des temps de réponse dont la moyenne est inférieure à 3 secondes.


P. 79

III.4.4.2 Capacité et volumétrie

TIBODA (uniquement pendant les heures de bureau) :

Environ 220 utilisateurs ;

En moyenne : 200 utilisateurs simultanés ;

FIODA :

Entre 2500 et 3000 utilisateurs ;


En heure de pointe : 300 utilisateurs simultanés ;

TOTAL SHERLOCK :

Entre 2720 et 3220 utilisateurs ;


En heure de pointe : 500 utilisateurs simultanés ; Dossiers :

60 000 nouveaux dossiers infractionnels par an ;

20 000 nouveaux dossiers contentieux par an ;

Documents :

300 000 documents infractionnels par an (5 par dossier en moyenne) ;

500 000 documents contentieux par an (25 documents par dossier en moyenne) ;

dont : 5000 documents scannés par an ;

Connectivité :

SITRAN

o 120 000 requêtes par an pour les infractions (accès mobile plausible), en moyenne 2 par infraction ;

o 300 000 requêtes par an pour le contentieux ;

PLDA

o 80 000 requêtes par an pour les infractions (accès mobile plausible)

o 250 000 requêtes par an pour le contentieux (environ 5/jour/ agent)

DIV

o 60 000 requêtes par an pour les infractions

III.4.4.3 Disponibilité

Malgré le caractère permanent de certains services douaniers, SHERLOCK ne nécessite pas une disponibilité absolue de 24/24 heures et 7/7 jours. Il convient cependant de garantir une disponibilité maximale durant les heures ouvrables courantes (7h30 à 18 heures). Voir III.6.5.2 pour le temps d’intervention demandé en cas de problème technique et III.6.7 pour le SLA régissant la disponibilité de l’application.


P. 80

La tolérance aux pannes est faible : à partir du moment où le système devient l’outil de travail principal des agents de l’Administration du Contentieux et du Recouvrement, et le point de passage obligé de toutes les actes de constatation, alors son non-fonctionnement est bloquant. Une partie de la fiabilité du système dépend de l’infrastructure informatique du SPF Finances. Une autre partie dépend de l’architecture de la solution, qui doit être simple et robuste. Il peut être acceptable qu’un mode dégradé garantisse un fonctionnement de base du système. En revanche, l’accès aux documents doit être garanti autant que possible. Dans le cadre de la disponibilité, la solution doit être en accord avec le Disaster Recovery Plan (DRP) et le Business Continuity Plan (BCP) du SPF Finances. La solution doit notamment prévoir une procédure de sauvegarde et de restauration de tout le contenu du système.

III.4.4.4 Sécurité

Toutes les informations manipulées sont extrêmement sensibles. Leur divulgation peut avoir un impact grave sur les procédures en cours. L’accès à SHERLOCK doit donc être configurable afin que seuls les utilisateurs autorisés faisant partie des services concernés de l’AGDA puissent faire usage de l’application (voir III.4.5.1.2 – intégration à IAM / LDAP aspect contrôle d’accès). SHERLOCK permet ensuite de répartir ces utilisateurs en groupes sur la base des rôles fonctionnels ou des profils d’utilisateur, afin que les fonctionnalités autorisées pour chaque utilisateur correspondent le plus étroitement possible aux tâches et aux activités qui lui sont confiées. Les échanges de données avec des systèmes externes (via des webservices) doivent se dérouler de manière sécurisée et cryptée.

III.4.5 Aspects techniques

III.4.5.1 Respect des normes ICT existantes

Que la solution offerte soit un package/outil ou le résultat de développements spécifiques sur mesure, il convient de maximiser la conformité aux normes et fondements ICT actuels (voir § III.3.2). Vu les souhaits spécifiques exposés au paragraphe III.4.3, nous supposons qu'un certain rôle sera dévolu à divers composants architecturaux faisant partie des standards ICT. Le soumissionnaire est invité à décrire clairement comment sa solution s’intègre aux éléments d’architecture sous-jacents. En règle générale, toute dérogation aux normes et fondements ICT doit être solidement argumentée.

III.4.5.1.1 Intégration – connecteurs

Le paragraphe III.4.3 explique comment l'application SHERLOCK doit faire appel à certains services, notamment l’échange de données, offerts par d’autres applications du SPF Finances (PLDA, SITRAN…). Dans son offre, le soumissionnaire doit spécifier les services qu'il a l'intention de fournir et les tâches à réaliser dans le cadre de ces intégrations. Il est clair que SHERLOCK devra interagir à terme avec une multiplicité d'autres systèmes, dont certains restent à définir. Dans son offre, le soumissionnaire expliquera comment les collaborateurs du Service d'encadrement ICT pourront à l'avenir construire des interfaces avec des applications qui ne sont pas encore connues aujourd'hui ou des applications qui n’offrent pas encore de services d’intégration. Le soumissionnaire doit donc préciser les conditions à remplir pour qu'un système soit connectable à SHERLOCK.


P. 81

Enterprise Service Bus (ESB) À la mise en place de l’interaction entre SHERLOCK et d'autres applications via les web services, il importe de les coordonner au maximum avec les standards et outils SOA (Service oriented architecture). Concrètement, cela signifie que la solution proposée doit mettre en place les contrats de services mutuels avec l'aide du composant ESB disponible. Il importe à cet égard d'exploiter au maximum la valeur ajoutée de ESB, en fonction des impératifs de sécurité, logging, transformations de modèles de données, etc. Il est donc demandé à tous les nouveaux projets de s'inscrire dès le début dans cette démarche en réutilisant autant que possible les services existants et en contribuant à leur tour à l'enrichissement du catalogue de service. Le document décrivant l'architecture du projet présentera donc quels sont les services qui vont être réutilisés. Cette réutilisation doit être correctement planifiée et négociée, via un SLA, avec le service owner. Afin de préparer au mieux cette phase, le projet présentera une estimation de la consommation de chaque service (nombre d'appels, taille des messages, distribution estimée dans le temps, ...). Le document décrivant l'architecture du projet présentera également quels sont les nouveaux services d'accès aux données et aux processus qui seront mis à disposition par le projet. Les services fournis par le projet doivent respecter les principes SOA : contrat standardisé de services, couplage lâche des services, abstraction, réutilisabilité, autonomie, absence d'état, service pouvant être découvert et services composables Les services seront exposés via la solution ESB déployée au SPF Finances. Cette solution comprend les produits Aurea ( http://www.aurea.com ) et Progress ( http://www.progress.com ) suivants : Aurea Sonic, Aurea Actional, Aurea DataXtend SI et Progress Control Tower. Cette solution fournit les fonctionnalités standards d'un ESB (routing, transformation et enrichissement de messages, orchestration, ...), permet d'exposer des services en y ajoutant une couche de sécurité et d'audit, offre des fonctionnalités de monitoring technique et business (BAM) ainsi que de gestion d'un Common Data Model. Si les services proposés par le projet sont mis en œuvre sous la forme de webservices, ceux-ci devront suivre les recommandations OASIS sur la qualité des webservices (http://docs.oasis-open.org/wsqm/WS-Quality-Factors/v1.0/cs01/WS-Quality-Factors-v1.0-cs01.html ) et être compatibles WS-I Basic Profile 1.1 ( http://www.ws-i.org/profiles/basicprofile-1.1-2004-08-24.html ). Un soin tout particulier sera apporté au data model des services. La réutilisation de standards existants est encouragée lorsque cela est pertinent. Les définitions WSDL et XSD seront définies en anglais, les noms des classes commenceront par une majuscule et les propriétés seront en CamelCase. Ces définitions seront correctement commentées y compris du point de vue de la gestion des erreurs et des exceptions. Le modèle de données fera abstraction de l'implémentation technique sous-jacente et définira de manière adéquate les types et le caractère obligatoire ou non des éléments. Les services exposés et leur interface seront soumis à l’approbation de l’équipe ESB qui fournira du support et de l’expertise si nécessaire. La définition des messages XML et des interfaces des web services (WSDL) utilisés dans les échanges de données avec d’autres applications sera développée à la phase d'analyse (PHASE 1). Dans la mesure où les interfaces existantes suffisent, on en fera toujours un usage optimal. Si elles sont inexistantes ou incomplètes, la définition des nouvelles interfaces se fera en liaison étroite avec les collaborateurs de projet de l’application à intégrer.


P. 82

Le périmètre de ce marché couvre la réalisation des interfaces nécessaires côté SHERLOCK ainsi que la mise en place et les tests de l’intégration effective. Les nouveaux développements des interfaces avec lesquelles l’intégration sera réalisée seront à la charge de ces applications et ne font donc pas partie du présent cahier des charges.

III.4.5.1.2 IAM / LDAP

Avec le système Identity and Access Management (IAM), le SPF Finances dispose de son propre cadre de gestion des identités et des accès. L’intégration à ce système est considérée comme une nécessité absolue. L’intégration concrète avec IAM sera affinée à la phase d’analyse (PHASE 1). Contrôle d’accès Si SHERLOCK revêt la forme d’un développement spécifique sur mesure, les aspects de la gestion de l'accès tels que l'authentification et l'autorisation doivent utiliser entièrement les composants prévus à cette fin dans le système IAM. En revanche, si SHERLOCK s’appuie sur un produit prêt à l'emploi disponible dans le commerce, qui ne fait pas appel aux composants IAM, l’authentification doit être déléguée au serveur LDAP corporate. La sécurité des échanges entre LDAP et SHERLOCK étant un point critique, la compatibilité avec LDAP via SSL (LDAPS) est indispensable. Mise à disposition (provisioning) des données utilisateurs En complément, tout sera fait pour viser la mise à disposition des données utilisateur à partir de l’environnement IAM. Cela implique que les métadonnées de SHERLOCK (profils utilisateurs internes, répartition en groupes, répartition des rôles et permissions) soient dérivées automatiquement de LDAP. Piste d’audit Autre aspect intéressant de la sécurité : la protection de la vie privée. Ce besoin peut également trouver une réponse dans le système IAM. Durant les opérations d’intégration de SHERLOCK avec IAM, l’équipe vie privée du SPF Finances définira des besoins concrets en termes d’audit. Compte tenu des sensibilités spécifiques du contexte SHERLOCK, on déterminera quelles informations les auditeurs « privacy » jugent critiques. En faisant usage de l’API de logging IAM, SHERLOCK pourra enregistrer les informations demandées dans la base de données centrale de logging de IAM.

III.4.5.1.3 Lotus Notes

SHERLOCK est censé offrir un support direct en matière d'échanges (entrants et sortants) de messages électroniques (e-mails) dans le cadre du traitement des dossiers. Pour l’inventaire des exigences fonctionnelles liées à l’envoi, à la réception et à la gestion des e-mails via SHERLOCK, nous renvoyons à § III.4.3.15. Le soumissionnaire doit expliquer clairement comment il entend réaliser sur le plan technique l’intégration avec le système de messagerie du SPF Finances, Lotus Notes. Non moins importante est la description de l’indépendance de la solution par rapport au choix du système de messagerie avec lequel l’intégration sera réalisée. Cela doit garantir que le SPF Finances, en cas de futur changement de sa messagerie standard, puisse continuer à exploiter les mêmes fonctionnalités de messagerie moyennant un impact acceptable sur la configuration du système.


P. 83

En complément à l’intégration IAM, pour les besoins de laquelle on vise un lien avec LDAP pour l’authentification des utilisateurs et la mise à disposition des informations de compte, il faudra aussi transposer les adresses e-mail des collaborateurs du SPF Finances via le lien avec SHERLOCK.

III.4.5.1.4 FileNet

La gestion des documents est une fonctionnalité centrale de SHERLOCK. Avec FileNet, le SPF Finances dispose déjà d’un puissant système de gestion documentaire. En conséquence, il importe que la solution soit dans la mesure du possible compatible avec la plate-forme FileNet P8.

III.4.5.1.5 Scriptura / Adobe LiveCycle

Les outils ICT standard actuels pour la création de documents à partir de templates dynamiques sont Scriptura d’Inventive Designers (http://www.inventivedesigners.com) et Adobe LiveCycle. Scriptura est un logiciel qui fait partie de Fedopress, le système centralisé qui assure les services de composition, de conception et d’impression numérique des documents en gros volumes. Adobe LiveCycle est un logiciel SOA à base Java EE qui supporte notamment la création de documents PDF éditables à partir de templates, ainsi que la certification et la signature numérique de ces documents PDF. Le processus de génération de documents (PDF) à partir des modèles Scriptura et Adobe LiveCycle est également intégré dans le cadre CCFF. Comme expliqué sous III.4.3.1.3 et III.4.3.5, SHERLOCK doit offrir des possibilités de création et de gestion des templates, à partir desquels les documents concrets seront générés sur la base des informations du dossier et d’autres métadonnées. Si la solution offerte ne revêt pas la forme d’un package/outil prêt à l’emploi incorporant un système de gestion des templates et de génération des documents, mais que la concrétisation de ces besoins passe par un développement sur mesure, il faut également que la solution soit la plus conforme possible aux standards concernés, en l’occurrence Scriptura ou Adobe LiveCycle.

III.4.5.2 Environnements

Environnement matériel L’ensemble doit être réalisé sur des plates-formes qui seront mises à disposition par le SPF Finances, dans le respect des normes technologiques et des normes de développement définies par le SPF. Le soumissionnaire est invité, dès le stade de l'offre, à donner les indications les plus concrètes possibles quant aux composants matériels et à leur capacité. Cette description doit notamment permettre d’évaluer la solution offerte en termes d’impact sur l’infrastructure et de coûts correspondants. Développement, tests, acceptation, production et formation Au sein d’ICT, dans un processus de développement, chaque phase de la réalisation correspond à un environnement déterminé. La répartition exacte des environnements et leur rôle spécifique seront précisés en fonction de l’architecture de SHERLOCK. Le choix dépendra notamment de l’approche choisie pour le projet, de la quantité de développement spécifique, des besoins ICT, etc. Au niveau général, les environnements suivants sont susceptibles d’occuper une place dans le contexte de SHERLOCK :

Développement : un programme ou composant est d’abord développé dans l’environnement de développement. Le besoin d’un environnement de développement dépend étroitement de l’importance des développements spécifiques requis. Si la solution se compose d’un

http://www.inventivedesigners.com/


P. 84

package/outil à configurer, qui ne nécessite guère d’extensions ni de personnalisation, l’environnement de développement ne sera pas forcément nécessaire.

Test / acceptation : cet environnement est destiné aux diverses activités de test (unit tests, tests d'intégration, tests des systèmes, tests d'acceptation...). Selon le nombre d’itérations au cours desquelles plusieurs releases subissent en parallèle une phase de test distincte, on peut décider de prévoir un environnement séparé pour les tests d’acceptation.

Production : l’acceptation de l'application est suivie du déploiement dans l’environnement de production, où elle est mise à la disposition des utilisateurs finaux.

Formation : après le déploiement de l’application, les utilisateurs suivent des formations qui nécessitent un environnement conçu à cet effet.

Les différents environnements sont cloisonnés, mais du point de vue technique, ils doivent être similaires de manière à éviter les incompatibilités. Environnements fonctionnels Au niveau des utilisateurs finaux, il convient de distinguer deux types de fonctions d’utilisation. Outre l’utilisation proprement dite de l’application, à l’appui des tâches métier, nous avons aussi un groupe d'administrateurs d'application, chargés de l'entretien des métadonnées, des templates de documents, des règles d'action, etc. (voir § III.4.2). Cela suppose l’existence de deux environnements fonctionnels pour les utilisateurs finaux de D&A, chacun ayant son SLA de production. Les templates et autres règles d’action nouveaux ou modifiés sont « promus » de manière contrôlée de l’environnement « administrateur » vers l’environnement « business ». Le soumissionnaire doit expliquer clairement comment ces environnements fonctionnels se traduiront techniquement dans l’architecture de SHERLOCK.

III.4.5.3 Développements spécifiques

Toute forme de développement spécifique nécessaire pour combler les besoins formulés doit être prise en compte dans la détermination du prix total qui figure dans l’inventaire de ce cahier spécial des charges (voir III.7). Outre le coût, l’offre doit donner une description technique claire et complète du développement spécifique à prévoir. Pour éviter par la suite les problèmes de mise à jour en cas de nouvelle version, le soumissionnaire s'engage à supporter ces développements dans le cadre de la maintenance de toutes les versions à venir.

III.4.5.4 Poste client

Le SPF Finances attache une importance particulière à l'indépendance des solutions par rapport aux postes clients. Le client doit donc veiller à ce que le raccordement, l'installation des composants et l'intégration au poste client exercent un impact minimum. À cette fin, il proposera de préférence une solution à base Internet (web). Le soumissionnaire doit également garantir cette indépendance en termes de logiciels, dans le cadre des standards ICT. A titre d'exemple, les installations éventuelles doivent avoir lieu dans le cadre du projet SMS (System Management System, pour la gestion de l'installation des logiciels à distance). Les services correspondants doivent être assurés via le présent marché, sans frais supplémentaires.


P. 85

III.4.5.5 Plan de déploiement

Dans son offre, le soumissionnaire présentera un plan de déploiement de haut niveau. Cela concerne à la fois le déploiement technique et le déploiement business. Dans toute l’exécution du marché, l'élaboration et l'entretien du plan de déploiement incombent à l'adjudicataire. Le plan de déploiement doit contenir les informations suivantes :

planning de toutes les activités de déploiement

concernant le déploiement technique :

o les composants à installer

o les intégrations à mettre en place

o l’estimation des profils nécessaires

o les besoins en termes d’infrastructure et de matériel (voir III.4.5.2)

o l’impact sur les ressources ICT et la part escomptée de celles-ci

concernant le déploiement business :

o planification des formations (voir III.6.1)

o coordination du déploiement technique

les résultats finaux (livrables)

les risques

choix de la structure de suivi :

o comment le rapportage des progrès et des problèmes du déploiement est-il organisé ?

o comment cette structure interagit-elle avec l’équipe de projet et le suivi général du projet (voir III.3.3) ?

les autres informations éventuelles que le soumissionnaire juge nécessaires.

Le déploiement technique ne peut naturellement exercer aucune influence sur l’intégrité et le bon fonctionnement des autres systèmes et applications ICT. Dans son plan de déploiement, le soumissionnaire doit prévoir les garanties nécessaires pour préserver la stabilité générale durant le déploiement technique.

III.4.5.6 Tests / plan de test

Le soumissionnaire explique l'approche qu'il entend utiliser pour tester le système. Il présentera son plan de test au SPF Finances. Le soumissionnaire propose et documente un système de test (chargé de vérifier le bon fonctionnement du système et le traitement correct des données). Les tests d'efficacité de l'utilisation de l'application seront effectués dans des groupes d'utilisateurs spécifiques pour chaque module. Le soumissionnaire se charge aussi de cet aspect et le documente.


P. 86

III.5 Encadrement du marché

III.5.1 Phasage

III.5.1.1 Itérations

La réalisation de SHERLOCK sera organisée en blocs fonctionnels ou itérations. La teneur précise des itérations pourra être adaptée compte tenu des éventuelles spécificités techniques de la solution choisie et d'autres conditions secondaires. Chaque itération successive s’appuie sur la précédente. En fin de parcours, cela donne naissance à SHERLOCK en tant que solution à part entière pour le présent marché. Cette méthode itérative permet à l’administration des D&A de faire valider graduellement par les groupes d’utilisateurs pilotes les fonctionnalités livrées. Itération « R0 » La première itération vise la réalisation d’une version de base de l’application SHERLOCK à l'intention du groupe de projet. L’objectif de l’itération R0 est double:

1. permettre de valider fonctionnellement les principes de la solution par l’équipe projet;

2. pouvoir commencer à encoder les maquettes (qui sont nécessaires pour le lot R1).

Il est donc requis que R0 contienne :

1. une version simplifiée des interfaces (Fioda, TIBODA et gestion);

2. l’interface simplifiée de Fioda permettra d’enregistrer un dossier, de le valider et de le faire suivre vers le contentieux, ce qui inclut la gestion manuelle des dossiers, l’enregistrement de métadonnées, de documents externes et la création de documents à partir de maquettes;

3. l’interface TIBODA doit permettre de gérer manuellement un dossier : enregistrement des métadonnées, enregistrement de documents externes, création de documents à partir de maquettes;

4. la partie gestion doit permettre de réaliser des maquettes: définition de la mise en page, positionnement de métadonnées.

Avec cette version, l’équipe projet pourra, en interne, créer des maquettes et simuler des processus complets. Les maquettes créées pourront être utilisées dans les phases suivantes sans modification. Itération “R1” L’objectif de l’itération R1 est de faire valider fonctionnellement la solution par un groupe d’utilisateurs pilotes. Ils devront donc disposer d’un système cohérent, même s’il est encore limité dans ces fonctionnalités. Il est donc requis que R1 contienne :

1. une version utilisable par les utilisateurs finaux des interfaces;

2. une connexion avec les systèmes PLDA, SITRAN et Lotus Notes;

3. la gestion des délais et des notifications (éventuellement limité en fonctionnalité);

4. le processus de verrouillage des documents;

5. le processus d’impression.

Le système présenté en R1 doit absolument démontrer une valeur ajoutée aux utilisateurs. Dans le cas contraire le projet pourra être interrompu.


P. 87

Itération “R2” – 1e release L’itération R2 sera mise à disposition de l’ensemble des utilisateurs. Elle contiendra essentiellement les fonctionnalités de R1, mais corrigées en fonction du retour des expériences pilotes. Il est donc nécessaire que R2 contienne :

1. l’attribution des actions à des agents (pas nécessairement automatisée);

2. le Webservice Fioda;

3. l’exportation des données vers le SCGI;

4. le multilinguisme.

Les fonctionnalités de priorité P2 seront progressivement intégrées, dans un ordre à déterminer.

III.5.1.2 Méthodologie FUP

Le SPF Finances a instauré une méthodologie pour le développement des applications. Celle-ci a avant tout pour but de formaliser et de stabiliser le déroulement des projets ICT dans un cadre commun, en uniformisant le contenu des phases d’un projet, les rôles des différents acteurs, et les artéfacts livrés à chaque phase. Le SPF Finances souhaite faire usage de standards ouverts et reconnus. À cet effet, il a choisi la méthodologie de base UP (Unified Process ou « processus unifié »), adaptée en fonction des besoins et enrichie de certains concepts issus de RUP (Rational Unified Process).

III.5.1.3 Phases

Sur la base de la méthodologie FUP, nous distinguons les phases suivantes :

PHASE 1 – Élaboration

A. consolidation et validation du périmètre total du projet, en partant de la description du marché dans le cahier des charges, débouchant sur une formulation à haut niveau de toutes les exigences fonctionnelles et non fonctionnelles à réaliser

B. analyse fonctionnelle : les exigences du périmètre de cette itération sont traduites en use cases détaillés

C. conception de la solution (notamment interface utilisateur, modèle de données conceptuel et physique) et finalisation de l’architecture du système et du logiciel

D. si la complexité de la solution l’exige, suivent le développement, les tests et la validation du prototype.

PHASE 2 – Construction

A. finalisation de la conception : il ne s’agit pas ici de changements structurels mais de compléter le cas échéant les détails nécessaires pour alimenter la réalisation concrète de la solution

B. implémentation de SHERLOCK : en fonction du choix du soumissionnaire, il s’agit ici d’une application entièrement nouvelle ou de l’installation d’un package/outil avec le paramétrage et la personnalisation nécessaires à son bon fonctionnement

C. exécution des tests pour vérifier que l’implémentation est conforme à l’analyse, à la conception et à l’architecture issues des phases précédentes, suivant les procédures et la stratégie décrites dans le plan de test (voir § III.4.5.6)

D. création du matériel de formation et des manuels qui serviront à la formation des premiers utilisateurs pilotes

E. élaboration d’une première version du plan de déploiement et mise en service de SHERLOCK


P. 88

PHASE 3 – Transition

A. finalisation des implémentations : les dernières corrections et demandes de changement sont intégrées en une version prête pour l’acceptation

B. tests d’acceptation : le SPF Finances valide la solution et vérifie qu’elle est conforme aux exigences

C. déploiement de SHERLOCK dans l’environnement de production : l’application est testée par un groupe limité d'utilisateurs pilotes

D. finalisation du plan de mise en service

E. formation des utilisateurs finaux (voir § III.6.1)

F. transfert de connaissances entre l’équipe de projet chargée de la réalisation de SHERLOCK et les collaborateurs du SPF Finances chargés des aspects entretien et exploitation

G. mise en service effective de SHERLOCK par tous les utilisateurs finaux

À chaque itération (voir III.5.1.1), toutes les étapes de la PHASE 1 « Élaboration » et de la PHASE 2 « Construction » sont entièrement accomplies, de même que les étapes A et B de la phase 3 « Transition ». À la dernière itération, on passe aussi par les autres étapes de la PHASE 3 « Transition », jusqu’à la remise finale SHERLOCK aux utilisateurs finaux.

III.5.1.4 Délais

Dans le cadre de la réalisation du marché, le pouvoir adjudicateur souhaite disposer dans un délai raisonnable de résultats exploitables concrètement. Plus précisément, il est demandé que la réalisation de la solution tienne compte des délais suivants :

l’itération « R0 » doit être achevée dans les 9 mois suivant la notification de l’attribution ;

l’itération « R1 » doit être achevée dans les 5 mois suivant la notification d’une décision « Go » ;

l’itération « R2 » doit être achevée dans les 5 mois suivant la notification d’une décision « Go » ;

le calendrier des phases de chaque itération doit être compatible avec la complexité et le volume des packages de travail correspondants ;

la mise en œuvre de la PHASE 1 « Élaboration » ne peut occuper plus de 40% de la durée totale de chaque itération.

Le soumissionnaire donnera déjà dans son offre un planning indicatif exposant de manière argumentée les phases, les itérations et les délais. Un changement dans la répartition des phases (voir plus haut) ou une adaptation des délais ne sont possibles que moyennant concertation et approbation par le groupe de projet du SPF Finances.

III.5.2 Décision Go / No Go

Avant le lancement des itérations « R1 » et « R2 », le SPF Finances examine s'il est opportun de poursuivre le projet. Autrement dit, après cette phase, l'on insère une décision explicite « Go / No go ». Une décision « No Go », qui met fin de facto au projet, n'entraîne aucune forme d'indemnisation. Les réceptions qui résultent de chaque phase font partie d’une validation formelle. Cela signifie que dans une même itération, la PHASE 2 « Construction » ne peut commencer qu’après approbation des livrables issus de la PHASE 1 « Élaboration ».


P. 89

III.5.3 Aspects personnels

Pour le chef de projet et tous les collaborateurs techniques ou enseignants, le soumissionnaire est invité à joindre un CV nominatif conforme au modèle de l'annexe « Addenda au cahier des charges : curriculum vitae ». Il spécifiera aussi la fonction et les responsabilités de chaque personne dont il soumet le CV. L’offre comprendra un aperçu schématique de l’équipe mise en place. Le soumissionnaire doit, au moyen d’un CV annexé, démontrer que le personnel affecté dispose de l’expérience et des compétences (techniques) nécessaires pour mener à bien la réalisation de la mission. Sauf cas de force majeure, l'adjudicataire s’engage à ce que les personnes dont le CV est présenté soient effectivement disponibles pour participer au projet. Tout changement au sein de l’équipe de projet (l’ajout, le retrait ou le remplacement) doit être soumis à l’approbation du comité de pilotage.

III.5.4 Licences à livrer

Si la solution proposée par le soumissionnaire nécessite des licences logicielles spécifiques, par exemple si SHERLOCK s’appuie sur un package/outil prêt à l’emploi, le prix (maintenance comprise) de toutes les licences nécessaires que le SPF Finances doit acquérir doit figurer dans l’inventaire (voir III.7). Si le soumissionnaire choisit une solution ouverte (open source) pour un des composants, l'offre doit mentionner les garanties correspondantes et les conditions d’entretien. Au niveau général, le soumissionnaire doit prévoir le support et les licences de tous les composants logiciels qui font partie de la solution proposée, y compris les composants de tiers, dans la mesure où les composants concernés ne font pas partie des standards et fondements ICT du SPF. A titre d'exemple, si la solution fait appel à un système de base de données pour la persistance des données opérationnelles et métadonnées, on se reposera de préférence sur DB2, le standard ICT en matière de technologie de base de données. Si cette condition n’est pas réalisable parce que le package/outil ne supporte pas DB2 en standard, il est indispensable que le soumissionnaire mentionne explicitement les coûts supplémentaires des licences nécessaires ainsi que du support spécifique requis par le DBMS alternatif de la solution proposée.

III.5.5 Documentation à fournir

Dans son offre, le soumissionnaire précise la documentation qu'il offre et la décrit en détail. Le soumissionnaire est aussi invité à expliquer sa méthode de tenue à jour de la documentation. Pour les besoins de l’intégration de la documentation dans le système documentaire du service d’encadrement ICT, la documentation sera obligatoirement fournie en version électronique, au format Word 2010 ou pdf, permettant les recherches « full text ». Le SPF Finances peut copier la documentation pour les besoins de sa diffusion interne, sans limitation. Documentation technique L’adjudicataire doit remettre au SPF Finances toute la documentation technique en français, en néerlandais ou en anglais. La langue sera choisie en concertation avec l'équipe de projet ou en fonction de la langue dans laquelle la documentation est disponible. La documentation technique doit plus précisément expliquer comment le système est construit, exposer les propriétés et les règles d’utilisation du matériel et des logiciels faisant partie du projet, et décrire en détail l’ensemble du système, en expliquant les différents sous-systèmes et leurs liaisons mutuelles. Outre la prise en compte des méthodologies standard (voir § III.3.2), l’adjudicataire est naturellement tenu de réaliser tous les livrables et la documentation.


P. 90

Documentation utilisateur Les manuels destinés aux utilisateurs doivent comporter un chapitre sur le démarrage rapide (« getting started quickly ») pour permettre à ces personnes de se mettre au travail sans délai ; on doit aussi y trouver une partie consacrée à l’utilisation avancée (« advanced »). Les manuels doivent être disponibles en ligne et téléchargeables (au format pdf). L’aide en ligne et les manuels pour utilisateurs doivent être disponibles en français et en néerlandais. Pour appuyer les utilisateurs, l'adjudicataire doit prévoir un support méthodologique. Il doit composer un ensemble de guides pour veiller à la cohérence des actions (par exemple : guide d’architecture, guide des métadonnées, guide des liens et des langues, guide terminologique, guide d’édition et de style, guide de workflow, guide des aspects collaboratifs…).

III.5.6 Gestion de la qualité et des risques

Le soumissionnaire explique comment il envisage la gestion de la qualité et des risques. On trouvera ci-dessous des exemples de risques sur lesquels le soumissionnaire peut se baser. L’offre doit cependant comporter un exposé plus complet et cohérent de l’approche retenue. Le soumissionnaire peut compléter la liste ci-dessous en ajoutant les risques qu’il juge pertinents.

L’interface : est-elle perçue comme conviviale par l’utilisateur ?

L’utilisateur considère-t-il les différents écrans comme pertinents par rapport à son rôle et à sa tâche ?

Dépendance des parties d'application

Qualité des analyses

Changements au cadre législatif

Évolution des autres projets en cours avec lesquels il existe des dépendances

Changement organisationnel

III.6 Services à prester

III.6.1 Transfert de connaissance

III.6.1.1 Formation

Chacune des formations requises doit être proposée en français et en néerlandais. La formation sera organisée à 4 niveaux :

1. Utilisateurs finaux : Application du principe « formation du formateur ». Le soumissionnaire donnera la description et le prix d’une session de formation en français et en néerlandais (maximum 8 participants par session).

2. Power user / application administrators : Ce groupe de collaborateurs business assure

notamment la tenue à jour des métadonnées, des templates de documents et des règles d’action. Un ensemble de formations ciblées, de matériel didactique et de documentation système doit permettre à un public sans bagage informatique d’assumer en autonomie les tâches spécialisées (maximum 8 participants par session).

3. Administrateur de système ICT : Au vu de la complexité technique de la solution, une

formation est organisée (avec sa documentation) à l'intention des collaborateurs ICT chargés du support technique et opérationnel de SHERLOCK (maximum 4 participants par session).


P. 91

4. Service Desk (remarque : le service desk opère suivant les principes ITIL) : le

soumissionnaire propose une brève formation, deux fois en français et deux fois en néerlandais, pour des groupes de 10 personnes maximum. La formation est organisée de telle façon que les membres du service desk acquièrent une connaissance suffisante de l'application pour remplir leur fonction, ainsi que le bagage nécessaire pour transférer cette connaissance à leurs collaborateurs (« train the trainer »).

Pour les rôles « utilisateur final » et « power user / application administrator », le programme de formation est élaboré en liaison avec les collaborateurs de projet de D&A. Pour les formations ci-dessus, le soumissionnaire décrit les objectifs, le contenu et la forme. La documentation doit être adaptée aux nouveaux développements. Exigences générales Les modalités ci-dessous restent intégralement applicables. À défaut, l'offre du soumissionnaire peut être considérée comme irrégulière. Les personnes chargées de la formation doivent :

posséder l'expérience nécessaire dans le domaine qu'elles enseignent

faire preuve d'une maîtrise PARFAITE de la langue dans laquelle le cours est donné

posséder les qualités pédagogiques indispensables pour transmettre la matière de façon structurée et systématique aux participants

savoir exploiter efficacement les moyens pédagogiques et s'en servir aux bons moments

tenir compte des remarques du pouvoir adjudicateur en ce qui concerne le contenu et la présentation de la formation

Le cas échéant, l'offre peut se contenter de faire référence au CV de la ou des personnes concernées. Le pouvoir adjudicateur se réserve le droit d'exiger par téléphone, télécopie ou courriel suivis d'une confirmation par lettre recommandée, le remplacement immédiat d'un ou plusieurs formateurs qui ne répondraient pas aux qualifications requises, par des formateurs possédant des qualifications équivalentes à celles qui sont mentionnées dans l'offre. En principe, les formations sont dispensées dans les locaux proposés par le SPF Finances, situés dans l’agglomération bruxelloise. Le soumissionnaire annonce clairement les moyens et impératifs techniques propres aux différentes formations (p.ex. nombre de PC). Chaque participant recevra des notes de cours, rédigées de préférence dans sa langue. Il ne peut être dérogé à cette règle sans en avoir averti le SPF Finances au préalable et avoir obtenu son autorisation. L'adjudicataire prendra les présences des participants par demi-jour.

III.6.2 Collaboration et coaching

Le SPF Finances souhaite une étroite collaboration entre son personnel et celui du soumissionnaire, dans la perspective des objectifs du projet. Outre les exigences de formation (voir § III.6.1), le contrat prévoit un coaching afin que le personnel du SPF Finances puisse acquérir assez de connaissances et de compétences pour prêter son concours au projet et entretenir le système, y compris les futurs développements de l’application. Le soumissionnaire doit décrire l'approche qu'il entend adopter pour veiller au transfert de connaissances durant toutes les phases du projet. Il doit aussi expliquer comment la collaboration entre son personnel et celui du SPF Finances sera planifiée.


P. 92

Dans son offre, le soumissionnaire doit indiquer les compétences que ces personnes doivent posséder pour pouvoir se charger du projet en fin de parcours. Il est évident que ce coaching aura pour cadre les locaux du SPF Finances.

III.6.3 Assistance complémentaire

Le soumissionnaire doit faire une proposition de prix pour une assistance complémentaire que le SPF Finances pourra demander pendant toute la durée du contrat. Selon les besoins, le SPF Finances peut faire appel à l'assistance complémentaire par jour ou par demi-jour. L'assistance sera facturée suivant la consommation. Cette assistance couvrira les extensions qui seront réalisées à la demande du SPF Finances. Les jours/homme couvriront en principe tout ce qui est jugé nécessaire dans le cadre des extensions demandées. Les mises en œuvre réceptionnées sous le régime de l'assistance complémentaire seront comprises dans la garantie pour la durée du contrat, ainsi que dans la maintenance ultérieure éventuelle, sans frais supplémentaires. L’option d’assistance complémentaire représente au maximum 50 jours par an.

III.6.4 Transférabilité

L’adjudicataire remettra au SPF Finances toutes les informations nécessaires pour transférer le contrat afin que le SPF puisse effectuer toutes les opérations nécessaires au bon fonctionnement ou à l'évolution de la solution ou pour en confier l'exécution à un tiers si l'adjudicataire ou un de ses sous-traitants reste en défaut (cessation de ses activités ou rupture du contrat). À la fin du contrat, que ce soit par expiration ou rupture, l'adjudicataire prêtera de bonne foi son concours au SPF Finances afin que celui-ci ou un tiers puisse poursuivre sans difficulté les prestations exécutées dans le cadre du contrat. À partir du début de la période de transférabilité, l'adjudicataire s'engage à restituer au SPF Finances tous les éléments nécessaires à la production de l'informatique et tous les documents appartenant au SPF. Les méthodes et procédures instaurées durant les prestations sont la propriété du SPF Finances. Aussi, en cas de résiliation ou de non-renouvellement, l'adjudicataire proposera au SPF Finances un plan de transition spécifiant en détail les dispositions et conditions relatives aux tâches à accomplir pour fournir l'information nécessaire à la bonne transition, avec un calendrier de ces tâches. L'adjudicataire s'engage à faire établir ce plan de transition par des personnes faisant partie de l'équipe chargée du contrat, sans supplément de frais pour le SPF Finances.

Toutes les opérations en relation avec la transférabilité incombent à l'adjudicataire. Il s'agit notamment

de :

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

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

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

le transfert des données

Le soumissionnaire explique au minimum comment il compte aborder les éléments ci-dessus, en ajoutant les informations supplémentaires qu'il juge utiles


P. 93

III.6.5 Maintenance

Le soumissionnaire doit expliquer comment il entend organiser la maintenance des produits livrés. La maintenance ne commence qu’après la réception provisoire globale. Elle est gratuite pendant la période de garantie pour ce qui concerne la maintenance préventive, corrective et évolutive. La réponse doit être cohérente avec les exigences ci-dessous.

III.6.5.1 Maintenance préventive

La maintenance préventive couvre les interventions techniques de paramétrage, d'optimisation, de mise au point fine et de conception du système livré. Ces interventions sont effectuées de façon à perturber le moins possible la production, autrement dit de préférence dans les périodes calmes. L'adjudicataire avertira l'Administration au moins quatre jours ouvrables avant une intervention programmée. Celle-ci ne pourra avoir lieu qu'avec l'autorisation explicite de l’Administration.

III.6.5.2 Maintenance corrective / problèmes techniques

L'adjudicataire assurera au minimum l'assistance technique nécessaire à la résolution des problèmes techniques du système livré. L'assistance technique est assurée pendant les heures d'ouverture des services du SPF (de 7h30 à 18h). Les demandes doivent pouvoir être suivies par les collaborateurs du SPF Finances. Le suivi des interventions doit être possible chaque jour de la semaine, 24 heures sur 24. L'application sera hébergée auprès du fournisseur, qui en assumera aussi la gestion. L'application permettra de mesurer la capacité de réaction et la qualité des interventions dans le cadre du SLA. Délai d'intervention L'adjudicataire doit réagir à chaque demande d'intervention dans un délai de 2 heures (avec un début de solution). Dans un délai de 8 heures, une solution doit être en place pour permettre la reprise des activités de production. Ce délai est également valable pour les parties du système qui ne sont pas directement livrées par l'adjudicataire. Le rythme normal du travail doit donc être rétabli dans les 8 heures suivant la notification d'un problème de priorité 1 et 2. Ce délai peut être allongé ou raccourci, par exemple pour les problèmes de priorité 3 et 4, en fonction de la nature du problème. Pour la définition des priorités, nous renvoyons à § III.6.7. Si l'on prévoit que les mesures curatives vont prendre trop de temps, l’adjudicataire doit, dans la mesure du possible, proposer un palliatif permettant de contourner le problème ou le défaut.

III.6.5.3 Maintenance évolutive

La maintenance évolutive comprend les nouvelles versions logicielles, qui corrigent les bogues constatés dans les produits. Il s'agit en principe de releases moins importants, qui mettent les logiciels en conformité avec les autres modules déjà livrés ou qui prennent en compte l’évolution des standards du marché. L'adjudicataire avertira l'Administration au moins quatre jours ouvrables avant une intervention programmée. Celle-ci ne pourra avoir lieu qu'avec l'autorisation explicite de l’Administration. Logiciels sous licence L'adjudicataire met à la disposition du SPF Finances et installe les nouveaux releases, upgrades et mises à jour des logiciels.


P. 94

La maintenance évolutive des licences couvre tous les upgrades, y compris ceux qualifiés de 'majeurs' par l'adjudicataire. Tous les logiciels sont concernés (logiciels de base et extensions). Le SPF Finances décidera seul s'il veut installer un upgrade, partiellement ou totalement. En cas de changement dans le packaging (regroupement de logiciels formant un tout), le nouveau packaging ne sera pas imposé au SPF Finances si cela a pour effet de supprimer des fonctions déjà disponibles. Le fait que le nouveau packaging comporte des fonctionnalités supplémentaires qui n'intéressent pas le SPF Finances ne pourra justifier une augmentation de prix.

III.6.5.4 Maintenance adaptative

La maintenance adaptative concerne les modifications aux logiciels et aux applications résultant des changements et upgrades apportés aux environnements, aux applications clients et aux standards de l'Administration, à quoi il faut ajouter de nouvelles fonctionnalités. La maintenance adaptative est expressément demandée par le SPF Finances. Elle est couverte par le poste « Assistance complémentaire » du cahier des charges.

III.6.5.5 Programme de maintenance

L'adjudicataire exposera les grandes lignes du programme de maintenance qu'il recommande pour les systèmes de production, programme à appliquer par le personnel du SPF Finances afin que les produits proposés par le soumissionnaire soient convenablement supportés. Cela concerne toutes les opérations d'entretien du système : quotidiennes, hebdomadaires, mensuelles ou autres.

III.6.6 Intégration au service desk

Le service demandé ci-dessous doit être assuré les jours ouvrables de 7h30 à 18h. 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. L’adjudicataire 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 le soumissionnaire 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.


P. 95

La transmission des appels entre le service desk du SPF Finances et le helpdesk de deuxième ligne que l'adjudicataire doit mettre en place passera au moins par les canaux suivants :

Téléphone et e-mail à la disposition des opérateurs du service desk du SPF Finances.

Automatiquement ou semi-automatiquement, en reliant l'outil du SPF Finances (HP Service Manager) à l'outil utilisé par l’adjudicataire pour la gestion et le suivi des appels. Le soumissionnaire expliquera dans son offre les canaux qu'il supporte. Il précisera en particulier

o Les moyens dont l'Administration disposera pour contrôler à tout moment l'état des appels ouverts.

o Les moyens dont l'Administration disposera pour contrôler le respect du SLA.

o La façon dont il propose éventuellement de synchroniser les deux outils (SPF Finances et soumissionnaire)

o Les rapports qu'il mettra à la disposition du SPF Finances pour le suivi de la qualité du service

o La méthode éventuelle pour résoudre à distance certains problèmes de fonctionnement

Le soumissionnaire doit aussi prévoir un retour d'information vers le service desk à propos des appels qui lui ont été transmis ; autrement dit, il doit informer le service desk de la suite qu'il leur a réservée, via un canal préalablement annoncé, canal qui permet le suivi des appels. Le soumissionnaire expliquera le service en tenant compte de tous les points évoqués ici. Il fournira aussi les autres services qu'il juge nécessaires. Tout changement au système entraîne la livraison d'un ensemble de code source et de documentation à inclure dans le système de gestion des versions du SPF Finances. Les changements ne sont effectués qu'après l'accord du SPF Finances. L'adjudicataire transmettra toutes les informations nécessaires à la CMDB (configuration management database), en suivant les procédures imposées par le SPF Finances. Ces procédures seront communiquées après attribution du marché. Elles pourront changer pendant la durée du contrat. Le SPF Finances attire l'attention des soumissionnaires sur la grande importance attachée à la surveillance de l'intégrité de la CMDB. Dans leur offre, les soumissionnaires préciseront clairement les mesures qu'ils proposent à cet effet.

III.6.7 Service Level Agreements (SLA)

À partir de la date où la réception provisoire globale est prononcée jusqu'à l'expiration de la période de maintenance et d'assistance, l'adjudicataire s'engage à maintenir les niveaux de services convenus dans les SLA pour la solution. L'Administration ne transigera pas sur les exigences en matière de service.

Niveaux de SLA Les SLA doivent se situer à plusieurs niveaux. Le SPF Finances souhaite définir quatre niveaux de SLA :

SLA portant sur la mise en production de la solution ;

SLA portant sur la période de garantie et la période de maintenance ;

SLA portant sur la disponibilité et les performances de la solution ;

SLA portant sur les services assurés par le personnel mis à disposition.


P. 96

SLA de mise en production Préalablement à la mise en production effective de SHERLOCK, le SPF Finances validera la solution en la confrontant aux objectifs définis et consolidés au début du projet durant les phases d'analyse. L'adjudicataire doit proposer une méthode de validation qui garantit la cohérence par rapport aux objectifs fixés, en termes de fonctionnalités disponibles, de performances à fournir, de données à traiter, etc., sans oublier les résultats à atteindre lors des phases de déploiement. Des mesures correctives seront proposées pour les cas de différence entre les objectifs et les résultats, avec application du SLA que le soumissionnaire doit proposer pour ce genre de situation. Il importe par ailleurs que le SLA spécifie le traitement à réserver aux délais : le SPF Finances se soucie beaucoup des dépassements de délai pour la réception provisoire des différentes itérations et pour la réception provisoire globale de SHERLOCK.

SLA de période de garantie et de maintenance À partir de la réception provisoire globale et jusqu'à la fin du marché, le soumissionnaire veille au respect du niveau de service défini dans les SLA.

Ce SLA porte notamment sur :

la fiabilité, ou le temps moyen entre pannes ;

la disponibilité du personnel du soumissionnaire ;

la sécurité et l’intégrité des données ;

la maintenance et l'assistance : le délai d'intervention maximum en cas de panne, garantie de disponibilité de l'application ;

le délai maximum de réparation et/ou de résolution des défauts. Le soumissionnaire est libre de compléter cette liste à sa guise.

SLA de services Dans son offre, le soumissionnaire est invité à exposer les mesures qu'il prendra pour garantir la qualité et le niveau de service, ainsi que la qualité du développement, du suivi et de l'accompagnement du projet, du suivi et du respect des plannings, des livrables, etc.

SLA portant sur la disponibilité et les performances de l’application Ce SLA porte notamment sur :

les performances de l'application (disponibilité du système, temps de réponse pour des fonctionnalités déterminées comme les recherches transactionnelles, la consultation ou la mise à jour);

La garantie que l'indisponibilité totale du système ne dépassera pas les critères suivants :

o 44 heures par an (99,50% de disponibilité) pour les systèmes critiques ;

o 88 heures par an (99,00% de disponibilité) pour les autres systèmes.

Périodes de validité des différents SLA

Mise en production : durant la PHASE 3 « Transition » des itérations successives (voir § III.5.1.1), la mise en production effective (donc la réception provisoire globale) de SHERLOCK n’intervient qu’après la réception provisoire de la dernière itération « R2 » ;

Garantie et maintenance : à partir de la réception provisoire globale jusqu’à la fin du marché ;

Disponibilité et niveau de performance : à partir de la réception provisoire globale jusqu’à la fin du marché ;

Services : à partir du coup d’envoi et pendant toute la durée résiduelle du marché.


P. 97

Sanctions Le non-respect d'un élément de SLA est sanctionné d'une pénalité. Il n'entre pas dans les intentions du SPF de réduire ses coûts par le biais des pénalités, mais seulement d'inciter l'adjudicataire à respecter tous ses engagements afin que les utilisateurs ne soient pas lésés. Les pénalités de non-respect d'un élément de SLA doivent être proposées par le soumissionnaire, en pourcentage du prix total de la maintenance et de l'intervention, visé dans le tableau des prix (voir III.7) et proposé pour l’exécution des différents modules. Ce montant servant de base au calcul reste de mise pendant toute la durée du contrat.

Niveaux de priorité des SLA Le SPF Finances a identifié cinq niveaux de priorité :

Priorité 1 (incident considéré comme facteur de blocage) : une partie du système ne fonctionne pas et occasionne une stagnation importante de l'ensemble. L'incident doit être traité immédiatement.

Priorité 2 (incident considéré comme gênant) : l'incident provoque un ralentissement chez les utilisateurs et doit être traité après résolution d'un incident de la catégorie 1.

Priorité 3 (incident considéré comme gênant) : l'incident n'a pas d'effet significatif sur la production et les utilisateurs, mais ne répond pas aux fonctionnalités convenues ; l'incident doit être traité après la résolution des incidents de la catégorie 2 ;

Priorité 4 (incident considéré comme cosmétique ; incidents supposés qui ne font pas partie des catégories 1 à 3, mais qui concernent une demande de modification d'une fonctionnalité existante.

Priorité 5 (incident considéré comme non gênant) : l'incident est sans conséquences sur la production.

Pour les priorités 1 et 2, l'adjudicataire doit apporter un début de solution dans les 4 heures. L'utilisateur doit pouvoir recommencer à travailler sur le système dans un délai qui ne dépasse pas ces 4 heures. Un rythme de travail entièrement normal doit être retrouvé dans les 24 heures au maximum. Pour les incidents de priorité 3 : un début de solution doit être apporté dans les 72 heures. Pour les incidents de priorité 4, l'adjudicataire doit apporter un début de solution dans les 5 jours ouvrables. Le soumissionnaire peut aussi proposer un SLA pour les autres aspects qu'il juge pertinents. Dans son offre, le soumissionnaire déterminera le niveau de service à atteindre pour chacun des points ci-dessus, ainsi que les outils et périodes de mesure. Éléments des SLA à aborder Pour chacun des SLA :

Objectifs du SLA

Scope

Date de début et conditions de modification

Rôles et responsabilités

o SPF Finances

o Adjudicataire

Services offerts

Procédure de traitement des réclamations

o du SPF Finances, adressées à l'adjudicataire


P. 98

o de l’adjudicataire, adressées au SPF Finances

Rapportage

Concertation

Informations de contact

Normes et pénalités du SLA (y compris mesures, définition des normes)

En outre, pour « garantie et maintenance » et « disponibilité et performance », le SLA doit être

subdivisé en :

Processus et procédures

Gestion des incidents

Gestion des problèmes

Gestion des changements

Gestion des configurations

Remarques Les SLA sont obligatoirement mesurés par périodes de 3 mois (dans la limite des possibilités). Si la période dure moins de 3 mois à la fin des 5 premières années du projet, il y a 2 possibilités : La période dure un mois ou moins: la période précédente est prolongée de cette durée, et traitée comme si elle avait duré 3 mois. La période dure plus d'un mois : une nouvelle période de mesure est ouverte, de la durée en question, et traitée comme si elle durait trois mois. Si un SLA n’est pas respecté deux fois sur une période glissante de 12 mois, la pénalité de ce SLA est doublée. Dès le moment où un SLA est respecté, la pénalité est à nouveau appliquée sans doublement la prochaine fois que le SLA n’est pas respecté. Le SPF Finances peut, s'il le souhaite, faire contrôler et exécuter les mesures du SLA, à ses frais, par un bureau d'étude indépendant.

III.7 Informations concernant l’inventaire La détermination des prix à l’aide des tableaux de l’inventaire (voir annexe E - Inventaire) doit tenir compte des éléments de prix suivants : Partie A – Services et prestations

1. Réalisation

Le soumissionnaire doit préciser un prix total pour l’ensemble des services et prestations qui sont nécesaires pour la réalisation des objectifs et fonctionnalités respectifs ( voir III.4.3). Il est demandé d’opérer une distinction entre les réalisations des exigences de niveau prioritaire P1 (NON-OPTIONNEL) de celles es exigences de niveau prioritaire P2 (OPTIONNEL). Toutes les exigences P1 mentionnées dans ce cahier spécial des charges sont l’objet de la partie fixe du marché et devront être réalisées selon les itérations proposées R0, R1 et R2. En outre, les coûts de réalisation par exigence de type P2 doivent être énumérés, chacun d’entre eux restant une option. Dans la détermination de ses prix, le soumissionnaire doit tenir compte d'une approche conforme au phasage de la méthodologie FUP, y compris la réception de toute la documentation technique correspondante. Pour une description plus détaillée des phases et itérations, nous renvoyons à § III.5.


P. 99

Cela comprend notamment l’élaboration de l'analyse fonctionnelle et de l’architecture, toutes les étapes de la phase de construction et de vérification de SHERLOCK, toutes les étapes de la phase de transition qui concernent l’exécution des corrections issues des tests d’acceptation, l’organisation de la transmission des connaissances ainsi que l’assistance au déploiement et à la mise en production de SHERLOCK.

2. Documentation utilisateur

Le prix total de la documentation utilisateur comme spécifiée sous III.5.5. L’offre doit s’accompagner d’une liste de prix détaillée pour la documentation utilisateur, que l’on pourra au besoin acquérir par parties (en supplément). Par analogie avec le prix total pour la réalisation, une distinction dans la documentation utilisateur doit être faite entre d’une part, les exigences P1 par itération (NON-OPTIONNEL) et, d’autre part les exigences P2 (OPTIONS).

3. Formations

Le coût total des formations suivant les dispositions visées sous III.6.1. Pour chaque profil à former, le soumissionnaire fixe le prix unitaire par session de formation en français et en néerlandais. Conformément à la documentation utilisateur et à la réalisation, le coût total des formations est subdivisé en une partie NON-OPTIONNELLE et un tableau de prix pour les options. Ce dernier détermine les coûts respectifs supplémentaires par option pour chaque type de formation.

4. Maintenance

Le prix total pour la maintenance suivant les dispositions de III.6.5., pour une période de 3 ans suivant la fin de la période de garantie. La maintenance pour les options P2 est également basée sur une durée standard de 3 ans. Généralement le choix de réalisation des options sera déterminé au début du projet ou par itération. Cependant, la possibilité demeure qu’une ou plusieurs options P2 puisse être levée après la phase de réalisation. Dans ce cas, les coûts de maintenance relatifs à ces réalisations seront recalculés au prorata de la durée restante du marché à ce moment là. Comme indiqué au paragraphe III.6.5, la maintenance est gratuite pendant la période de garantie, à l’exception de la maintenance adaptative.

Partie B – Licences Le soumissionnaire doit dresser un état des prix pour toutes les licences des packages/outils et logiciels de tiers qui font partie de la solution ou sont nécessaires à sa mise en place. Par licence, il doit mentionner le prix total qui permettra à 500 utilisateurs (voir III.4.4.2) d’accéder simultanément à SHERLOCK. Le soumissionnaire est invité à préciser le prix pour l’acquisition initiale et, le cas échéant, pour le renouvellement annuel. L’achat initial des licences intervient après la réception provisoire globale et permet aux utilisateurs finaux désignés de se servir de l‘application (au moins) pendant la période de garantie. Le renouvellement annuel des licences permet ensuite de continuer à utiliser SHERLOCK aux mêmes conditions que celles de l’achat initial. Le soumissionnaire doit indiquer pour les OPTIONS P2 laquelle de ces options ont un impact sur le coût d’une licence. Si le coût de la licence d’un certain package/outil est influencé par plusieurs options, pour chaque combinaison une ligne distincte du tableau des options doit être remplie.


P. 100

Par licence, il faut également mentionner le surcoût éventuel pour 1 utilisateur supplémentaire et pour un groupe de 10 utilisateurs, au cas où le SPF Finances souhaiterait par la suite commander d’autres licences afin de répondre à un futur besoin potentiel d'augmenter le nombre d'utilisateurs de SHERLOCK. Partie C - Assistance complémentaire Le soumissionnaire propose un prix par jour/homme pour l’assistance complémentaire (voir III.6.3). En ce qui concerne l’option de l’assistance complémentaire, il convient de prévoir un maximum de 50 jours/homme par an sur une période totale de 4 ans.

Lu et approuvé, Le Président du Comité de Direction Hans D’HONDT


P. 101

ANNEXE A : FORMULAIRE D'OFFRE Objet de la soumission : Sherlock Cahier spécial des charges : Sherlock Identification du soumissionnaire Société

: :

: Siège social Rue : N° : Boîte : Localité : Code postal : Pays : Numéro de téléphone : Numéro de fax : Numéro de TVA : Numéro d’entreprise :

et pour laquelle Monsieur/Madame (*)

(nom)

(fonction)

domicilié(e) à l’adresse :

(rue) (code postal et commune) (pays)

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’organisme de paiement du pouvoir adjudicateur payera les sommes dues par virement ou versement

sur le compte n° : Code IBAN Code BIC

Pour l’interprétation du contrat, la Langue

française/néerlandaise (*)

est choisie.

Toute correspondance concernant la passation et l’exécution du marché doit être envoyée à l’adresse suivante :

Personne de contact : Téléphone : Fax : E-mail :


P. 102

Adresse postale :

Par la présente, j’accepte/je n’accepte pas (biffer la mention inutile) l’utilisation des moyens de communication électronique (e-mail) pour la correspondance avec le pouvoir adjudicateur dans le cadre du présent marché. Durée de validité de la soumission La présente soumission reste valable jusqu’au : ……………………………………. (minimum 240 jours) J’autorise le pouvoir adjudicateur à prendre toutes informations utiles (par ex. de nature financière) sur mon entreprise, auprès d'autres instances. Je m’engage à effectuer, conformément aux dispositions du présent cahier spécial des charges, les prestations/livraisons énumérées de manière détaillée dans les tableaux de prix joints à la présente soumission, et ce conformément aux tarifs y fixés.

Fait: A Le

Le soumissionnaire ou le fondé de pouvoir :

(nom)

(fonction)


P. 103

ANNEXE B : Curriculum vitae NB : L'utilisation de ce modèle est obligatoire. En complétant les CV, le soumissionnaire doit veiller à écrire le nom des personnes en toutes lettres. De même, il précisera clairement les diplômes et les établissements d'enseignement où ils ont été obtenus. Le pouvoir adjudicateur s'engage à traiter ces données avec une extrême discrétion et à ne les utiliser que pour les besoins de l'évaluation de l'offre. Le pouvoir adjudicateur se réserve le droit de considérer comme insuffisants les CV qui ne respecteront pas les règles ci-dessus et de ne pas les prendre en compte dans l'évaluation de l'offre.

Si les diplômes mentionnés ne correspondent pas à 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) …………………………………………………… ……………………………………………………


P. 104

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

Dans trois autres entreprises au maximum :

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

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

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

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

Autres compétences :

En management ……………………………………………………

En consultance ……………………………………………………

Autres (seulement si pertinent) ……………………………………………………

Connaissance des langues :

Français : compréhension - actif - passif (biffer les mentions inutiles) commentaires ……………………………………………………

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

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

Autres (seulement si pertinent) ……………………………………………………


P. 105

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

1. Nom du projet …………………………………………………………………….

2. Nom de l’entreprise ……………………………

3. Secteur d'activité

…………………………………………………………………….

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

5. Coordonnées

…………………………………………………………………….

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

7. Buts poursuivis

…………………………………………………………………….

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

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

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

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

B. Logiciels ……………………

C. Services ……………………

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

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

B. Partie du marché ……………………

C. Compétence ……………………

12. Complexité Nombre d’utilisateurs, nombre de systèmes IT hors PC (nombre de mainframes, minis et serveurs) …………………………………………………………………….

13. Résumé et brève description des systèmes sources



C. Environnement de développement ……………………

14. Résumé et brève description des systèmes pour la réalisation du projet



C. Environnement de développement ……………………

15. Méthode de gestion de projet

Instrument/méthode …………………………………………………………………….

16. Aperçu des profils affectés au projet ; (nombre (TOTAL) de personnes et hommes-jours pour le projet complet

Profil 1 ……………………

Profil 2 ……………………

Profil 3 ……………………

Profil 4 ……………………

Profil 5 ……………………

Profil … ……………………


P. 106

Annexe D : Formulaire de questions/réponses Remarque : Si la question ne peut être liée à un paragraphe, indiquez "général" dans la première colonne.

paragraphe n° de page

langue Question


P. 107

ANNEXE E : INVENTAIRE

“SHERLOCK”

Sous peine de nullité définitive de l'offre, la présentation des prix doit être conforme à la disposition des tableaux ci-dessous. Il ne sera pas tenu compte de prix mentionnés ailleurs. En cas de divergence entre cet inventaire et un inventaire détaillé du soumissionnaire, il sera exclusivement tenu compte des prix du présent inventaire, annexé au cahier des charges spécial.

Pour une description détaillée des éléments de prix de l'inventaire et des règles complémentaires de détermination des prix à l'aide des tableaux ci-dessous, nous renvoyons au paragraphe III.7. Tableau de synthèse

total général

objet montant NON OPTIONNEL montant OPTIONNEL

hors TVA TVAC hors TVA TVAC

Partie A – Services et prestations sous-total réalisation

sous-total documentation utilisateurs

sous-total formation

sous-total maintenance

Partie B – sous-total Licences

Partie C – sous-total Assistance complémentaire

total général


P. 108

Tableaux détaillés

services et prestations réalisation - besoins fonctionnels niveaux de priorité P1 (NON OPTIONNEL)

itération montant

hors TVA TVAC

R0

R1

R2

sous-total réalisation (non optionnel)

services et prestations réalisation - besoins fonctionnels niveaux de priorité P2 (OPTIONNEL)

par option P2 montant

hors TVA TVAC

DS3

AC2

AC4

AC7

PR1

TR3

LN3

KB1

IN3

EN10

EN6

EN9

sous-total réalisation (optionnel)


P. 109

Documentation utilisateurs par itération - besoins fonctionnels niveaux de priorité P1 (NON OPTIONNEL)

itération montant

hors TVA TVAC

Documentation utilisateurs R0



sous-total documentation utilisateurs (non optionnel)

Documentation utilisateurs - besoins fonctionnels niveaux de priorité P2 (OPTIONNEL)

par option P2 montant

hors TVA TVAC

Documentation utilisateurs DS3

Documentation utilisateurs AC2



Documentation utilisateurs PR1

Documentation utilisateurs TR3

Documentation utilisateurs LN3

Documentation utilisateurs KB1

Documentation utilisateurs IN3

Documentation utilisateurs EN10



sous-total documentation utilisateurs (optionnel)


P. 110

services et prestations formation - besoins fonctionnels niveaux de priorité P1 (NON OPTIONNEL)

formation prix par session nombre sessions montant


session « train the trainers » 2

session « power user / appl. administrator » 2

session « administrateur de systèmes ICT » 2

session « service desk » 2

sous-total formation (non optionnel)

services et prestations formation - besoins fonctionnels niveaux de priorité P2 (OPTIONNEL)

formation par option P2 prix par session pour tous les P2

nombre sessions

montant

DS

3

AC

2

AC

4

AC

7

PR

1

TR

3

LN

3

KB

1

IN3

EN

10

EN

6

EN

9

hors TVA

TVAC hors TVA

TVAC

session « train the trainers » 2

session « power user / appl. administrator »

2

session « administrateur de systèmes ICT »

2

session « service desk » 2

sous-total formation (optionnel)


P. 111

services et prestations maintenance - besoins fonctionnels niveaux de priorité P1 (NON OPTIONNEL)

prix par an nombre années montant


3

sous-total maintenance (non optionnel)

services et prestations maintenance - besoins fonctionnels niveaux de priorité P2 (OPTIONNEL)

par option P2 prix par an nombre années montant


DS3 3

AC2 3

AC4 3

AC7 3

PR1 3

TR3 3

LN3 3

KB1 3

IN3 3

EN10 3

EN6 3

EN9 3

sous-total maintenance (optionnel)


P. 112

assistance complémentaire

prix par jour/homme nombre jours/ homme (50/an)

montant


200

sous-total assistance complémentaire


P. 113

licences (500 utilisateurs simultanés) - besoins fonctionnels niveaux de priorité P1 (NON OPTIONNEL)

nom package/outil prix achat initial prix renouvellement annuel nombre années

montant

hors TVA TVAC hors TVA TVAC hors TVA TVAC

3

3

3

3

3

sous-total licences (non optionnel)

licences (500 utilisateurs simultanés) - besoins fonctionnels niveaux de priorité P2 (OPTIONNEL)

nom package/outil option P2 (*) prix achat initial prix renouvellement annuel nombre années

montant

hors TVA hors TVA hors TVA TVAC hors TVA TVAC

3

3

3

3

3

sous-total licences (optionnel)

* : Le soumissionnaire doit indiquer dans cette colonne laquelle des options possible P2 a un impact sur le coût d’une licence. Si le coût de la licence d’un certain

package/outil est influencé par plusieurs options, une ligne distincte du tableau doit être remplie pour chaque combinaison. Les options P2 possibles sont: DS3, AC2, AC4, AC7, PR1, TR3, LN3, KB1, IN3, EN10, EN6, EN9


P. 114

licences (utilisateurs supplémentaires)

nom package/outil prix pour 1 utilisateur supplémentaire prix pour 10 utilisateurs supplémentaires coût de maintenance mensuel par utilisateur supplémentaire

hors TVA TVAC hors TVA TVAC hors TVA TVAC


P. 115

Annexe F : Concepts

Intitulé Description

Mesures conservatoires / exécutoires

Les biens immeubles et meubles du débiteur servent à payer ce qui est dû au Trésor en cas de non-paiement volontaire par le débiteur et garantissent sa solvabilité. Afin d’éviter que le débiteur diminue sa solvabilité en vendant ses biens, le créancier peut procéder à une saisie conservatoire, empêchant ainsi le débiteur de vendre ses biens au préjudice du créancier ou à une saisie exécution en faisant vendre les biens du débiteur au profit du créancier. En sus des mesures ci-dessus prévues par le code judiciaire, DA dispose de bases légales spécifiques (loi générale sur les douanes et accises) lui permettant de procéder à des saisies conservatoires et/ou exécutoires sur des biens spécifiques de son débiteur selon une procédure particulières.

Décision Mesures conservatoires / exécutoires

Au moment où l’administration a connaissance du fait qu’un contribuable / contrevenant aura une dette envers l’administration, si elle doute à ce moment des possibilités de paiement de l’intéressé, elle peut prendre des mesures conservatoires et les lever en fonction du paiement spontané ou non des sommes dues.

Contribuable / contrevenant Personne qui doit payer les droits et taxes (contribuable) et/ou les amendes (contrevenant). Ces personnes physiques et morales (sociétés) doivent être identifiées correctement (nom, adresse, n° national, n° d’entreprise, etc) et ces données doivent être tenues à jour (par exemple en cas de changement d’adresse). L’historique doit être consultable.

Fraude

Moyen de transport Les véhicules avec lesquels l’infraction a été commise ou qui ont servi à cacher la marchandise de contrebande (en matière de D&A, de taxe de circulation et d’eurovignette).

Moyen utilisé pour la fraude Moyens employés pour commettre la fraude : ensemble des marchandises ayant servi aux contrevenants (ex: transpalette, clark, gsm, gps, ordinateurs, etc.), des marchandises utilisées comme cachettes ou ayant servi à dissimuler les marchandises fraudées, ensemble des moyens de transport utilisés.

Marchandises Les marchandises fraudées : les marchandises qui font l’objet de la fraude et pour lesquelles les taxes dues ont été évitées. Ces marchandises font ou non l’objet d’une saisie effective ou fictive.

Infraction Une infraction est la violation d’une disposition légale ou réglementaire. On se limitera aux infractions pour lesquelles l’AGDA est compétente pour constater.

Acte

Contrainte Titre exécutoire que l'administration se crée à elle-même afin de recouvrer les redevabilités fiscales dans une procédure civile, mais pas les amendes, sans attendre une décision judiciaire.

Pro Justicia (acte de constatation)

Pro Justicia: est établi pour les infractions de droit commun (défaut d’assurance, d'immatriculation ou d'inspection d'un véhicule...)

PV En matière de douanes et accises, le procès-verbal est un exposé écrit des faits tels qu’ils sont constatés par au moins 2 personnes compétentes. Le procès-verbal possède une force de preuve particulière jusqu’à preuve du contraire (fausseté).


P. 116

PV d’audition 424 (document accessoire)

Document dans lequel un agent ayant qualité retranscrit les déclarations faites par une personne (témoin, inculpé). Le PV d’audition accompagne un PV lorsque la loi le prévoit.

Recours administratif (acte) Recours introduit auprès de l’Administrateur général des douanes et accises à des fins de contestation et dirigé contre une décision (ou une absence de décision) en application de la législation en matière de douanes et accises, à l’exception des décisions qui comprennent une peine, émanant d’un directeur régional ou un fonctionnaire de grade équivalent désigné par le Ministre des finances (Auditeur général ou Directeur, chef de service à l’Administration centrale). C’est une étape préalable et obligatoire si un particulier souhaite pouvoir saisir la justice de sa contestation

Recours en grâce (acte) Requête déposée au profit d’un condamné, par lui-même, par un tiers ou par l’autorité compétente d’office afin d’obtenir une remise, une réduction ou une commutation, par arrêté royal, des peines prononcées du chef d’une infraction en matière de douanes et accises (amendes, confiscation, fermeture d’établissement, emprisonnement).

Acte Toutes les décisions de l’administration qui sont consignées par écrit.

Acte de constatation Acte (autre qu’un PV) constatant/actant une infraction à la législation sur la douane et les accises, la taxe de circulation, l’eurovignette ou le droit commun. Les différentes sortes d’actes de constatation sont décrits ci-après.

Acte d’assujettissement 101 (acte de constatation)

Transaction conditionnelle pour le règlement des infractions de douane et accises (et TVA) de faible importance, établie par le service verbalisant. Le règlement est définitif en cas d’acceptation tacite ou expresse du directeur régional dans les 60 jours qui suivent la date de l’acte.

Demande de dispense de verbaliser 614 (acte de constatation)

Transaction conditionnelle pour le règlement des infractions de douane et accises (et TVA), principalement établie en cas de vérification ou contrôle a posteriori des déclarations de douane et accises, par le service verbalisant. Le règlement est définitif si l’acte n’est pas détruit dans les 60 jours suivant son établissement et son acceptation par les services locaux.

Rapport 359 (acte de constatation)

Rapport administratif des verbalisateurs, dans lequel ils décrivent l’infraction constatée et proposent une transaction. La décision de règlement amiable appartient au directeur régional : il acceptera la proposition et proposera une transaction, ou décidera de poursuivre en justice, ou de classer sans suite. Un rapport 359 est établi si le service verbalisant n’est pas compétent pour régler immédiatement l’infraction avec une AVO101 ou un 614 ou si l’infraction n’est pas assez grave pour justifier un PV immédiat.

Document accessoire Document qui accompagne l’acte de constatation et qui est indispensable à la complétude du dossier infractionnel. Exemples : quittance 257, réquisitoire en cas d’arrestation immédiate d’un fraudeur inconnu ou d’un fraudeur ayant commis une infraction susceptible d’arrestation immédiate 404, fiche fraude importante, fiche FEAGA,…

Plan de paiement Décision autorisant le débiteur des douanes et accises à acquitter sa dette par tranches.

Annexe Toutes les annexes / pièces qui font partie d'un dossier d'infraction et constituent la preuve de la fraude. Exemples : procès-verbal d’audition (424), récépissé sommaire des marchandises saisies (368DA), inventaire des marchandises saisies, inventaire des marchandises en entrepôt (cf. art. 313 AWDA), toute autre pièce pouvant figurer au dossier (factures, photos, correspondance….).

Disposition (acte) Toute décision de l’Administration des Douane et Accises ayant des conséquences juridiques pour une ou plusieurs personnes et ne comportant pas de sanction. La disposition doit frapper l’intéressé directement et individuellement.


P. 117

En ce qui concerne le service recouvrement et litiges, il s’agit des invitations à payer (seules les taxes sont recouvrées, sans amende). Dans les autres services, on peut avoir : délivrance ou refus de permis, refus de remboursement…).

Décision Parallèlement aux actes, l’administration prend aussi des décisions (courrier à l’intéressé exposant la position de l’administration).

Décision AB CA Décision concernant les recours administratifs par laquelle l’Administrateur général des douanes et accises confirme ou invalide (en tout ou partie) les décisions ou l’absence de décision. Le contribuable ne peut introduire d’action judiciaire qu’après avoir entamé une procédure de recours administratif. Le délai d’introduction varie selon qu’il a été statué sur le recours ou non.

Décision Recours en grâce Décision concernant le recours en grâce qui peut être favorable sans conditions, favorable sous réserve d’un paiement préalable, ou défavorable.

Transaction (acte) Acte/lettre communiquant au contrevenant les conditions du règlement amiable de son infraction.

Recours administratif La procédure de recours administratif prévoit que le contribuable / client a le droit d’être entendu oralement par l’administrateur général.

Montants

Droits et taxes Les taxes à payer par un ou plusieurs contrevenants / contribuables, p.ex. : droits d’importation UE, TVA, accises, accises spéciales…

Intérêts de retard Des intérêts de retard portant sur les droits et taxes sont dus par le contrevenant lorsque celui-ci ne paie pas immédiatement les sommes qui lui sont réclamées. Des intérêts de retard sont dus au niveau de la transaction et/ou après jugement.

Invitation à payer Demande de paiement des droits, taxes et intérêts de retard, sans amende et susceptible de recours administratif

Dette La somme totale à payer par un ou plusieurs contrevenants ou contribuables dans un dossier déterminé.

Frais Frais causé à l'administration par l'infraction. Différents frais sont récupérables auprès du contrevenant. D'autres sont à la charge de l'administration (frais des mesures conservatoires (hypothèque), frais d'interprète à la constatation). Certains frais sont dus par le redevable dès qu'il y a une transaction (ex: frais de dépannage et gardiennage afin de récupérer le véhicule saisi en matière de taxe de circulation). Certains frais ne sont dus qu'après procédure judiciaire et condamnation définitive (frais de poursuites + ensemble des frais générés par l'infraction et demandés sur citation). Dans certains cas, il y a aussi les frais des mesures conservatoires et/ou exécutoires (hypothèque, frais d’huissier)

Paiement La transaction financière par laquelle le contribuable / contrevenant paie à l’administration les sommes qu’il lui doit. Le paiement est toujours effectué sur le compte du Bureau Unique. Les sommes payées sont ventilées en frais, amendes, taxes et intérêts de retard suivant une hiérarchie prescrite. Le paiement peut aussi passer par la perception d’une sûreté préalablement constituée.

Montant Résultats du calcul des sommes dues.

Amendes Les sommes sanctionnant les infractions à la législation en matière de douane et accises, de taxe de circulation ou d’eurovignette. Il peut s’agir d’une transaction, d'un jugement ou d'un arrêt. Les amendes sont souvent infligées solidairement.

Inscription Moment de l’enregistrement de la somme litigieuse dans la comptabilité. Inscription dans la base de données des dettes Inscription dans la Comptabilité B


P. 118

Inscription au journal auxiliaire (Demande de dispense de verbaliser 614) Inscription sur le compte de crédit spécial A

Intéressés

Intéressés Toutes les personnes (physiques et morales) avec lesquelles le service Recouvrement et litiges entre en contact.

Propriétaire de bonne foi Propriétaire d’un bien qui fait l’objet d’une saisie pénale suite à une infraction dans laquelle il n’est pas impliqué.

Avocat Les avocats propres du départements qui défendent les droits de l’administration devant les tribunaux. Remarque : les avocats du département des finances figurent dans la « liste des avocats du département » (nom, adresse, tél., e-mail, tribunal compétent) tenue et distribuée par l'administration centrale.

Verbalisant Les personnes qui constatent l’infraction / irrégularité. Dans un certain nombre de cas, ces personnes peuvent être étrangères à l’administration (agents de police, fonctionnaires de la circulation...)

Contribuable La personne qui doit payer des taxes dans le cadre d’une infraction / constatation, taxes que l’Administration des Douanes et Accises est compétente pour réclamer. Personne morale / physique

Administration AGDA Ensemble des services généraux et des administrations (au niveau central, régional et local) des Douanes et Accises.

Faillite entreprise / continuité des entreprises

Situation financière d'une personne physique ou morale qui entraîne certaines conséquences sur le traitement du dossier.

Tribunal Les tribunaux impliqués dans le règlement des litiges / recouvrements en matière de douanes et accises (tribunal correctionnel, tribunal de commerce, tribunal du travail, tribunal civil, juge des saisies, juge des référés…).

Huissier de justice Contacts avec les huissiers de justice en vue des significations (jugements / arrêts) et de la prise des mesures conservatoires et exécutoires. Adresses de tous les huissiers de justice en vue des contacts directs ou via médiation de l’avocat du département.

Débiteur en médiation de dettes

Personne physique non commerçante qui est en état de cessation de paiement

Dossier

Pièce Les pièces peuvent être diverses. Sous forme électronique, elles peuvent être au format Word ou Excel (éventuellement rendues non modifiables).

Mémo Notes internes qui sont mentionnées dans le dossier afin d'attirer l'attention du gestionnaire sur certaines tâches à effectuer, sur certaines échéances, sur certains aspects spécifiques du dossier Autre interprétation de « mémo » : noter une conversation téléphonique concernant un dossier ou des conversations tenues au bureau avec le contribuable / contrevenant.

Courrier entrant Correspondance entrante. Peut arriver par la poste classique (scanning) ou par la boîte aux lettres électronique.

Dossier Toutes les pièces et la correspondance d’un dossier de litige. Le dossier peut être à caractère pénal (infraction) ou civil (recours administratif, faillite, règlement collectif de dettes, citation de tiers…). Le dossier sera complété par les services qui traitent le litige à ses stades successifs.

Lettre Toutes les communications formelles entrantes et sortantes relatives à un dossier déterminé, de et vers le contribuable / contrevenant - des tiers - d’autres services (notamment le service verbalisant). Les lettres peuvent être envoyées ou arriver par la poste normale, par e-mail ou par fax.

Notes internes Notes des services compétents (notamment notes de service de


P. 119

l’Administration centrale, dir. régional), utilisées dans le traitement d’un dossier.

Disposition légale Dispositions légales en matière de douanes et accises, taxe de circulation, eurovignette, qui déterminent l’imposabilité et/ou l’infraction à la législation (y compris les sanctions) ou sur lesquelles la disposition de l’administration est basée. Nature (Loi, AR, MB..), date de promulgation, date de publication au MB, toutes les dispositions légales possibles, éventuellement standard pour certaines décisions de routine et/ou à sélectionner dans un fichier avec toutes les lois en vigueur à un moment donné.

Procédure

Procédure Pour chaque dossier, il convient de déterminer la procédure à suivre. Il est aussi possible de changer de procédure en cours de dossier.

Procédure de recours administratif

procédure auprès de l’administration centrale destinée à examiner les contestations relatives aux décisions (ou absence de décision) en application de la législation en matière de douanes et accises émanant d’un directeur régional ou un fonctionnaire de grade équivalent désigné par le Ministre des finances) susceptibles de recours administratif.

Disposition (procédure) Le fait que le directeur régional ou un fonctionnaire de grade équivalent prenne ou non une disposition (voir définition) contre laquelle un recours administratif est possible.

Conclusions Argumentation rédigée par l’administration ou l’adversaire dans une affaire judiciaire.

Citation (procédure) Exploit demandé par l'administration ou l'adversaire en vue de soumettre un litige au tribunal. La citation peut être civile ou pénale.

Contrainte Ensemble des activités relatives aux contraintes lorsque l'administration décide de recouvrer les impôts seulement (sans les amendes) et que le contribuable n’a pas procédé à un recours administratif.

Recours en grâce Procédure destinée à évaluer les recours en grâce et ce afin de corriger la rigueur de certaines condamnations par rapport à la situation personnelle et financière de l’intéressé. L’Administration prend parfois une décision de « surseoir à statuer » prévoyant le respect de certaines conditions (paiement des droits et frais et d’un certain montant d’amende) en fonction desquelles la grâce royale sera acceptée ou le recours rejeté.

Procédure judiciaire Procédure menées devant les tribunaux par l’administration ou le contribuable parce que les parties ne peuvent ou ne veulent pas aboutir à un accord amiable (correctionnel, civil)

Recouvrement Ensemble des procédures relatives au recouvrement, c'est-à-dire à la récupération des sommes auxquelles le contrevenant a été condamné par une décision judiciaire définitive of par une contrainte à titre exécutoire. Si le contribuable réside dans un autre État membre, le recouvrement peut passer par l’ « assistance mutuelle ». Les dossiers de recouvrement peuvent aussi commencer par une demande de recouvrement émanant d’un autre pays de l’Union européenne.

Irrécouvrabilité Si le recouvrement des moyens propres est impossible, l’irrécouvrabilité doit être signalée / demandée à la Commission européenne suivant la procédure prévue dans le Règlement ad hoc.

Transaction (procédure) Procédure tentant de résoudre l’infraction de douanes et accises à l’amiable (sans intervention judiciaire).

Jugement / arrêt Résultat de la procédure judiciaire.

Séance Jours où les affaires de douanes et accises sont traitées par les tribunaux. Une date de séance est demandée en vue de la délivrance d’une citation.


P. 120

Annexe G : Scénarios du Workflow Contentieux et Recouvrement Cette annexe présente plusieurs scénarios métier afin d’illustrer la manière dont les utilisateurs pourraient interagir avec le système. Il ne s’agit pas à proprement parler de cas d’utilisation, car ceux-ci devront être génériques. En effet, il n’est pas attendu que le logiciel en lui-même implémente des scenarios : ceux-ci seront le résultat de la configuration. Ces scénarios ne sont pas exhaustifs, il en existe bien d’autres. Ces scénarios ne sont pas complets, ils admettent des variantes qui sont loin d’être toutes mentionnées. Décision sur une transaction immédiate 101 Scénario : Transaction acceptée

Etape Utilisateur Système

1 Le système reçoit le document de type 101 depuis FIODA.

2 Le système identifie le bureau du contentieux destinataire et applique les règles d’affectation du bureau pour déterminer l’agent en charge ; par défaut le chef du bureau

3 Le système crée le dossier, ajoute le 101 dans les documents, crée et active une action pour l’agent identifié : « décider de la suite à donner » ;

4 Le système propose deux actions : accepter le 101, refuser le 101.

5 L’agent, notifié de l’action, ouvre le dossier et le document 101 et prend sa décision en sélectionnant l’action « accepter le 101 »

La sélection de l’action « accepter » clôture l’action « décider » ; Cela déclenche aussi les règles qui, sur base des métadonnées du 101 (montant, matière), décident de la création ou non d’une action de contrôle pour le chef hiérarchique.

6 Le chef hiérarchique, notifié de l’action « contrôle », active une des deux actions proposées : « valider » ou « rejeter »

Le système clôture les actions du chef et crée un action pour l’agent : « clôturer »

7 L’agent, notifié, déclenche l’action « clôturer »

Calcul des récompenses Envoi des messages Fermeture du dossier

Variante : transaction refusée


5b L’agent rejette la transaction par la sélection de l’action « Refuser le 101 »

Clôture l’action « décider » ; Crée l’action « définir le nouveau montant »

6b L’agent décide le montant, modifie les zones financières en conséquence ; L’agent marque l’action terminée

Enregistre les montants dans PLDA (au minimum : ouvre PLDA, prêt à encoder) Créer le document courrier standard (lequel ?) Créer l’action « envoyer le courrier » Crée l’action « envoyer une note au conseiller général »

7b L’agent complète le document standard

8b L’agent rédige la note L’agent active l’action « envoyer note »

Crée les action « Valider rejet 101 » et « Refuser rejet 101 » pour le chef et notifie

9b Le chef, notifié, consulte et active l’action de validation

Le système clôture les actions du chef et notifie l’agent


P. 121

10b L’agent valide l’action « envoyer le courrier »

Le système imprime le courrier et initie l’action « Vérifier le paiement », avec un délai initial

11b A l’écoulement du délai, le système recherche les traces du paiement dans PLDA

12b A l’écoulement du délai ou à l’arrivée du paiement, l’agent est notifié. Si le paiement est reçu, l’action de clôture est proposée.

13b L’agent, notifié, constate le paiement et valide l’action de clôture.

Le système indique à PLDA de procéder à la mise en recette définitive. Les récompenses calculées et notifiées. Le dossier est clôturé.

Variante : délai écoulé sans action


4 à 7 L’agent n’effectue aucune action dans les délais prévus

Le système :

1) accentue la visualisation de l’action dans la liste des actions ;

2) notifie l’agent par mail ;

3) notifie le chef par mail

Proposition de Transaction La proposition de transaction commence à la réception d’un constat ou d’un PV et se termine par le paiement de la transaction proposée ou par la décision d’une action en justice à l’encontre du contrevenant. Transaction acceptée et payée


1 Enregistre la réception d’un dossier contenant un avis (proposition de transaction).

2 Identifie le bureau destinataire et applique les règles d’affectation du bureau pour déterminer l’agent en charge ; par défaut le chef du bureau.

3 Crée le dossier contentieux et y inclut le dossier d’infraction (Fioda) . Note : prévoir une alter-native en l’absence de Fioda.

4 Crée une procédure « Transaction ». Crée une action « Avis sur nouveau dossier » pour l’agent en charge.

5 L’agent (ou le chef), notifié, consulte le dossier et le vérifie.

6 L’agent rédige une note de résumé et, si possible, calcule les droits, taxes et amendes et stipule la suite proposée. La note comprend une partie de texte libre et une partie de données structurées.

Le système enregistre la note et, selon certaines règles basées sur des métadonnées, notifie (7) ou pas (8) le chef de service pour avis.

7 Le chef, notifié, consulte le dossier et modifie la proposition de suite avec motivation dans une note. Note : le cas échéant, il y a réaffectation de l’agent.

8 Le système propose une des actions, selon l’information enregistrée dans la note : « citation directe », « demande de PV complémentaire », « proposition de transaction », « demande d’enquête complémentaire », « Article 277 ».

9 Sur base des éléments du dossier, l’agent active l’action proposition de transaction.

Le système crée les documents standard de proposition de transaction.


P. 122

Note : dans le cas détaillé ici, on prend le scénario d’une proposition de transaction. Dans le cas d’une demande d’enquête, cette étape est postposée jusqu’à réception (via Fioda) des documents complémentaires.

Les actions suivantes sont proposées :

- Définir la transaction

- Enregistrer dans PLDA

- Editer le courrier de proposition

- Envoyer le courrier de proposition

10 L’agent définit la proposition de transaction et active l’action d’enregis-trement PLDA. Note : la forme que cela prendra reste à définir ; par exemple : remplissage d’un formulaire interne qui serait ajouté aux documents ; ou bien : remplissage de la zone financière.

Le système enregistre les montants dans PLDA.

11 L’agent active l’action d’édition du courrier officiel.

Le système pré-remplit le document avec les montants et autres métadonnées requises.

12 L’agent imprime et envoie le document. Le système active l’action de contrôle du paiement.

13 Voir procédure 101 pour le contrôle du paiement. Voir aussi les alternatives ci-dessous.

Variante : modification d’une proposition de transaction


* L’agent ou le chef active l’action « refaire une proposition de transaction » (laquelle est proposée dès que l’action « faire une proposition » a été réalisée).

Le système marque la proposition en cours comme obsolète (concept à définir) et supprime les enregistrements correspondants dans PLDA (définir la forme que cela prend).

Le système passe au point 9 du scénario de base.

Variante : annulation d’une transaction pour aller en justice


* L’agent ou le chef active l’action « suspendre la transaction » (laquelle est proposée dès que la procédure de transaction a été créée, et commente sa décision (note attachée à l’action).

Le système marque la procédure comme échouée. Il annule toutes les tâches en cours pour cette procédure.

Le système propose l’action « Lancer la procédure pénale » (sur base d’une règle).

L’agent ou le chef active l’action « Lancer la procédure pénale ».

Recours administratif Selon ce scénario, le chef de service (A4) reçoit un courrier de recours administratif ; il l’affecte à un agent qui le traitera effectivement. On suppose dans ce scénario que la requête inclut une demande de suspension.


Phase de réception de courrier

1 Le chef de service (ou son mandataire) reçoit un courrier relatif à une demande de recours administratif.

2 Il se connecte et crée un nouveau dossier Le système crée le dossier


P. 123

vide, de type recours administratif

3 Il scanne et enregistre le courrier Le système importe le fichier

4 Il caractérise le document comme « demande de recours » (métadonnée)

Le système crée les champs pour les métadonnées standard d’un tel courrier + les actions associées (p.ex. accusé de réception, demande d’avis).

5 Il remplit les champs (requérant, date du courrier, langue, etc.)

Le système fournit de l’assistance au remplissage de certains champs (p.ex. requérant recherche Sitran)

6 Il choisit l’action « standard » : réaffectation du dossier

Le système propose les personnes susceptibles de traiter ce dossier

7 Il choisit la personne à qui transmettre le dossier

Le système change l’attribution du dossier (donc aussi celle de toutes les actions en attente).

Phase de traitement du dossier

8 L’agent (A1/A2) ouvre le dossier, le consulte et constate la demande de suspension

9 L’agent modifie le champ (métadonnée) « demande de suspension »

Le système crée les actions associées : « demande d’avis », « proposition de suspension »

10 L’agent active l’action « demande d’avis » (créée au point 4)

Le système crée la lettre type correspondante.

11 L’agent complète la demande d’avis et la valide – il indique la direction régionale compétente.

Le système envoie la demande d’avis à la direction régionale renseignée (action assignée à la personne de contact)

12 L’agent active l’action « proposition de suspension »

Le système crée le document type associé

13 L’agent complète le document de proposition de suspension et le valide

Le système transmet le document au responsable de l’agent pour validation (A3) [c-à-d crée une action à réaliser par cette personne + envoi mail]

14 Le responsable adapte la proposition et la valide

Le système enregistre et trace les modifications (p.ex. versionning) et transmet le document au chef de service (A4) pour validation [idem]

15 Le chef de service valide la proposition Le système clôture les tâches de validation A3 et A4 et active la tâche « notification de la suspension » pour l’agent A1/A2

16 L’agent active l’action « accusé de réception » (créée au point 4)

Le système crée un document d’accusé de réception

17 L’agent complète l’accusé de réception et attache la proposition de suspension et valide.

Le système imprime une version du document à destination du requérant

18 L’agent signe, poste et notifie que l’envoi a été effectué

Le système envoie un message à la personne de contact de la direction régionale pour signaler la suspension.


P. 124

Annexe H : Exemples de scenarios FIODA La dispense de verbaliser (DV614) La Dispense de Verbaliser (DV614) est utilisée lorsqu’une erreur supposée de bonne foi a été commise dans une déclaration en Douanes.


1 L’agent vérificateur procède à des contrôles de la conformité des marchandises par rapport aux déclarations effectuées par l’opérateur. Il constate une erreur.

2 A son poste de travail, l’agent décide d’introduire une proposition de régularisation.

Le système propose à l’agent la liste des lieux de contrôle (dont p.ex. l’aéroport, sur site opérateur, port, etc.).

3 L’agent sélectionne le lieu de contrôle Le système propose à l’agent un second niveau de choix, p.ex. contrôle déclaration, contrôle individus, etc. La liste est définie et configurée par l’AGDA.

4 L’agent sélectionne le contrôle de déclarations.

Le système propose les infractions types (liste définie et configurée par l’AGDA), dont le 614.

5 L’agent sélectionne le DV614 Le système crée un nouveau dossier infractionnel, dans lequel il crée un DV614

6 L’agent encode les métadonnées, dont le numéro de MRN.

Le système recherche les paiements dans PLDA.

7 L’agent recherche et identifie la déclaration (option minimale : l’agent entre le numéro de code de la déclaration)

Le système remplit les champs : id colis, déclarant, valeur déclarée

8 L’agent pointe les éléments fautifs dans la déclaration et indique les valeurs constatées

Le système recourt à PLDA pour calculer les droits de douanes effectivement dus

9 Le système applique une amende de 10% avec un minimum de 25€ (application de règles business régissant le champ « amende » et encodées par l’AGDA)

10 L’agent vérifie la proposition.

11 L’agent imprime et signe le document Le système verrouille la partie 1 du DV614

12 Le système transmet le document au chef de contrôle ou son délégué (routage configuré au niveau de chaque service – tenant compte des absences/congés).

13 Le chef de service voit le nouveau DV614 dans sa liste d’attente. Il l’ouvre et complète sa partie.

Le système verrouille la partie 2 du DV614. Note : Le système vérifie l’écoulement du délai de 60 jours.

14 Le système enregistre l’entrée dans PLDA

15 Le système notifie le dossier à la direction (régionale ?)

16 La direction valide le DV614. Complète éventuellement sa partie.

Le système verrouille la partie 3 du DV614.

17 Le système enregistre pour récompense.


P. 125

Alternative : l’opérateur n’a pas de compte 49.


14bis Le système imprime un courrier d’invitation à payer (note : le paiement est suivi par la recette).