Aspects techniques et environnement existant

du système.

3.4.1.3 Outils de développement standard

Si des développements s'imposent, le soumissionnaire est prié de faire appel aux outils de développement standard existants. Il doit aussi se conformer aux méthodologies standard en vigueur pour l'analyse, le support au développement et la gestion de projet.

3.4.1.4 Identity Management - gestion des identités

L'attention est spécifiquement attirée sur le chapitre 'Identity Management' des standards ICT.

L'exécution du projet doit en tenir compte. Le soumissionnaire est invité à s'y conformer afin que les exigences de l'Identity Management puissent être et soient prises en compte dans le système.

D'autres détails seront communiqués à ce sujet après attribution du marché.

Le SPF Finances tient à ce que le système puisse identifier les utilisateurs via LDAP, car cela permet de limiter l'administration.

Remarque : Contrairement à ce qui est prévu dans le document ABB, le service RBAC-1 n’est pas mis en œuvre.

3.4.1.5 Priorité spécifique: FileNet

L’attention du soumissionnaire est attirée sur le fait que le SPF Finances dispose d’un environnement FileNet avec les ‘site licences’ nécessaires. Cela ne concerne donc pas le seul service d’encadrement ICT. Les détails de cet environnement se trouvent dans les Architectural Building Blocks. Il appartient au soumissionnaire de définir si la solution doit s’appuyer sur l’environnement FileNet (éventuellement en partie), en fonction des exigences imposées.

3.4.2 Développements spécifiques

Les développements spécifiques qui peuvent être nécessaires pour répondre aux besoins doivent faire l'objet d'un prix forfaitaire. L’offre doit s'accompagner d'une description des développements en question.

Pour éviter par la suite les problèmes de mise à jour en cas de nouvelle version, le soumissionnaire s'engage à supporter ces développements dans le cadre de la maintenance de toutes les versions à venir.

Il va de soi que le SPF Finances souhaite limiter au strict minimum les développements spécifiques.

Le soumissionnaire considérera que les développements non essentiels ne sont pas nécessaires et s'abstiendra donc de les proposer.

3.4.3 Paramétrages spécifiques

Pour tous les paramétrages spécifiques, le soumissionnaire précisera s'ils doivent être réalisés par lui seul ou si le SPF peut s'en charger de façon autonome, moyennant une formation adéquate.

3.4.4 Support Helpdesk

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’adjudicatiare 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 il aura la responsabilité. 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 charge de toutes les interventions possibles à effectuer sur les logiciels à entretenir.

Les services proposés par l'adjudicataire seront introduits dans le respect de la méthodologie ITIL, appliquée au sein du SPF Finances. Cela signifie notamment que la gestion des incidents, problèmes, changements, etc doit être conforme aux méthodes en vigueur au sein du SPF Finances.

La première ligne se chargera de distinguer les incidents d'infrastructure et les incidents applicatifs.

La communication entre la première et la deuxième ligne est décrite par le soumissionnaire. Elle doit permettre à la première ligne de mettre l'utilisateur en contact avec la deuxième ligne si la première soupçonne que l'incident signalé va nécessiter une intervention sur place ou une communication entre deuxième ligne et utilisateur. Dans son offre, le soumissionnaire indique comment il entend

appliquer les normes ITIL dans sa tâche et comment il va acquérir les connaissances nécessaires pour s'intégrer dans les processus existants.

La transmission des appels entre le Service desk du SPF Finances et le helpdesk de deuxième ligne que l’adjudicatiare 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 OpenView) à l'outil utilisé par le service manager pour la gestion et le suivi des appels.

Le soumissionnaire expliquera dans son offre les canaux qu'il supporte. Il précisera en particulier :

• Les moyens dont le SPF Finances disposera pour contrôler à tout moment l'état des appels ouverts.

• Les moyens dont le SPF Finances disposera pour contrôler le respect du SLA.

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

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

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

Le soumissionnaire expliquera le service en tenant compte de tous les points évoqués ici. Il fournira aussi les autres services qu'il juge nécessaires.

L’adjudicatiare 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.

Les heures auxquelles le helpdesk est accessible et les solutions disponibles se situeront toujours entre 7h30 et 18h00.

3.4.5 Performances

Le système doit être disponible de 7h00 à 19h00 sans dégradation notable des performances, De plus, la disponibilité 24h/24 doit être garantie pour certaines documentations (p.ex. disaster recovery, mais aussi d’autres). Le soumissionnaire est libre de proposer un système garantissant la disponibilité 24h/24 pour l’ensemble du contenu.

3.4.6 Exigences en matière d'intégration aux standards existants

Dans le prolongement de l'introduction de cette partie, l'attention du soumissionnaire est encore une fois attirée sur les exigences en matière d'intégration aux standards existants. L’adjudicatiare recevra après attribution du marché des informations complémentaires concernant ce qui suit (mais aussi concernant les autres normes le cas échéant).

3.4.6.1 Connecteurs – interfaces – échanges de données

La connexion avec les systèmes en place au sein du SPF Finances et nécessaires à la bonne exploitation du système fait partie intégrante du marché. Elle ne peut donner lieu à aucune forme de facturation. Les informations de base sur ces systèmes figurent sur le site web du SPF Finances, sous ‘ICT et plan informatique’ (ABB v3.0).

Il est clair que le système devra interagir avec une série d'autres systèmes, dont certains restent peut-être à 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. Le soumissionnaire doit donc préciser les conditions à remplir pour qu'un système soit connectable.

3.4.6.2 Poste client

Le SPF Finances attache une importance particulière à l'indépendance des solutions par rapport aux postes clients. Le soumissionnaire 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 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é.

En principe, tous les postes de travail reposeront sur la technologie PC.

3.4.7 Utilisateurs externes

Par ‘utilisateurs externes’, il faut entendre les personnes qui travaillent au SPF Finances mais ne font pas partie du service d’encadrement ICT. À ce titre, ils doivent être connus comme utilisateurs dans LDAP et dans les systèmes de gestion des identités et des accès.

Ces utilisateurs doivent pouvoir consulter certaines données dans le système, en fonction des circonstances. Cela peut par exemple passer par un accès direct en lecture à une partie du système, une certaine documentation, etc.

Le soumissionnaire proposera la solution la plus efficiente et économique possible à cette fin.

3.4.8 Ouverture et prise en compte des standards ouverts

Le SPF Finances veillera en particulier à ce que les solutions proposées soient conformes aux standards ouverts, notamment en ce qui concerne la communication entre systèmes, l'interopérabilité, etc (utilisation de SOA, respect des normes XML, ouverture de la solution, priorité aux standards ouverts plutôt qu'aux standards propriétaires, etc.).

Le soumissionnaire doit proposer un système ouvert et flexible, notamment en ce qui concerne les interfaces, mais aussi, le cas échéant, en termes de compatibilité avec nos 'ICT browsers' standard, afin que l'on puisse profiter des possibilités de Web 2.0 et d'AJAX ainsi que des futurs développements de la technologie Internet. Le soumissionnaire explique cet aspect dans son offre.

Le soumissionnaire se conforme aussi à la note de FedICT ‘Directives et recommandations pour l'utilisation des standards ouverts et/ou des spécifications ouvertes dans les administrations fédérales’, note disponible sur le site web du SPF Finances ;

http://minfin.fgov.be/portail1/nl/ict/pdf/OpenstandaardenNL_FEDICT.pdf.

3.4.9 Utilisation de logiciels ouverts ('Open source')

Le soumissionnaire doit préciser sous quelle licence les logiciels sont distribués. La licence doit donner la liberté de modifier le code, en collaboration ou non avec le fournisseur ou un de ses partenaires.

Le soumissionnaire doit aussi indiquer si des modules complémentaires sont disponibles sous d'autres licences.

Le soumissionnaire doit décrire l'organisation mise en place pour la gestion des évolutions. Il précisera le nombre moyen de développeurs qui ont participé ces deux dernières années au développement du noyau du produit. Il indiquera le site Internet européen destiné aux utilisateurs du produit.

3.4.10 Internationalisation des logiciels

Ce point est très important. Il entraînera l'élimination de tout logiciel qui n'autoriserait pas cet accès multiple.

Le logiciel doit être accessible en même temps dans un minimum de deux langues (néerlandais, français).

Les deux langues opérationnelles sont le néerlandais et le français.

Le choix de la langue est opéré par l'utilisateur au stade du log-in.

La langue d'accès concerne :

• les mentions dans les masques et formulaires

• les listes de choix à la saisie

• le stockage de l'information issue des listes de la base de données.

Toute saisie effectuée dans une liste de valeurs doit pouvoir se faire dans la langue du log-in. Ces informations doivent pouvoir être lues par un autre utilisateur dans sa propre langue si elle est

différente, durant une consultation ou une modification.

Le soumissionnaire précisera quelle méthode le logiciel applique et comment l'exigence de multilinguisme est remplie par le projet.

Le soumissionnaire proposera aussi avec le logiciel un outil externe pour la réalisation des traductions et des mises à jour du logiciel. Cet outil aidera les gestionnaires dans le développement, la modification et l'enrichissement de leurs listes ainsi que dans la création de nouvelles listes.

Pour le reste, les exigences sont les suivantes:

• Dans l'interface, il doit être possible de passer rapidement d'une langue à une autre.

• Le changement de langue doit être transparent aux yeux de l'utilisateur.

• Normalement, la langue de l'interface est celle qui figure dans le profil de l'utilisateur.

La réponse à ces exigences n'est pas obligatoire pour la langue allemande.

3.4.11 Cycle de mise en production

Pour la mise en production de l’application, le cycle de développement suivant est obligatoire : Le développement doit avoir pour cadre les environnements de développement. Les tests auront lieu dans les environnements d'intégration. Les tests d'acceptation se dérouleront dans les environnements d'acceptation. Le passage à la production suivra une issue positive des tests d'acceptation.

3.4.12 Disponibilité et performance de l’application

Dans son offre, le soumissionnaire précise les performances et la disponibilité de l'application (ou de parties de l'application) qu'il peut garantir dans des conditions données. Ces performances et disponibilité figureront aussi dans le SLA.