9544 dsi1213 1 lecahierdesclausestechniquesparticulieres c c t p etsesdocumentsannexes rev1

Cahier des clauses techniques particulières Fourniture et mise en œuvre du nouveau portail intranet/extranet du CG 63

Conseil général du Puy-de-Dôme

Cahier des clauses techniques

particulières

FOURNITURE ET MISE EN ŒUVRE DU NOUVEAU

PORTAIL INTRANET/EXTRANET DU CONSEIL GENERAL

Cahier des clauses techniques particulières Fourniture et mise en œuvre du nouveau portail intranet/extranet du CG 63 1

1. Introduction ____________________________________________________________ 5

2. Description fonctionnelle de la solution attendue ______________________________ 9

3. Description des contraintes techniques _____________________________________ 41

4. Prestations générales attendues __________________________________________ 49

5. Assistance technique, support et maintenance (phase technique 7) ______________ 56

6. Aide à la formulation de la réponse ________________________________________ 59

7. Annexes ______________________________________________________________ 61

Ce document comporte 70 pages


1. Introduction ____________________________________________________________ 5

1.1. Présentation du Conseil général du Puy-de-Dôme _______________________________ 5

Les missions __________________________________________________________________ 5 1.1.1.

Quelques chiffres ______________________________________________________________ 5 1.1.2.

1.2. Contexte général __________________________________________________________ 5

1.3. Présentation des objectifs du projet __________________________________________ 6

1.4. Objet du document et aide à la lecture ________________________________________ 6

1.5. Eléments de réponse attendus _______________________________________________ 7

Eléments de réponse généraux ___________________________________________________ 7 1.5.1.

Eléments de réponse spécifiques __________________________________________________ 7 1.5.2.

1.6. Phasage du projet et calendrier prévisionnel ___________________________________ 8

2. Description fonctionnelle de la solution attendue ______________________________ 9

2.1. Administration ___________________________________________________________ 9

Gestion des rôles ______________________________________________________________ 9 2.1.1.

2.1.1.1. Gestion globale ______________________________________________________________ 9

2.1.1.2. Gestion pour la publication de contenus ________________________________________ 10

Gestion des groupes ___________________________________________________________ 11 2.1.2.

Statistiques __________________________________________________________________ 12 2.1.3.

2.2. Gestion des pages ________________________________________________________ 13

Gestion des rubriques et de l’arborescence ________________________________________ 13 2.2.1.

Agencement des gabarits de pages _______________________________________________ 13 2.2.2.

Gestion des types de pages _____________________________________________________ 13 2.2.3.

Blocs composant les pages ______________________________________________________ 15 2.2.4.

2.2.4.1. Blocs envisagés au lancement de l’intranet ______________________________________ 15

2.2.4.1.1. Blocs « standards » ______________________________________________________ 15

2.2.4.1.1. Blocs « avancés » ________________________________________________________ 18

Pages à destination d’une population spécifique ____________________________________ 19 2.2.5.

2.3. Gestion des contenus _____________________________________________________ 20

Types de contenus ____________________________________________________________ 20 2.3.1.

2.3.1.1. Configuration des types de contenus ___________________________________________ 21

2.3.1.2. Règles de saisies ____________________________________________________________ 21

2.3.1.3. Types de contenus spécifiques ________________________________________________ 22

Evènements ____________________________________________________________________ 22

Questions / réponses ____________________________________________________________ 22

Petites annonces ________________________________________________________________ 23

Contenus multimédias ___________________________________________________________ 23

Formulaires ____________________________________________________________________ 23

Fonctionnalités d’administration et d’édition ______________________________________ 29 2.3.2.

2.3.2.1. Accès aux interfaces de contribution en Front Office _______________________________ 29

2.3.2.2. Accès aux interfaces de gestion en Back Office ___________________________________ 30

2.3.2.3. Ubiquité des contenus _______________________________________________________ 30

2.3.2.4. Interface WYSIWYG _________________________________________________________ 30


2.3.2.5. Base documentaire de fichiers ________________________________________________ 31

2.3.2.6. Base documentaire de photos _________________________________________________ 31

2.3.2.7. Base documentaire de vidéos _________________________________________________ 32

2.3.2.8. Planification des publications _________________________________________________ 33

2.3.2.9. Fonction d’aperçu avant publication ____________________________________________ 33

2.3.2.10. Lier des ressources ________________________________________________________ 33

2.3.2.11. Gestion des mots-clés/tags _________________________________________________ 33

2.3.2.12. Versionning des publications ________________________________________________ 34

Fonctionnalités accessibles aux lecteurs de contenus ________________________________ 34 2.3.3.

2.3.3.1. Services en ligne ____________________________________________________________ 34

2.3.3.2. Sondage __________________________________________________________________ 34

2.3.3.3. Notation __________________________________________________________________ 35

2.3.3.4. Recommandation ___________________________________________________________ 35

2.3.3.5. Abonnement _______________________________________________________________ 35

2.3.3.6. Favoris ____________________________________________________________________ 35

2.3.3.7. A lire plus tard _____________________________________________________________ 36

2.3.3.8. Signalement d’obsolescence __________________________________________________ 36

2.3.3.9. Flipbook pdf _______________________________________________________________ 36

2.3.3.10. Newsletter ______________________________________________________________ 36

2.4. Fonctions transverses _____________________________________________________ 37

Moteur de recherche __________________________________________________________ 37 2.4.1.

Alertes ______________________________________________________________________ 38 2.4.2.

Annuaire ____________________________________________________________________ 39 2.4.3.

Version mobile de l’intranet _____________________________________________________ 40 2.4.4.

3. Description des contraintes techniques _____________________________________ 41

3.1. Préambule ______________________________________________________________ 41

3.2. Fourniture des documentations _____________________________________________ 41

3.3. SSO ___________________________________________________________________ 42

3.4. Accès depuis les postes utilisateurs __________________________________________ 43

3.5. Serveurs et Virtualisation __________________________________________________ 43

3.6. Bases de données ________________________________________________________ 43

3.7. Flux de données _________________________________________________________ 44

3.8. Pour sites internet _______________________________________________________ 44

3.9. Performance de la solution ________________________________________________ 45

Qualité de service _____________________________________________________________ 45 3.9.1.

Topologie du réseau – accès internet _____________________________________________ 45 3.9.2.

Dimensionnement et évolution de la capacité de la solution ___________________________ 45 3.9.3.

Surveillance/exploitation _______________________________________________________ 46 3.9.1.

3.10. Respect des normes d’interopérabilité et accessibilité _________________________ 47

3.11. Développement et personnalisation _______________________________________ 48

4. Prestations générales attendues __________________________________________ 49


4.1. Cadrage du projet ________________________________________________________ 49

Tableaux de bord _____________________________________________________________ 49 4.1.1.

Environnements ______________________________________________________________ 49 4.1.2.

4.2. Spécifications fonctionnelles (phase technique 1) ______________________________ 50

4.3. Graphisme et ergonomie (phase technique 2) _________________________________ 50

Création de la charte graphique __________________________________________________ 50 4.3.1.

Elaboration de l’ergonomie _____________________________________________________ 51 4.3.2.

Evolution de la charte graphique _________________________________________________ 51 4.3.3.

Accessibilité __________________________________________________________________ 51 4.3.4.

4.4. Mise en œuvre sur environnement de recette (phase technique 3) ________________ 52

4.5. Mise en œuvre sur environnement de production (phase technique 4) _____________ 53

4.6. Formations (phase technique 5) ____________________________________________ 54

4.7. Prestations complémentaires (phase technique 6) ______________________________ 55

4.8. Opérations de vérification _________________________________________________ 56

5. Assistance technique, support et maintenance (phase technique 7) ______________ 56

5.1. Conditions de maintenance ________________________________________________ 56

6. Aide à la formulation de la réponse ________________________________________ 59

7. Annexes ______________________________________________________________ 61

7.1. Schéma simplifié d’architecture sécurisée ____________________________________ 61

7.1. Architecteur SSO / OpenAM _______________________________________________ 61

7.1. Tables intermédiaires RH pour synchronisation ________________________________ 62

7.1. Gestion actuelle des identités ______________________________________________ 63

7.2. Récupération du nombre de messages non lus GroupWise _______________________ 63

7.3. Applications accessibles depuis l’intranet SPIDI ________________________________ 64

Légende _____________________________________________________________________ 64 7.3.1.

Colonne : Type d'authentification _______________________________________________________ 64

Colonne : Méthode d'authentification ___________________________________________________ 64

Liste au 08/08/13 _____________________________________________________________ 65 7.3.2.

7.4. Bloc « Petites annonces » __________________________________________________ 68

7.5. Bloc « Remontée d’application » ____________________________________________ 68

Logiciel « Frais de déplacement » ________________________________________________ 68 7.5.1.

Logiciel « Demandes de renfort » ________________________________________________ 69 7.5.2.

Logiciel « Intentions d’achats » __________________________________________________ 69 7.5.3.


1. Introduction

1.1. Présentation du Conseil général du Puy-de-Dôme

Les missions 1.1.1.

Le Conseil général est la collectivité en charge des affaires du département. L'essentiel de ses

compétences actuelles et les modes de fonctionnement qui en découlent, résultent des lois de

décentralisation de 1982 et 1983, régulièrement complétées depuis.

Ces lois donnent en particulier aux conseils généraux des missions spécifiques dans les domaines

suivants :

l'action sociale en faveur des personnes âgées, des personnes handicapées, de l'enfance et

de la famille, des personnes en difficulté ;

la construction, l'entretien et le fonctionnement des collèges publics ;

le transport scolaire et les transports publics routiers sur le territoire départemental ;

la construction et l'entretien des routes départementales ;

la participation aux services départementaux de secours et d'incendie.

A ces missions spécifiques s'ajoutent des missions particulières dans les domaines de la promotion

touristique, de la lecture publique, des archives départementales, etc.

Quelques chiffres 1.1.2.

Le Conseil général du Puy-de-Dôme est composé de :

470 communes réparties en 61 cantons ;

632 311 habitants (chiffre 2010) ;

2333 agents auxquels s’ajoutent 350 assistants familiaux employés à domicile ;

190 agents en télétravail parmi les 2333. Ils utilisent des postes virtuels mis à leur

disposition ;

3 sites principaux : l’Hôtel du Département, les sites Michel de l'Hospital et Georges

Couthon ;

Une centaine de sites distants répartis sur tout le département dans les divisions routières et

les circonscriptions d'actions sociales.

1.2. Contexte général Une technologie vieillissante

Le Conseil général du Puy-de-Dôme possède un portail intranet (nommé « SPIDI ») qui s’est amélioré

au fils des années depuis sa réalisation en 2002. Cet historique de 10 ans a permis de bâtir un portail

aujourd’hui mâture. L’intranet est hébergé en interne et la maintenance est effectuée par la DSI et

un intégrateur (via un contrat de support et d'assistance technique).

Ce portail contient un fort contenu éditorial mais il est également le point d’accès unifié à toutes les

applications métiers des agents. Le logiciel sur lequel est bâti ce portail « Oracle Portal 10G » est

aujourd’hui en fin de vie. Cela oblige le CG63 à migrer son portail dans les prochaines années sur un

nouveau logiciel.


Le CG63 souhaite profiter de cette opportunité pour opérer une refonte de son portail. Celui-ci devra

être simple d’utilisation et ergonomique afin d’en faciliter l’appropriation par les agents du CG.

Sur ce projet, le Conseil général est accompagné d'une assistance à maîtrise d'ouvrage.

Un développement des usages 2.0

Au-delà de cette refonte, un autre chantier est en cours. Il concerne le développement des espaces

collaboratifs au sein du CG sur la technologie « Novell Vibe ». Le présent marché n’a pas pour but

d’équiper les agents d’un outil concurrentiel à Novell Vibe. En revanche, des passerelles devront être

créées entre le futur intranet et le produit Novell Vibe.

1.3. Présentation des objectifs du projet Les objectifs du projet intranet du CG63 sont de :

S’assurer de disposer d’un intranet au minimum isofonctionnel et opérationnel par rapport

à celui existant

o En offrant des accès directs vers un grand nombre d’applications (50 exactement) et

ce via un mode SSO. Toutefois, le portail ne devra plus être fédérateur d’identité

pour le SSO.

o Grâce à une offre de services riche basée sur des formulaires en ligne et des

applications web

o Grâce à des fonctionnalités (en front et back-office) au périmètre large grâce à dix

années de développements évolutifs accumulés

Intégrer des fonctionnalités innovantes pour rendre toujours plus attractif et utile

l’intranet de l’institution

o Compteur de notifications

o Personnalisation accrue

o Annuaire riche

o Fiche profil des derniers arrivants

o Ciblage de la communication

o Moteur de recherche performant

o Foire aux questions contextualisée

o Etc.

Le CG63 souhaite mettre en place une solution couvrant l’ensemble des besoins exprimés, en

maximisant l’utilisation de fonctions natives et donc en limitant les développements spécifiques.

Dans le cas de développements spécifiques envisagés, le soumissionnaire l’indiquera clairement

dans son offre.

1.4. Objet du document et aide à la lecture Ce document constitue le cahier des clauses techniques particulières (CCTP) pour la refonte de

l’intranet du CG63. Il fait état du besoin et des attentes du CG63.

Ce CCTP décrit notamment :


Le contexte et la démarche attendue pour la réalisation de la prestation,

Les fonctionnalités attendues,

La configuration initiale attendue,

Les prestations associées attendues,

Les niveaux de maintenance, de support et d’assistance technique,

Les conditions de sécurité, de contrôle et de conformité souhaitées,

Les éléments de réponse attendus.

Des éléments de réponse spécifiques peuvent être demandés et sont précisés pour chaque exigence

fonctionnelle ou technique au sein de chacune des parties du présent cahier des charges. Ces

éléments viennent compléter les éléments attendus dans le cadre de la réponse du soumissionnaire,

et précisés ci-après.

Dans ce document, les termes « maître d’œuvre », « MOE », et « titulaire » désignent le futur

titulaire du présent marché. Les termes « collectivité », « MOA », « CG63 » ou encore « pouvoir

adjudicateur » désignent le Conseil général du Puy-de-Dôme. Le terme « soumissionnaire » désigne

tout acteur économique répondant au présent cahier des charges.

1.5. Eléments de réponse attendus

Eléments de réponse généraux 1.5.1.

De manière générale dans sa réponse, le soumissionnaire apportera les éléments suivants :

Une note méthodologique présentant sa démarche pour la conduite du projet, le transfert

de compétences (notamment technique), les méthodes et outils qui lui serviront d’appui ;

Une description des caractéristiques et une évaluation financière de l’infrastructure

nécessaire au bon fonctionnement de l’application dans le contexte décrit ;

Une description fonctionnelle (et technique) détaillée de la réponse (socle technique et

implémentation) apportée à la définition fonctionnelle du besoin ;

Une évaluation des charges et actions attendues par le pouvoir adjudicateur ;

Un planning de réalisation détaillé allant jusqu’à la fin de la phase de déploiement général de

l’intranet ;

L’équipe proposée (description des expériences d’intégration avec la solution proposée,

niveau de certification de chaque membre de l’équipe et rôles précis de chacun des

intervenants) ;

L’offre commerciale dans le cadre d’une réalisation au forfait ;

L’offre commerciale concernant le support, l’assistance technique et la maintenance sur 3

ans.

Eléments de réponse spécifiques 1.5.2.

Excepté mentions particulières, les exigences fonctionnelles dans leur ensemble sont considérées

comme des « Exigences principales » qui devront être couvertes dans l’offre. De manière spécifique,

certaines exigences sont mentionnées comme des « Exigences secondaires ». Cette distinction

permet de hiérarchiser l’importance accordée.


Tout au long du présent cahier des charges, des paragraphes précisent au soumissionnaire ce qu’il

doit apporter comme éléments de réponse. Le soumissionnaire reste libre d’apporter en

complément toute information permettant de mieux comprendre sa proposition.

Il est demandé que les réponses soient le plus possible agrémentées de copie(s) d’écran présentant

des réalisations correspondant aux demandes, et qui ont déjà été déployées par le soumissionnaire.

Des schémas sont également possibles lorsque le soumissionnaire ne dispose pas de capture d’écran

ou bien lorsque cela clarifie une explication rédigée.

1.6. Phasage du projet et calendrier prévisionnel

Eléments de réponse attendus

Le soumissionnaire doit fournir un planning détaillé de mise en œuvre.


2. Description fonctionnelle de la solution attendue

2.1. Administration

Gestion des rôles 2.1.1.

2.1.1.1. Gestion globale

L’attribution des droits d’accès est basée sur l’utilisation de rôles. Ci-dessous un descriptif des rôles

qui sont prévus. Un rôle correspond à un ensemble de droits (ex : droit de publier, droit d’initier un

contenu…) sur un emplacement donné. Il sera possible de créer d’autres rôles en combinant

différents droits.

Administrateur technique En charge de l'administration technique de l’intranet

Administrateur fonctionnel En charge de l'administration fonctionnelle de

l’intranet et des fonctions décrites dans ce CCTP

Gestionnaire de groupes En charge de la gestion des utilisateurs et des groupes

d’utilisateurs

Gestionnaire de rubrique Accède aux fonctions de gestion (définies dans chaque

rubrique). Ex : gestionnaires de la rubrique RH

Contributeur/publicateur Accède aux fonctions de contributions et peut

déléguer son rôle

Valideur

Valide et donc publie les contenus proposés par les

publicateurs dont il est responsable. Le valideur devra

également valider les workflows de publication dans

ses espaces.

Lecteur Accède au contenu, peut publier des commentaires et

recommander des informations à des groupes.

Répartition et gestion des rôles

Chaque acteur bénéficiant d’un droit d’accès a nécessairement un rôle.

Les rôles d’un utilisateur pourront être différents d’un emplacement de l’intranet à l’autre. Ainsi le

valideur d’une rubrique A pourra être un simple lecteur d’une rubrique B.

La solution permettra de :

Lister tous les droits/rôles d’un acteur donné

Lister tous les acteurs/rôles et leurs droits sur un emplacement (rubrique, sous-rubrique,

etc.)


Définir et distribuer les rôles par module ou plus largement, à l’aide d’une interface de

gestion.

Rôle de l’administrateur fonctionnel

Un administrateur fonctionnel intervient sur une partie ou la totalité du site.

L’administrateur fonctionnel sera en mesure de configurer les modules (par exemple les droits sur

une rubrique), de définir l’agencement des pages d’accueil, de définir les types de publication,

d’affecter les droits et les rôles.

Il pourra déléguer, sur une instance d’un module donné, la gestion des droits / des rôles au

gestionnaire de l’instance. Il pourra également répandre par héritage les droits/rôles d’une rubrique,

ou sous-rubrique à l’ensemble de ses sous-éléments, écrasant alors la configuration existante de ces

sous- éléments.

Ergonomie du Back Office

La majorité des actions de gestion / publications s‘effectuera dans le Back Office de la solution. Dans

celui-ci, seules les fonctions autorisées aux rôles y accédant seront affichées. Ce Back-Office devra

être le plus épuré possible pour en faciliter l’intuitivité et la prise en main. Il s’agit d’un des

inconvénients de l’outil actuel auquel le futur intranet devra pallier.

2.1.1.2. Gestion pour la publication de contenus

Rôles et cycle de vie d’un contenu

Le cycle de vie standard d’un contenu est défini par 5 états :

• brouillon [uniquement visible du contributeur qui a initié le contenu],

• soumis à validation [visible du valideur qui doit en valider la publication],

• refusé [accessible uniquement par le back office],

• validé (publié) [affiché dans l’intranet et visibles de tous les utilisateurs ayant accès à la

page sur laquelle le contenu est publié],

• dé-publié [archivé, éventuellement accessible comme une « ancienne version » d’un

contenu disponible sur l’intranet].

Par défaut, un contenu est diffusé à partir du moment où il est 'validé' et dé-publié

automatiquement en fonction de la date programmée ou par une action du contributeur ou du

gestionnaire.

Lorsque le contributeur a aussi le rôle de valideur de ses propres contenus, le contenu est publié

directement sans passer par une étape de validation.


Accès aux interfaces de contribution en front office

Pour les contributeurs, ayant pour rôle d’ajouter/de modifier des contenus dans une rubrique

donnée, la contribution pourra se faire sur le front office.

Accès aux interfaces de gestion en back office

L’accès aux interfaces de gestion pourra également se faire par un lien disponible sur le Front Office,

sur les pages où apparaissent les publications.

Rôle du valideur

Le module de gestion de contenus s'appuiera sur un mécanisme de Workflow simple permettant au

valideur de valider la publication de contenus. Il pourra également supprimer des contenus a

posteriori selon les rôles et droits décrits précédemment.


Le soumissionnaire présentera l’ensemble des rôles proposés par sa solution ainsi que l’interface de

gestion et les fonctionnalités associées.

Description de la configuration initiale attendue

Les processus de publications associés aux différents types de contenus devront être configurés avec

les différents rôles qui seront spécifiés.

Gestion des groupes 2.1.2.

Des groupes pourront être définis dans la solution. Ils permettront d’affecter plus rapidement les

droits aux utilisateurs. Ils pourront être composés à partir d’un référentiel d’identité, d’autres

annuaires et bases de données. Ils pourront également être créés manuellement dans le back-office

de l’intranet.

Une API doit être disponible. L’objectif consiste en la récupération des groupes et sous-groupes

auxquels appartient un utilisateur donné, ou encore de lister les membres d’un groupe, pour des

applications internes. En effet, des applications créées en interne s’appuient sur ces groupes pour la

gestion des droits internes à l’application.

Par ailleurs, les groupes hiérarchiques (DG, Directions, Services) ainsi que les groupes fonctionnels

("Chefs de service", "Directeurs", "DGA") doivent être créés dans l’intranet ainsi que l’appartenance

des utilisateurs à ces groupes.

La synchronisation de ces groupes et membres avec les mouvements des ressources humaines

(nouvel arrivant, création de services…) doit être automatisée et devra s’appuyer sur une base de

données intermédiaire (Cf. schéma logique en annexe). Cette synchronisation doit permettre l’ajout

de nouveaux utilisateurs et la création de nouveaux groupes.


La description de l’API de synchronisation doit nous être fournie de manière à assurer l’autonomie de

la DSI lors d’évolutions futures.

Exigence secondaire

La gestion des groupes et utilisateurs peut être déléguée au sein d’une interface spécifique. Le but

est de décentraliser cette gestion au niveau des directions du département, et ne pas la restreindre

aux administrateurs fonctionnels.


La synchronisation des utilisateurs et des groupes sera réalisée avant l’ouverture de l’intranet à

l’ensemble des agents. Le soumissionnaire indiquera dans sa réponse les caractéristiques de l’API de

sa solution.

Statistiques 2.1.3.

La solution devra fournir des statistiques relatives à l’utilisation de l’intranet. Le module de

statistiques pourra par exemple contenir les informations suivantes :

Nombre de personnes connectées (par jours, semaines, mois, années)

Nombre de connexions sur le site (par jours, semaines, mois, années)

Nombres de pages vues (par jours, semaines, mois, années)

Mots clés ou thèmes recherchés

Durée de lecture des pages

Pages les plus consultées

Vidéos les plus consultées

Statistiques d'accès aux documents

Statistiques sur tous les liens du portail

Ces statistiques devront pouvoir être croisées avec les groupes d’utilisateurs. Ces informations

seront disponibles de manière brute pour l’export des données ou pour l’exploitation directe via

nos outils de reporting, et de manière consolidée sous forme graphique.

L’ensemble complet des indicateurs statistiques sera défini avec le titulaire lors des travaux de

spécifications fonctionnelles afin de fournir plusieurs tableaux de bord représentatifs de l’usage de

l’intranet.

Il sera possible d’afficher le nombre de vue d’une publication dans le Back Office comme dans le

Front Office.

Les performances de l’application ne devront en aucun cas être impactées par l’utilisation du module

de statistiques.


2.2. Gestion des pages

Gestion des rubriques et de l’arborescence 2.2.1.

L’information est organisée par rubriques, qui correspondent aux éléments du menu de navigation

principal du site. A l’intérieur de ces rubriques, l’information est organisée par sous-rubriques

arborescentes dans lesquelles les contenus peuvent être multi positionnés.

L’administrateur fonctionnel pourra gérer les rubriques et faire évoluer l’arborescence. Il pourra

créer de nouvelles rubriques et sous-rubriques.


Le soumissionnaire présentera précisément le processus de gestion des rubriques et de

l’arborescence de sa solution.

A titre d’exemple, voici l’état de la réflexion concernant l’arborescence du futur intranet :

Agencement des gabarits de pages 2.2.2.

Chaque page de l’intranet s’appuiera sur un gabarit. La solution permettra de modifier les gabarits de

pages au fil du temps pour faire évoluer les pages. Elle devra permettre à l’administrateur

fonctionnel de définir de nouvelles zones et de les disposer selon ses besoins, de manière simple et

ergonomique. Les nouveaux gabarits ainsi créés pourront servir pour générer de nouveaux types de

pages. L’ensemble de ces étapes se fait sans l’utilisation de compétences techniques.

De plus, la solution permettra à l’administrateur fonctionnel de définir de nouveaux gabarits par

un simple glisser/déposer au sein d’un configurateur de zones.


Le soumissionnaire présentera les fonctionnalités de sa solution permettant de générer et modifier

des gabarits de pages.

Gestion des types de pages 2.2.3.

Du point de vue fonctionnel, l’agencement de l’intranet est défini à partir de « types de pages »

composés par des éléments (blocs ou contenus) au sein d’un gabarit.


Les types des pages pourront être définis par l’agencement de ces différents éléments. Pour

certaines pages, ou parties de pages, les intranautes devront pouvoir eux-mêmes :

Modifier l’agencement des blocs composant la page en question ;

Ajouter et supprimer les blocs composant la page en question.

Chaque nouvel agencement de l’administrateur fonctionnel pourra donner lieu à la création d’un

nouveau type de pages. A titre d’exemple, il est attendu, au regard des blocs décrits ci-après, que la

page d’accueil puisse être constituée des éléments suivants :

Bloc présentant les dernières actualités

Bloc agenda

Bloc météo

Bloc permettant de visualiser les dernières photos publiées

Bloc permettant de lire la dernière vidéo publiée

Etc.


Le soumissionnaire présentera des exemples de type de pages lui semblant correspondre aux

attentes du CG63, ainsi que les fonctionnalités de gestion et de modification de ces pages.


Une page d’accueil de l’intranet et des pages d’accueil internes aux rubriques agrégeant des Blocs

(voir ci-après) devront être définis lors des spécifications.


Blocs composant les pages 2.2.4.

Les pages seront composées de différents blocs qui permettront d’afficher des données et services

provenant de la solution permettant de gérer l’intranet. Certains blocs afficheront également des

données et services provenant d’autres outils. Les blocs, et les données affichées dans les blocs,

pourront différer suivant les groupes d’utilisateurs et donc être imposés. Les blocs pourront

également être proposés aux utilisateurs à placer à leur convenance.

Les blocs types envisagés sont décrits dans chacun des modules fonctionnels ou dans le chapitre

dédié ci-dessous.

Un extrait, une accroche ou une présentation courte des contenus pourra automatiquement

remonter dans des blocs. Ils pourront être agencés de différentes manières dans les différentes

pages. Il devra être possible de choisir le nombre d’éléments à afficher dans chaque bloc et d’avoir

un lien pointant vers l ‘intégralité des éléments de la liste.

2.2.4.1. Blocs envisagés au lancement de l’intranet

2.2.4.1.1. Blocs « standards »

Blocs « Actualités »

Affichage des dernières actualités publiées dans une rubrique sélectionnée. D’un point de vue

graphique, ce bloc pourra être proposé en deux formats :

Liste d’actualités ;

Carrousel d’actualités.

Certaines actualités pourront être valorisées différemment dans cette liste, en fonction de leur

importance. (Ex. : pour le carrousel, l’administrateur pourra forcer l’ordre d’apparition des

contenus).

Blocs « Message d’urgence »

L’administrateur fonctionnel aura la possibilité de diffuser un message d’urgence de manière

ponctuelle et limitée dans le temps. Lorsqu’il sera activé, ce bloc prendra toute la largeur de la page

d’accueil et s’affichera au-dessus des autres informations. Son texte pourra être statique ou défilant.

Blocs « sondage »

Une vue sur le sondage en cours pourra être proposé par exemple sur la page d’accueil principale ou

dans toute autre partie du site intranet.

Blocs « Agenda »

Affichage des différents évènements de la collectivité sous forme de calendrier avec la possibilité

d’être redirigé sur le détail de l’évènement après avoir cliqué dessus. Chaque évènement sera

associé à une thématique, et pourra avoir une couleur prédéfinie pour faciliter sa reconnaissance. Il

sera possible d’utiliser le bloc en filtrant les évènements par thématique pour n’en afficher que

certains.


Bloc « Quoi de neuf »

Affichage d’un texte défilant de brèves d’actualité avec lien vers la ressource. Ce bloc sera refermable

par les agents ayant lu les brèves. Cette fermeture devra être persistante jusqu’à ce que de nouvelles

brèves fassent leur apparition.

Bloc « Nombre de personnes connectées »

Affichage du nombre de personnes connectées et du nombre de personnes actives sur l’intranet. Un

utilisateur est actif s’il a réalisé une opération sur l’intranet depuis moins 15 minutes. Ce bloc pourra

faire l’objet d’une intégration au niveau de l’en-tête.

Blocs « Liste de contenus »

Affichage d'une liste de contenus provenant d’une rubrique ou sous-rubrique spécifique.

Blocs « Contenu »

Affichage d’un contenu sélectionné dans l’intranet.

Blocs « Menu »

Affichage des rubriques et sous-rubriques sous forme de menu ou sous menu. Cela permettra par

exemple de pouvoir accéder à l’ensemble des contenus liés à un métier mais aussi d’afficher la

structure d’une rubrique. Ce bloc sera différent suivant le groupe auquel appartient l’agent connecté.

Blocs « Diaporama photos »

Affichage de diaporama photos avec une vignette représentant le thème du diaporama et une petite

description. L’utilisateur sera ensuite redirigé vers l’intégralité des photos du diaporama ou de la

base documentaire de photos.

Blocs « Vidéo »

Affichage d’une ou plusieurs vidéos mises à disposition dans l’intranet avec une vignette

représentant le sujet de chaque vidéo ainsi qu’une petite description. L’utilisateur pourra visionner la

vidéo directement dans le bloc. Il pourra, par un lien accéder à l’ensemble de la base documentaire

de vidéos.

Blocs « Ressources associées »

L’intranet sera en mesure de proposer un bloc permettant d’afficher la liste des liens, des contenus

ou documents associés à une publication. Cette liste devra être créée par l’utilisateur qui rédige la

contribution.

Blocs « Flux RSS »

Tout agent pourra configurer des blocs recevant des flux RSS provenant d’Internet et les disposer sur

les pages de l’intranet. Le flux RSS pourra, selon le souhait de l’agent, présenter la description de la

page avec ou sans capture d'écran. La configuration de ce bloc doit être simple et il doit être possible

de trier l’ordre d’affichage. Par ailleurs, la solution doit permettre de fusionner plusieurs flux RSS

dans un même bloc.

Blocs « Messages non lus »

L'administrateur fonctionnel pourra configurer des blocs indiquant le nombre de mails non lus de

l’agent connecté. L’agent sera en mesure de cliquer sur le bloc afin d’ouvrir sa messagerie

Groupwise.


Ce bloc récupérera les informations de la messagerie via des appels de services web SOAP (Cf.

annexe).

Blocs « Mes événements »

Le portail sera en mesure de proposer un bloc permettant d’afficher la liste des événements

auxquels l’intranaute aura répondu « présent » ou « peut-être ». Ces événements pourront provenir

d’espaces collaboratifs ou d’événements de l’intranet.

Blocs « Petites annonces »

Le portail sera en mesure de proposer un bloc permettant d’afficher la liste des 10 dernières

annonces parues dans l’application de gestion de « Petites annonces » développée par la DSI. Les

informations affichées sont récupérées directement dans l’application (Cf. annexe).

Blocs « HTML »

Le portail sera en mesure de proposer un bloc permettant de rentrer du code HTML. Ce bloc ne sera

pas limité en largeur et en hauteur. Il servira notamment à reprendre des cartes déjà codées (Ex. :

carte interactive des districts, écrans TV dans les étages de l’hôtel du département, etc.). Le bloc

disposera de sa propre feuille de style pour pouvoir être personnalisé graphiquement.

L’administrateur fonctionnel pourra saisir du HTML, du CSS et du javascript au sein de ce bloc.

Blocs « S’abonner / Se désabonner »

Le portail sera en mesure de proposer un bloc permettant de s’abonner et de se désabonner à une

newsletter de la solution prévue par le soumissionnaire (Cf. Newsletter).

Ce bloc contiendra également du texte afin d’indiquer de quelle mailing-list / newsletter il s’agit.

Blocs « Accès à mes applications »

L’administrateur fonctionnel pourra configurer un bloc de liens vers des applications web. Chaque

lien du bloc est soumis à une gestion de droit. Le lien peut-être affiché pour tous les agents, ou

uniquement pour les agents d’un groupe particulier. Au clic, l’application s’ouvrira au sein d’un

nouvel onglet du navigateur.

L’ensemble des applications web accessibles en SSO sont disponibles en annexe (Cf. Applications

accessibles depuis l’intranet SPIDI).

A titre d’exemple, le bloc du portail actuel se présente comme ci-dessous.


Informations techniques de la version actuelle :

- Les données de cette portlet sont stockées dans une table de base de données Oracle

- Les informations principales de cette table sont : l’URL, le nom d’affichage, le ou les groupes autorisés

Un transfert de compétence à la DSI doit être prévu pour permettre une autonomie pour des modifications futures de cette portlet (graphisme et fonctionnalités)

2.2.4.1.1. Blocs « avancés »

Blocs « Mes espaces collaboratifs »

Le portail sera en mesure de proposer un bloc permettant d’afficher la liste des espaces collaboratifs

dont un agent sera membre. Ce bloc sera affiché sur le profil d’un utilisateur. Il s’agit d’espaces

collaboratifs sous Novell Vibe. Chaque mention de l’espace collaboratif disposera d’un lien pour y

accéder.

La récupération de la liste des espaces collaboratifs se fera soit par une requête SQL ou par la lecture

d’un flux RSS.

Blocs « Remontée d’applications »

L’administrateur fonctionnel pourra configurer un bloc remontant des informations de différentes

applications. Voici les différentes méthodes qui devront pouvoir être utilisées pour la récupération

de ces informations :

o fichier texte formaté,

o requête SQL sur une base tierce

o flux XML + transformation XSL

o web service (SOAP, REST),

o page web ou partie de page (web clipping)

Des filtres seront proposés afin de filtrer les données source. Des mises en page différentes seront

proposées (tabulaire, graphique, formulaire, etc.)

La liste des remontées d’application est préconfigurée par l’administrateur. L’utilisateur choisit dans

les préférences du bloc, quelles remontées il souhaite voir apparaître. Les remontées d’applications

qui auront été lues devront proposer un style graphique différent (Ex. : passage de gras à non gras).

NB : Un transfert de compétence doit être prévu pour permettre à la DSI d’être autonome sur

l’ajout de nouvelles remontées d’information basées sur le même principe.


Les informations à remonter selon chaque application seront à étudier dans le cadre des ateliers de

spécifications. Vous trouverez en annexe l’état de la réflexion du CG63 pour les applications « « Frais

de déplacement », « Demandes de renfort » et « Intentions d’achat ».

Blocs « Portlets spécifiques »

Il doit être possible d’étendre les fonctionnalités du portail en développant ses propres blocs.

Ces blocs doivent être un moyen d’intégrer dans le portail une interaction avec un système tiers en

effectuant un développement spécifique. Depuis le code source de ces portlets spécifiques, il doit

être possible à minima les mêmes interactions que celles prévues dans le bloc « Remontée

d’applications » à savoir :

o fichier texte formaté,

o requête SQL sur une base tierce

o flux XML + transformation XSL

o appel de web service (SOAP, REST),

o page web ou partie de page (web clipping)

Le soumissionnaire décrira dans son offre le socle technique sous-jacent et les compétences requises

pour développer ses propres blocs. Dans le développement des blocs, on doit disposer d’un accès

simplifié (API) aux informations contextuelles du portail (user, login, groupe, profils…).

Lorsque la création de ces portlets spécifiques est fortement intégrée dans l’outil via des assistants

de création par exemple, il devra le préciser dans son offre.

NB : Un transfert de compétence doit être prévu pour permettre à la DSI d’être autonome sur

l’ajout de nouveaux blocs.


Le soumissionnaire présentera la réponse technique qu’il compte utiliser pour répondre au besoin de

chaque bloc. Il précisera également si ces éléments sont inclus dans son offre standard ou s’ils

nécessitent un développement spécifique.


L’ensemble des blocs listés dans « Blocs envisagés au lancement de l’intranet » devront être

configurés et opérationnels au lancement de l’intranet.

Pages à destination d’une population spécifique 2.2.5.

L’outil doit permettre de créer des groupes de pages ou rubriques accessibles uniquement à

certaines populations. Ces rubriques disposeront de leur propre arborescence. L’administrateur

fonctionnel pourra utiliser l’ensemble des fonctions prévues dans l’intranet pour gérer ces pages.


Ces rubriques correspondent à plusieurs cas d’usage :

- Pour usage interne

L’accès à ces rubriques pourra être restreint à un groupe de personnes comprises dans

l’annuaire du CG63. Ces rubriques posséderont leur propre arborescence. Les gabarits et

types de pages pourront être les mêmes que ceux utilisés pour l’intranet ou être de

nouveaux.

- Pour usage en extranet

L’accès à ces rubriques pourra être autorisé à des personnes identifiées ou non

comprises dans l’annuaire des agents du CG63.

- Pour sites internet

L’accès sera ouvert à tout public sans autorisation. Néanmoins une authentification

pourra être requise pour l’accès à certains contenus ou sous-rubriques. Ces pages

peuvent être disponibles en tant que telles sur internet, ou destinées à être intégrées

sur un site internet tiers sous différentes formes (iFrame, flux RSS, WebServices…). Dans

la majorité des cas, l’arborescence de ces pages ne sera pas intégrée à celle du portail

(nouveau site).

- Pour publication de ressources en ligne

La solution doit permettre de mettre en ligne une ressource de l’intranet sur internet

sans duplication de la ressource. Exemple : mise à disposition de l’organigramme interne

du CG63 sur le site institutionnel. Un dispositif de sécurité doit être mis en place pour

empêcher l’accès aux autres ressources de l’intranet.

En cas de besoin, ces pages ou ressources doivent pouvoir être mises en ligne sous une URL

différente de celle du portail intranet, et l’accès aux autres ressources du portail via cette URL doit

être interdit.


Le soumissionnaire présentera la méthode technique pour répondre au besoin des pages à

destination de populations spécifiques. Il alertera le pouvoir adjudicateur sur les limites et

contraintes inhérentes à sa méthode.

2.3. Gestion des contenus

Types de contenus 2.3.1.

Chaque contenu est composé de différents champs. Tous les contenus d’un même type sont

composés des mêmes champs (ex : tous les contenus événements sont composés des champs « titre,

date, lieu, etc. »)


Lors de l’édition, le publicateur remplit les différents champs d’un contenu. On pourra distinguer des

champs obligatoires et d’autres facultatifs. Si un des champs obligatoires n’est pas rempli, le contenu

ne peut être publié.

Chaque type de contenu pourra avoir un rendu différent. Par exemple, les actualités seront affichées

de manière chronologique et les FAQ de manière thématique et alphabétique avec une table des

matières.

Types de contenus identifiés : Contenu libre, Articles, Actualités, Evénements, Fiches contact, Avis de

concours, Formulaires, Trombinoscope, Diaporama.

D'autres types de contenus pourront être définis lors de la phase de spécification.

2.3.1.1. Configuration des types de contenus

La solution proposera une bibliothèque de types de contenus qui auront été proposés par le titulaire

et complétés les cas échéant par les demandes ci-dessus formulées par le CG63 et lors de la phase de

spécification.

L’administrateur pourra créer des types de contenus et faire évoluer les types de contenus existants

pour rajouter, supprimer, modifier des champs.


Le soumissionnaire présentera son outil de gestion des types de contenus ainsi que les paramétrages

associés.

2.3.1.2. Règles de saisies

Il sera possible de définir des règles de saisie pour certains champs. Exemple : pour le champ

« date », la convention de saisie pourra être : jj/mm/aa. Une saisie ne respectant pas le format

prérequis ne sera pas acceptée et un message d’information devra préciser la convention de saisie à

respecter.

Pour certains champs, un système d’auto-complétion devra être présent. Ce système pointera sur

le thésaurus défini par le Conseil général

Les différentes règles de saisies seront à déterminer lors de la phase de spécification fonctionnelle.


Le soumissionnaire présentera la gestion des opérations demandées ci-dessus. Le cas échéant, si sa

solution permet une gestion plus fine il la précisera.


Au lancement de l’intranet, l’auto-complétion via le thésaurus du CG63 devra être en état de

marche.


2.3.1.3. Types de contenus spécifiques

Evènements

L’outil permettra d’alimenter un agenda, qui sera composé de contenus du type « évènement »

L’affichage de ces contenus pourra se faire sous forme de calendrier ou de liste. Chaque évènement

sera associé à une thématique. Il sera possible de filtrer les évènements par thématique pour n’en

afficher que certains.

Le type de contenu « événement » sera constitué d’un titre, d’une date de début et d’une date de

fin, d’un lieu, d’un référent (le publicateur), d’une possibilité d’insérer une photo voire une vidéo,

d’un descriptif et de mots-clés.

La recherche d’un évènement pourra se faire soit par des filtres prédéfinis tels que « Demain », « la

semaine prochaine », « les événements internes », les « événements externes », etc. Les

« événements » constituant un type de contenu ils seront indexés par le moteur de recherche et

pourront être filtrés dans la recherche générale.

Les évènements de l’agenda pourront être affichés sur différents pages de l’intranet via l’utilisation

des blocs tels que décrit dans le chapitre consacré (« Blocs agenda »).


Le soumissionnaire présentera le fonctionnement du module agenda proposé ainsi que les liens avec

les fonctionnalités et pages du site intranet. Il présentera également les fonctionnalités

d’administration associées.

Questions / réponses

Chaque utilisateur pourra publier une question, éventuellement associée à des thématiques. Chaque

question pourra faire l’objet d’une ou plusieurs réponses, qui seront gérées comme des

commentaires. Le publicateur de la question pourra également commenter sa propre question afin

de répondre aux autres utilisateurs. Le publicateur de la question, et les administrateurs, pourront

clôturer la question dès qu’ils le souhaiteront.

Comme pour tous les contenus de l’intranet, il sera possible de modérer les questions / réponses

depuis le back-office.


Le soumissionnaire présentera des exemples de réalisations similaires ou ses propositions de

fonctionnalités avec maquettes s’il n’a pas encore réalisé ce type d’intégration. Les fonctionnalités

offertes en front-office et en back-office devront être précisées.

Exigence secondaire


Petites annonces

Un module de petites annonces est souhaité. Chaque utilisateur pourra proposer une offre (Ex. :

service de covoiturage, vente ou échange d’objets) au sein de thématiques. Seul l’administrateur

peut gérer les thématiques proposées. Chaque annonce pourra faire l’objet de plusieurs

commentaires. Un système de réponses avec indentation devra être présent. Le publicateur de

l’annonce, et les administrateurs, pourront supprimer l’annonce dès qu’ils le souhaiteront. Les

contributeurs d’annonce qui n’auraient pas supprimés leur annonce au bout d’un temps donné

recevront automatiquement un mail les invitant à la supprimer. Ce temps imparti sera identique à

l’ensemble des intranautes et modifiable par l’administrateur fonctionnel.



fonctionnalités avec maquettes s’il n’a pas encore réalisé ce type d’intégration. Les fonctionnalités

offertes en front-office et en back-office devront être précisées.

Contenus multimédias

Des fonctions de gestion des contenus multimédias devront être mise en place afin de pouvoir gérer

des images, sons et vidéos dans les formats les plus courants (JPEG, JPEG2000, GIF, PNG, TIFF, SVG,

WAV, MP3, AVI, MPEG, MOV, FLV). Ces médias seront redimensionnés automatiquement et des

vignettes seront créées pour chacun. Ils seront affichés sous forme de planche diapo et de

diaporama. Les fichiers audio et vidéo pourront être lus directement dans l’intranet. Il sera possible

de proposer aux contributeurs la possibilité de copier-coller un code html permettant d’encapsuler

un média dans une page web.

Ces contenus multimédias pourront utilisés dans le cadre de :

Pièce-jointe d’un autre type de contenu ;

Intégré au sein-même d’un autre type de contenu.


Le soumissionnaire présentera différents exemples de contenus, dans la mesure du possible en

phase avec les attentes exprimées ci-dessus.

Formulaires

L’intranet actuel dispose d’un niveau avancé dans les services proposés via des formulaires. Il

conviendra donc de proposer un gestionnaire de formulaires permettant de créer, modifier,

dupliquer et supprimer des formulaires.

Pour chaque formulaire sont définis :


La liste et la nature des champs : date, texte, email, case à cocher, bouton radio, liste

déroulante, fichier…

Le caractère obligatoire ou facultatif des champs

L’assistance à la saisie :

Masques de saisie pour faciliter la saisie des champs (Ex. : JJ-MM-AAAA pour les dates) ;

Calendrier pour les champs de type date ;

Règles de saisie (Ex. : 10 chiffres pour les numéros de téléphones, présence d’un symbole

« @ » dans les adresses mail, etc.) ;

Avertisseurs de mauvaise saisie lorsque c’est le cas ;

Notifier un ou plusieurs destinataires par mail lors du remplissage d’un formulaire.

Les fonctionnalités proposées :

Formulaire de saisie des données ;

Recherche de données avec critères de recherche. Tous les champs du formulaire doivent

pouvoir être utilisés en tant que critère de recherche ;

Affichage du résultat de recherche en mode tableau avec tri possible des colonnes ;

Affichage du résultat de recherche en mode formulaire avec bouton « précédent » /

« suivant » pour naviguer dans les résultats;

Suppression des données ;

Saisie des données en mode tableau (grille de saisie).

Enfin, nous souhaitons que la source de données (en lecture et écriture) de ces formulaires puissent

être une base de données Oracle (ou MySQL) tierce, différente de celle de la solution.

Compte-tenu de la multiplicité des formulaires présents et à venir dans l’intranet, la DSI souhaite

être autonome sur la génération de ces formulaires. Un transfert de compétence devra être réalisé

pour aider à la construction des formulaires.

A l’initialisation du portail, les formulaires ci-dessous devront être implémentés.

Formulaire de contact

Dans sa version actuelle, ce formulaire envoi un email à [email protected] avec la demande de

l’intranaute. Lors de la phase de spécification, les fonctionnalités à mettre en place seront précisées.

mailto:[email protected]


Formulaire pour la commande de chèques

Les fonctions prévues devront permettre de créer, mettre à jour, supprimer et rechercher des

données issues d’une base de données existante.

Formulaire pour les chèques en erreur ou annulés




Formulaire pour les chèques à détruire


données issues d’une base de données existante. A noter que dans ce formulaire, la saisie se fait en

mode tableau.

Formulaire pour les chèques en erreur ou annulés



Formulaire de modification de la typologie de la nomenclature GF

Les fonctions prévues devront permettre la mise à jour, et la recherche de données issues d’une base

de données existante.


Seul le champ "Type de mouvement" est modifiable

Formulaire de gestion des informations à caractère confidentiel

Les fonctions prévues devront de créer, mettre à jour, supprimer et rechercher et lister des données

issues d’une base de données existante.

Formulaire de gestion de la liste de liens de sites internet externe pour la DGSAS

Les fonctions prévues devront de créer, mettre à jour, supprimer, rechercher et lister des données

issues d’une base de données existante.

Formulaire d’ajout d’un lien


Affichage de la liste des sites

NB : mise en page particulière et liens cliquables

Les formulaires ci-dessous sont donnés à titre indicatif

Formulaire de reports convertis en BI publisher



Formulaire de test des applications sur Seven





Le soumissionnaire présentera différents exemples de formulaires déjà réalisés et la solution

technique qu’il prévoit d’utiliser pour créer ces différents formulaires et répondre aux besoins

demandés. Il fournira la documentation standard associée à la fonctionnalité de génération de

formulaires.


Différents types de contenus seront à implémenter dans la solution dès sa mise en œuvre. Ces types

de contenus seront définis lors de la phase de spécification. Les contenus à implémenter au minima

sont les contenus : Contenu libre, Articles, Actualités, Evénements, Fiches contact, Avis de concours,

les Questions/Réponses, Petites annonces, Contenus multimédias, Trombinoscope et l’ensemble des

Formulaires décrits comme devant être implémentés à l’initialisation de l’intranet.. La liste de leurs

champs ainsi que leur rendu dans l’intranet sera défini en phase de spécifications.

Fonctionnalités d’administration et d’édition 2.3.2.

La solution devra séparer le contenu de la présentation.

2.3.2.1. Accès aux interfaces de contribution en Front Office

Exigence secondaire

Pour les contributeurs, ayant pour rôle d’ajouter/de modifier des contenus dans une rubrique

donnée, la contribution se fera sur le Front Office. La contribution doit pouvoir se faire de manière

simple et intuitive.



Le prestataire s’attachera à présenter (avec copie(s) d’écran) l’ergonomie et la simplicité d’utilisation

de la solution proposée.

2.3.2.2. Accès aux interfaces de gestion en Back Office

L’accès aux interfaces de gestion se fait par un lien disponible sur le Front Office sur les pages où

apparaissent les publications. Dans le Back Office, seules les fonctions autorisées seront affichées aux

profils y accédant. La navigation ainsi que les fonctionnalités de gestion doivent être simples et

intuitives.


Le prestataire s’attachera à présenter (avec copie(s) d’écran) l’ergonomie et la simplicité d’utilisation

de la solution proposée du côté du Back Office.

2.3.2.3. Ubiquité des contenus

Un même contenu pourra être disponible dans plusieurs rubriques sans duplication du contenu. Les

gestionnaires de contenus pourront connaître les différents emplacements de diffusion des

contenus. Les contributeurs pourront choisir les champs de la publication à afficher suivant les

duplications.

L’ensemble des contenus seront rangés de manière arborescente. Des tris pourront être opérés sur

la date de création, sur le type de contenus et sur le titre du contenu.

Exigence secondaire

La mise en page du contenu sera différente suivant la rubrique de publication.


Le prestataire illustrera (avec copie(s) d’écran) la manière de multi-positionner des contenus avec la

solution proposée.

2.3.2.4. Interface WYSIWYG

La publication est rédigée dans un mini-Word mettant à disposition les outils de base de mise en

forme (G, i, s, liens, insertion d'images et de documents, …). L’éditeur permettra d’effectuer des

Copier-coller depuis le logiciel Word de la suite Office, puis de supprimer la mise en forme d’origine.

L'intégration de fichiers (images, PDF etc.) dans le contenu se fait en une seule étape. Les liens

pointeront directement vers le document de l’espace documentaire (il n’y aura pas de duplication

des ressources). Cela signifie que même si la publication est publique et qu’elle fait appel à un

document privé, les droits appliqués à celui-ci resteront les mêmes, c'est-à-dire privés.

L’interface proposera de boutons d’éditions de contenus définis en amont par la MOA et auxquelles

l’ensemble des contributeurs auront accès. Il n’y aura pas de différenciation dans les fonctions de

mises en forme selon les rôles. Cependant, l’administrateur fonctionnel sera en mesure de faire

évoluer ces fonctionnalités. Les styles accessibles sont définis par la feuille de style. Par exemple,


l'affectation "titre 1" à un mot permet automatiquement d'afficher ce texte avec le style employé par

le site.


Le soumissionnaire présentera la fonctionnalité WYSIWYG de sa solution.

2.3.2.5. Base documentaire de fichiers

Les contributeurs auront la possibilité de gérer des dossiers de fichiers (Ex. : document word, excel,

etc.). Le rangement de ces fichiers pourra être arborescent ou lié à des mots-clés.

Une interface web permettra un dépôt rapide et sans contraintes de plusieurs documents. De plus,

la solution permettra à l’administrateur fonctionnel de déposer de nouveaux documents par un

simple glisser/déposer.

Des fiches de qualification seront créées pour pousser à une utilisation plus forte des métadonnées.

Ainsi, au chargement d’un document, une fenêtre demandera à rentrer des champs à définir en

atelier de spécifications. La liste des métadonnées sera définie par l’administrateur fonctionnel.

Chacune d’entre elles pourra revêtir un caractère obligatoire ou facultatif. Les métadonnées

pourront provenir du thésaurus ou être des mots-clés.

Les documents pourront d’ailleurs être multi-positionnés. Pour ce faire, les administrateurs

fonctionnels auront la possibilité de définir plusieurs arborescences. Pour chaque document, les

utilisateurs devront pouvoir voir la liste des différents dossiers dans lesquels il est contenu. Pour

chaque document, les publicateurs devront pouvoir la liste des pages dans lesquelles il est placé.

Exigence secondaire

Pour les contributeurs, il sera possible d’importer des dossiers compressés au sein de la base

documentaire. Une décompression automatique sera réalisée afin d’intégrer les contenus (dossiers

et documents) précédemment compressés.

Exigence secondaire

Les intranautes pourront croiser plusieurs plans de classement pour faciliter la recherche de

contenus.


Le soumissionnaire présentera les fonctions permettant de gérer une galerie de documents dans le

Back Office. Il présentera l’ensemble des fonctionnalités envisagées et permises par la solution

proposée.

2.3.2.6. Base documentaire de photos

Les contributeurs auront la possibilité de gérer des dossiers d'images. Le rangement de ces images

pourra être arborescent ou lié à des mots-clés.


Les images déposées dans cette base documentaire pourront être redimensionnées avant leur

publication dans un contenu. En outre, la solution devra pouvoir en compresser le poids.

Des diaporamas pourront être créés de manière libre (choix des images, durée d’affichage, etc.). Les

formats d’images acceptés dans la base documentaire de photos devront être définis lors des

spécifications fonctionnelles. Une attention particulière sera portée au respect des normes

d’accessibilité.

Ces photos pourront utilisés dans le cadre de :

Pièce-jointe d’un autre type de contenu ;

Intégré au sein-même d’un autre type de contenu.

Un bloc « Diaporama photos » permettra d’intégrer des diaporama spécifiques dans les différentes

pages du site (voir chapitre « Blocs envisagés »).


Le soumissionnaire présentera les fonctions permettant de gérer une galerie d’images dans le Back

Office et le rendu en Front Office. Il précisera également les limites de poids obligatoires ou

conseillées.

2.3.2.7. Base documentaire de vidéos

Gestion de la base documentaire de vidéos

Les contributeurs auront la possibilité de gérer des dossiers de vidéos. Chaque vidéo pourra être

rangée au sein d’une arborescence ou associée à des mots-clés afin de faciliter leur recherche. Un

titre et un descriptif court pourra être proposé. Afin de ne pas nécessiter le recours à un lecteur sur

les postes de travail des collaborateurs, l’intranet devra proposer son propre player vidéo.

Un bloc « vidéo » permettra d’intégrer des petites vidéothèques spécifiques ou bien une vidéo

unique dans les différentes pages du site (voir chapitre « Blocs envisagés »).

Intégration de vidéos dans une publication

Le player vidéo pourra être intégré dans un contenu pour agrémenter une publication. Le player sera

également mis à disposition du lecteur afin de pouvoir consulter la vidéo directement dans la

publication.

Les critères de format des vidéos seront définis lors des spécifications fonctionnelles. Une attention

particulière sera portée au respect des normes d’accessibilité.


Le soumissionnaire présentera les fonctions permettant de gérer une galerie de vidéos dans le Back

Office et le rendu en Front Office.


2.3.2.8. Planification des publications

Les contributeurs disposeront de plusieurs options quant à la publication de leurs productions.

Celles-ci pourront être publiées de manière instantanée lors de la validation du contenu. Il sera

également possible de planifier dans le temps les publications. Pour ce faire, le contributeur choisir la

date de publication, pourra modifier les dates prévues, et annuler la planification. Les publications

soumises à validation, dont la planification de publication serait antérieure à leur validation, ne

seront publiées qu’au moment de la validation. Les publications disposeront également d’une date

de limite dé-publication ayant pour effet une dé-publication.

2.3.2.9. Fonction d’aperçu avant publication

La solution devra proposer une fonction permettant la prévisualisation des contenus, accessible tout

au long de la rédaction du contenu. Le publicateur, et/ou le validateur pourront consulter la

publication dans l’environnement final avant publication. Notamment, les documents attachés à des

publications tels que des vidéos, des images ou encore des pdf, pourront être prévisualisés dans les

mêmes conditions qu’en mode « publié ».

Exigence secondaire

La solution permettra au valideur de disposer d’une URL pointant directement vers la publication

sous le format aperçu. Par un simple envoi de mail, cette méthode permet de faciliter la tâche de

validation.


Le soumissionnaire présentera ses fonctionnalités de prévisualisation avec des exemples intégrant

des contenus multimédias. Il précisera la disponibilité de cette fonctionnalité dans le processus de

publication.

2.3.2.10. Lier des ressources

Il sera possible de lier plusieurs ressources entre elles. La liste des liens des contenus ou des

documents associés à une publication sera affichée via l’utilisation d’un bloc (voir description du Bloc

« Ressources associées » dans le chapitre « Blocs envisagés »).

2.3.2.11. Gestion des mots-clés/tags

Les contenus pourront être rattachés à des mots clés visant à faciliter leur recherche. Ainsi, pour

chaque contenu, il sera possible d’attacher un ou plusieurs mots clés. Ces mots clés seront à définir

par le publicateur. Certains mots clés seront également suggérés en cours de frappe (en fonction des

mots clés les plus utilisés par les publicateurs).

Les objectifs de l’utilisation de ces mots-clés sont :

D’améliorer les résultats des recherches ;

De permettre des recherches transversales par tags.


2.3.2.12. Versionning des publications

Il sera possible de récupérer les versions précédentes d’une publication. Un historique complet des

différentes versions et de leurs contributeurs sera disponible. Cet historique permettra de republier

une ancienne version du contenu. L’historique des versions devra pouvoir être purgée par les

contribruteurs et administrateurs fonctionnels.

Fonctionnalités accessibles aux lecteurs de contenus 2.3.3.

Des fonctions participatives seront disponibles et activables par le contributeur sur chaque contenu.

2.3.3.1. Services en ligne

Un système de formulaire en ligne devra être proposé aux contributeurs. Ces formulaires auront

pour but de développer les services en ligne au sein de l’administration.

Chacun des formulaires disposera d’une ou plusieurs adresses mail de destination. Un accusé de

réception sera proposé à l’intranaute ayant rempli le formulaire. Les données issues du remplissage

des formulaires seront disponibles à l’export (sous format .CSV ou .XLS) et au sein d’un tableau de

bord pour les contributeurs.

Ces formulaires pourront être rangés de manière arborescente.

Les agents apportant des services disposeront d’une interface agrégeant les demandes de services.

Ces agents pourront déléguer la gestion de la demande.

Les intranautes disposeront d’une vue consolidée permettant de connaître l’état de leur demandes

en cours.

Les contributeurs pourront affecter et modifier l’état de la demande formulée (Ex. : traitement en

cours, traité). L’ensemble des formulaires remplis auront par défaut l’état « A traiter ». Au sein de ce

tableau de bord, des vues consolidées seront disponibles (Ex. : tous les formulaires Lambda remplis

mais non répondus). Enfin, il sera possible d’effectuer des opérations sur plusieurs formulaires (Ex. :

passer plusieurs formulaires sous l’état « Traité »).


Le soumissionnaire présentera des exemples de réalisations similaires. Les fonctionnalités offertes en

front-office et en back-office devront être précisées.


Au lancement de l’intranet, au moins 10 services en ligne seront disponibles. Les soumissionnaires

devront prendre en compte ce chiffrage dans l’élaboration de leurs ateliers de spécifications.

2.3.3.2. Sondage

Le CG63 souhaite disposer d’une fonctionnalité de sondage simple et intuitive permettant de saisir

une ou plusieurs questions. Chacune de ces questions proposera plusieurs réponses possibles. Une

fois le sondage complété et validé, une vue des résultats sera proposée. Les résultats seront

exportables sous format *.csv ou *.xls pour une analyse plus fine.


Un bloc « sondage » devra pouvoir être inséré dans les différentes pages et espaces du site (voir

chapitre « Blocs envisagés »).

A noter que l’ensemble des réponses au sondage devront être anonymes.


Le soumissionnaire présentera des exemples de fonctionnalités de sondage qu’il a pu implémenter. Il

présentera également les fonctionnalités d’administration associées. Dans la mesure du possible, ce

service doit utiliser les fonctionnalités natives de la solution proposée par le soumissionnaire.

2.3.3.3. Notation

A la publication d’un contenu, le publicateur choisit s’il souhaite activer ou non le système de

notation. Si c’est le cas, il sera possible de noter les contributions. Les intranautes ne pourront noter

les publications qu’une seule fois. Ils auront en revanche la possibilité de modifier leur note. La note

affichée représentera la note moyenne de l’ensemble des notes reçues sur la publication.

2.3.3.4. Recommandation

Il sera possible de recommander une lecture à un intranaute ou à un groupe de personnes entier.

Recommandation à un intranaute :

Cette recommandation sera outillée via une alerte. La personne qui souhaite recommander une

lecture disposera d’une zone pour choisir son destinataire et d’une zone pour écrire un message. Au

remplissage de la zone du destinataire, un système d’auto-complétion proposera les membres

disposant d’un accès à l’intranet.

Recommandation à un groupe de personnes :

Cette recommandation sera outillée via une remontée dans un flux de contenus. Les agents pourront

recommander des lectures à leur propre service, leur direction, ou l’ensemble de l’intranet.

NB : Cette fonction est prévue pour l’ensemble des intranautes (Cf. rôle lecteur). Il conviendra donc

de proposer une interface en front-office pour faciliter leur contribution.

2.3.3.5. Abonnement

L’ensemble des contenus, publications et rubriques proposeront un bouton d’abonnement. Ainsi, à

chaque nouveauté ou modification, les intranautes abonnés recevront une alerte (Cf. le paragraphe

Alertes).

2.3.3.6. Favoris

Sur chaque page, un lien « Ajouter à mes favoris » permettra à l’utilisateur d’ajouter la page à ses

favoris. Sur la page d’accueil l’utilisateur retrouvera la liste de liens et pourra les modifier ou

supprimer directement en cliquant sur une icône à côté du favori. L’outil devra permettre d’organiser

et de gérer ces favoris (Ex. : dans des dossiers).


Le soumissionnaire présentera des exemples de réalisations similaires. Il présentera en outre les

modalités pour répondre au besoin décrit.


2.3.3.7. A lire plus tard

Sur chaque page, un lien « A lire plus tard » permettra à l’utilisateur d’incrémenter ses alertes avec

un lien pointant vers la ressource en question. Au clic sur l’alerte, celle-ci sera considérée comme lue.


Le soumissionnaire présentera des exemples de réalisations similaires. Il présentera en outre les

modalités pour répondre au besoin décrit.

2.3.3.8. Signalement d’obsolescence

Via un bouton du type « Ce contenu est peut être obsolète », les intranautes pourront émettre une

alerte sur laquelle ils pourront indiquer pourquoi ils pensent que le contenu est obsolète Le

contributeur qui a publié le contenu en question recevra alors une alerte. Celle-ci sera composée

d’un lien direct vers le contenu, du nom de la personne qui a communiqué cette alerte et du

message indiquant les raisons de l’alerte.

2.3.3.9. Flipbook pdf

Les publications du CG63 pourront être directement publiées en ligne dans un format *.pdf.

L’utilisation d’un système tel que flipbook (livre en ligne pouvant être feuilleté) devra être possible.

Cette interface devra être conforme aux règles d'accessibilité, de manière à permettre en particulier

son utilisation au clavier. De manière alternative, ce type de flipbook posant souvent des difficultés

importantes en matière d'accessibilité, il est nécessaire de permettre le téléchargement du

document pour sa consultation dans un logiciel client.


Le soumissionnaire présentera des exemples de réalisations intégrant ce type d’outils en précisant

les fonctionnalités associées tant en front-office qu’en back-office.

2.3.3.10. Newsletter

Les contributeurs du CG63 pourront créer des newsletters :

En intégrant des publications de l’intranet. Le contenu sera directement intégré dans le

corps du message. La newsletter deviendra alors consultable sans connexion au portail. Le

publicateur pourra modifier le contenu de la publication source pour en adapter le discours.

Et en rédigeant des contenus libres.

Au sein de chaque billet de newsletter, un lien d’accès au système d’abonnement/désabonnement

doit être disponible. Les contributeurs pourront configurer facilement la mise en forme graphique de

ces newsletters (Ex. : en-tête, pied de page, etc.). A chaque newsletter doit être associée une liste de

diffusion composée d’utilisateurs ou groupes du portail. Cette liste est administrable. La liste des

inscrits à chacune des newsletters sera accessible et téléchargeable en back-office. L’envoi des

newsletters pourra être planifié dans le temps. Chacune des newsletters sera accessible en mode

web et via une URL propre afin de pouvoir créer des historiques.

Exigence secondaire

La solution permettra de disposer de statistiques d’ouverture des newsletters.



Le soumissionnaire présentera des exemples de réalisations intégrant une newsletter ainsi que les

choix techniques pour répondre à ce besoin.

2.4. Fonctions transverses

Moteur de recherche 2.4.1.

Le moteur de recherche doit pouvoir indexer tous les contenus (données et métadonnées) proposés

dans la gestion de contenu (articles, commentaires, description des images et vidéos, questions et

réponses, profils utilisateur, etc.).

Le moteur de recherche doit respecter les droits appliqués aux contenus. Un utilisateur n’ayant pas

les droits adéquats, ne doit pas trouver des contenus non publiés ou auxquels il ne devrait pas avoir

accès. Cette gestion des visibilités est d’une importance capitale pour le CG63 compte tenu de la

création de pages spécifiques (Cf. Pages à destination d’une population spécifique).

La recherche doit être insensible aux majuscules, minuscules et aux accents. La solution pourra

indexer du contenu plein texte, des métadonnées et des titres, ainsi qu’indexer les métadonnées des

contenus de type « non documentaire », tels que des vidéos ou des images.

La solution devra indexer également le contenu des documents (Word, PDF, …) pour participation

aux recherches.

Il doit être possible de rechercher sur un type de contenu spécifique mais également sur tous les

types de contenus en même temps. Une restriction sur la date doit également être permise.

Le moteur de recherche pourra déterminer la pertinence des résultats d’une recherche au travers de

critère comme le nombre d’occurrences des mots clefs.

Classement des résultats de recherche

Les résultats de recherche doivent pouvoir être triés par pertinence et date. Les résultats de

recherche peuvent être affinés à l’aide de filtres (facettes) proposés automatiquement. Sont

notamment visés des filtres tels que : type de contenu, nom du publicateur, rubrique, mots-clés, date

de publication.

Pour chaque résultat, il sera à minima affiché : le titre, un extrait de texte contenant les mots clefs

recherchés qui seront mis en valeur, l’emplacement, le type de contenu, la date et l’auteur du

contenu. Le clic sur le titre permettra l’ouverture du contenu.

Le moteur de recherche devra être capable de proposer des requêtes plus fructueuses lorsque les

résultats de la recherche sont peu nombreux.

Lorsque le type de contenu le permet (à minima pour les images et vidéos) une miniature sera

affichée dans la liste des résultats de recherche.

Exigence secondaire


La solution permettra de gérer des synonymes au sein du moteur de recherche. Cet ensemble de

mots définis en phase de spécifications permettra d’afficher les résultats de la requête demandée,

ainsi que de ses synonymes. Cette fonction devra être activable/désactivable par les administrateurs

fonctionnels. Ils pourront également ajouter/modifier/supprimer les mots de cette liste de

synonymes.


Le soumissionnaire présentera le fonctionnement de son moteur de recherche, tant sur l’indexation

que sur les paramètres associés. Il présentera également les possibilités de filtrage proposées en

amont ainsi que les possibilités de classement des résultats de recherche (en aval).


Lors de la livraison, le moteur de recherche devra être opérationnel et avoir indexé l’ensemble des

contenus en respectant les droits d’accès des utilisateurs sur ces contenus. L’ensemble des filtres

(facettes) et des options permettant d’améliorer la pertinence du moteur de recherche devront

également avoir été configurés. La présentation des résultats de recherche pourra être personnalisée

si la présentation native n’est pas identifiée comme satisfaisante lors de la phase de spécification.

Alertes 2.4.2.

Chaque utilisateur pourra choisir, modifier et supprimer ses sources d’abonnements. Les alertes

concerneront :

la publication d’un nouveau contenu de l’intranet (information poussée par le

contributeur) ;

la publication d’un nouveau contenu au sein des espaces collaboratifs Novell Vibe ;

la publication d’un contenu dans une rubrique à laquelle l’intranaute s’est abonné

(information tirée par le lecteur) ;

la publication d’une recommandation de lecture par quelqu’un (information poussée par un

intranaute visiteur) ;

le choix de lire plus tard une publication jugée intéressante (information tirée par le lecteur).

La récupération de la liste des nouveaux contenus publiés au sein des espaces collaboratifs se fera

soit par une requête SQL ou par la lecture d’un flux RSS.

Sur chacune de ses sources, il pourra choisir le canal d’alerte : compteur et/ou e-mail. En effet, les

alertes auront la possibilité d’être :

agrégées au sein d’un compteur d’alertes (type « Facebook » ou « mail »). Il sera possible de

cliquer sur les informations remontées et l’utilisateur sera amené directement sur la page

concernée.

ou d’être envoyées par e-mail. Chaque alerte envoyée par mail aura un message prédéfini

mais il sera possible de le changer ou d'ajouter un message personnalisé. S’il choisit l’email, il

pourra définir la fréquence de réception de ces alertes (instantané, quotidienne, ou

hebdomadaire).


L’ensemble de ces configurations (Ex. : choix du canal mail ou compteur, liste des rubriques

auxquelles l’intranaute s’est abonné, etc.) devra être géré en un endroit unique, idéalement au sein

d’une page de préférences.



fonctionnalités avec maquettes s’il n’a pas encore réalisé ce type d’intégration. Le soumissionnaire

présentera également le fonctionnement prévu et les modalités techniques pour répondre au

besoin.

Annuaire 2.4.3.

La solution permettra de proposer un annuaire des collaborateurs de la collectivité. Cet annuaire

sera composé d’une fiche profil par agent.

Cette fiche sera composée à minima des informations suivantes : civilité, nom, prénom, email

cliquable, direction, service, photos, téléphone, lieu de rattachement. Des champs libres seront

également proposés afin que les utilisateurs puissent indiquer leurs projets en cours ou expériences

passées.

Les champs principaux de cet annuaire, ainsi que la création des profils, seront synchronisés avec une

base de données Oracle intermédiaire gérée par la DSI (Cf. description de la base de données en

annexe).

Lien vers le profil de l’utilisateur

Sur l’intranet, à chaque fois qu’un collaborateur sera cité, automatiquement et dans le respect des

droits d’accès, son nom sera affiché sous forme d’un lien permettant d’accéder à son profil

Le moteur de recherche indexera ces fiches profils et proposera une recherche filtrée uniquement

sur les profils.


Le soumissionnaire présentera le fonctionnement du module annuaire ainsi que les liens avec les

fonctionnalités et pages du site intranet. Il présentera également les fonctionnalités d’administration

associées.


L’annuaire devra contenir l’ensemble des agents de la collectivité ainsi que les informations définies

lors de la phase de spécification.


Version mobile de l’intranet 2.4.4.

Le CG63 ne dispose pas d’une flotte importante d’outils mobiles (huit tablettes pour les élus, une

centaine de smartphones pour l’encadrement). Néanmoins, les soumissionnaires devront indiquer

dans leur réponse les modalités pour que les agents puissent accéder à l’intranet via leur outil mobile

personnel et ceux du CG.

S’agissant des outils mobiles nous identifiions les terminaux équipés des systèmes d’exploitation

Appel iOs, Google Android, RIM BlackBerry, Microsoft Windows Phone.

S’agissant de la technique employée pour la fourniture de contenus vers les mobiles, nous

distinguons les approches :

- Site web développé spécifiquement pour les terminaux mobiles. L’utilisateur est re-routé

vers ce site lorsqu’il accède au portail depuis un terminal mobile.

- Site web à adaptation automatique de la mise en forme selon le terminal utilisé par

l’utilisateur (PC, téléphone ou tablette).

- Ou une application native spécifique à installer sur les périphériques mobiles.


Le soumissionnaire présentera les dispositifs natifs proposés par la solution utilisée pour répondre à

des accès et publications orientées « web mobile ».


3. Description des contraintes techniques Avant-propos : Les prestations d’installation et de mise en œuvre au sein du SI du Conseil général

du Puy-de-Dôme se font obligatoirement dans les locaux du Conseil général du Puy-de-Dôme.

3.1. Préambule

Attendus techniques de la solution

La solution retenue sera obligatoirement une solution :

Architecture n-Tiers (load balancing, serveurs d’applications, base de données)

Base de données (Oracle ou MySql ou SQL Server)

Hébergement sur environnement Vmware

Compatible avec la messagerie Novell GroupWise

Solution hébergée au Conseil général (de préférence SUZE, Windows )

Le futur prestataire devra mettre en place 3 environnements (test, pré-production, production)

Le paramétrage de l'environnement de pré-production sera repris automatiquement par le prestataire sur l'environnement de production (attendu obligatoire de l'offre).

Le candidat devra fournir dans sa réponse le descriptif de l’architecture technique de sa solution. Celle-ci devra s'intégrer dans l'existant décrit ci-après.

3.2. Fourniture des documentations Trois types de document sont à fournir par le titulaire :

La documentation de l’éditeur et du constructeur pour chaque composant intégré au

format électronique.

La documentation technique, les configurations serveurs, poste de travail, les procédures

d’installation spécifiques au contexte du Conseil général qui est rédigée par le prestataire.

Les manuels d’exploitation sur d’éventuelles procédures et traitements d’exploitation

Toute la documentation sera produite, adapté au contexte du Conseil général avec capture d’écran,

sous format électronique exploitable et modifiable par le Conseil général : format Word, Excel,

PowerPoint, Visio, ou compatible avec ces logiciels bureautiques.

La documentation fournie sera rédigée en français.

Le conseil général prendra à sa charge la reproduction en nombre des dits documents si nécessaire/

A l’admission des prestations, le Conseil général du Puy-de-Dôme deviendra propriétaire de

l’ensemble des documentations produites par le titulaire et pourra les utiliser librement.


3.3. SSO Afin de faciliter la connexion au système et permettre une logique d’authentification unique SSO (Single Sign-On), la gestion de l’authentification des utilisateurs devra se faire via la solution de fédération des identités OpenAM en cours de mise en place au CG63.

Cette solution permettra de gérer 4 méthodes d’authentification citées ci-dessous par ordre de

préférence :

1. Enrichissement des entêtes HTTP Le serveur de SSO peut, suite à une authentification réussie, enrichir les entêtes HTTP Header ou

cookies et transmettre la requête enrichie au serveur du portail. Les variables transmises peuvent

être le nom de login, le nom de matricule... Le nom des variables peut être choisi par le prestataire.

Cette solution est non intrusive, toutes les requêtes HTTP destinées au portail passent auparavant au

travers d’un reverseproxy qui prend en charge l’enrichissement des entêtes ou des cookies.

2. Installer un agent ou des APIs sur le serveur du portail Cette solution consiste à installer sur le serveur du portail des APIs ou un agent qui pourraient

vérifier que l’utilisateur est bien authentifié à OpenAM. Cette solution nécessite qu’une version d’API

ou d’agent OpenAM compatible avec le moteur de développement du portail existe.

3. Principe du FormFilling Cette solution consiste pour OpenAM à capturer le login et le mot de passe saisis par l’utilisateur à

l’ouverture de son poste de travail et à le rejouer sur le formulaire de login du portail. Cette solution

impose que le portail utilise le même référentiel LDAP d’authentification que celui utilisé à

l’ouverture de la session sur le poste de travail.

Nous utilisons un référentiel Microsoft Active Directory synchronisé avec un annuaire Novell

eDirectory.

4. Compatibilité SAML Le serveur SSO OpenAM est compatible SAML. Cette techno n’a pas encore été implémentée au CG.

Le prestataire veillera à respecter l’architecture SSO qui sera mise en place en l’appréhendant au préalable. Le schéma fournit en annexe donne un aperçu de l’architecture cible.

Par ailleurs, l’accès aux applications (par liens) sera situé dans le portail avec une gestion de droits pour n’afficher que les liens vers les applications auxquelles l’utilisateur a droit. En revanche, le SSO des applications sera délégué au moteur de SSO OpenAM.

A noter qu’il ne sera pas permis d’insertion dans l’annuaire Active Directory du Conseil général.


Le candidat décrira dans son offre ses capacités d’interfaçage avec le produit OpenAM et la(les)

méthode(s) d’authentification envisagée(s). Le soumissionnaire présentera également tout

document, rapport ou certification permettant de justifier ses engagements en termes de sécurité.



La solution devra être configurée et opérationnelle avec le moteur de SSO OpenAM dès le lancement

de l’intranet. L’ensemble des applications accessibles en SSO aujourd’hui devront l’être également au

lancement du futur intranet.

3.4. Accès depuis les postes utilisateurs Le Conseil général gère 2000 postes de travail.

L’intranet sera compatible et accessible de la même façon (les interfaces s’afficheront de manière

identique) avec les principaux navigateurs web du marché comme Internet Explorer version 10 et

supérieures, Chrome, Firefox 22 et supérieures, Safari et Opéra, et ce quel que soit le système

d'exploitation (Windows, Mac). Cela concerne l’affichage des différentes interfaces utilisateurs dites

« front-office » et « back-office ».

L’intranet devra également permettre un affichage de qualité sur les principaux navigateurs web

mobile.

Des tests devront être réalisés sur l'ensemble des pages et interfaces de l’intranet.

La messagerie du Conseil général est une messagerie GroupWise 2012 accessible depuis un navigateur Internet ou depuis un client Lourd. Le Conseil général est équipé d’une infrastructure NOVELL. Les agents s’authentifient sur le serveur d’infrastructure NOVELL (NDS), compatible LDAP, situé à l'Hôtel du Département. Cette authentification est synchronisée avec une AD (Active Directory).


Le soumissionnaire présentera tout élément d’information permettant d’assurer le respect de ces

demandes de compatibilités.

3.5. Serveurs et Virtualisation La solution est obligatoirement virtualisable. Le Conseil général possède une architecture virtualisée sous VMware ESX 5.

Attention : le CG63 ne valide que des VM qui fonctionnent sous :

- Linux : Suse linux enterprise server 10SP2 ou 11 SP1 - ou Windows : Windows 2008 r2

Les serveurs bases de données Oracle sont des serveurs AIX5.3 virtualisés (ARF).


Le soumissionnaire présentera tout élément d’information permettant d’apprécier la compatibilité

de sa solution avec l’environnement VMWare en place au Conseil général.

3.6. Bases de données Une solution sous base Oracle bénéficiera d’une note technique supérieure.

Les bases de données sont majoritairement des bases Oracle 10g mutualisées (plusieurs applications

par base). Le conseil général dispose de quelques bases MySQL ou SQLServer.


Le CG privilégiera une réponse sous base oracle et de préférence en version 11g . Le cas échéant, le

candidat devra justifier de compétences ORACLE nécessaires à ses prestations d’installation prévues

au marché.


Le soumissionnaire présentera tout élément d’information permettant d’apprécier la compatibilité

de sa solution avec les bases de données citées

3.7. Flux de données Le titulaire protègera les flux sur lesquels transitent des données sensibles par le protocole HTTPS. Il

prévoit notamment d’utiliser des protocoles standards assurant la confidentialité et l’intégrité des

données. Cette demande vise à interdire à toute personne d’accéder à des informations auxquelles

elle ne devrait pas avoir accès. Cette demande vise également à ne pas autoriser le recoupement

d’informations permettant l’identification de personnes lorsque des flux avec des applications tierces

sont créés.


Le soumissionnaire présentera tout élément d’information permettant d’assurer le respect de ces

demandes de protection de flux.


Au lancement de l’intranet, le protocole HTTPS sera opérationnel.

3.8. Pour sites internet

Bien que ce ne soit pas la cible principale, la solution pourra héberger des sites internet.

L’architecture proposée devra tenir compte de cette contrainte, notamment le passage par un DMZ

privée + publique. Le candidat présentera sa solution pour sécuriser l’ouverture vers internet.

Ces sites, comme le portail intranet, pourront avoir leur propre nom de domaine.

Les sites, bien qu’étant hébergés sur le même serveur, doivent être compartimenté. Par exemple : il

ne doit pas être possible d’adresser une ressource publiée sur le site A en passant par l’URL du site B.


Le soumissionnaire présentera tout élément d’information permettant d’assurer la publication de

sites internet.

Il fournira un schéma d’architecture dimensionné pour répondre à nos attentes. Les licences

proposées dans son offre tiennent compte de cette architecture.


3.9. Performance de la solution

Qualité de service 3.9.1.

L’intranet deviendra un véritable outil de travail pour les collaborateurs : certaines pratiques

s’appuyant aujourd’hui sur la messagerie (comme la transmission de documents) et sur les lecteurs

réseaux (comme le partage de documents) seront portées sur l’intranet. La fluidité des interfaces et

la fiabilité des outils sont indispensables. Les délais d’affichage des interfaces devront être inférieurs

à 1 seconde en temps normal et inférieurs à 3 secondes lors de pics de charge. Un dépassement de

ces délais d’affichage sera qualifié « d’anomalie gênante », voir « bloquante » si les ralentissements

ont lieu sur les périodes d’utilisation normale de la solution.

Les fonctions nécessitant la persistance de la connexion ou de la session doivent tenir compte des

pertes de connexion avec le serveur du réseau et prévenir tout risque de perte de données pour

l’utilisateur. La durée minimale de session sera de 8h et paramétrable par l’administrateur

technique.

De manière à récupérer les derniers contenus publiés, la solution devra permettre de rafraîchir les

pages de manière automatique. Le délai sera administrable.

Les opérations courantes de maintenance et de sauvegarde devront pouvoir se réaliser

automatiquement en dehors des plages de travail (à définir avec le CG63 au cours de la phase de

spécifications) et de manière planifiée.


Le soumissionnaire précisera toute information utile présentant le niveau de qualité de service qu’il

propose.

Topologie du réseau – accès internet 3.9.2.

Tous les sites du Conseil général sont interconnectés à travers un réseau VPN/IP.

Tout le trafic Internet passe par un Pare-Feu de type Netasq.

Les services réseau sont offerts par un serveur d'infrastructure Novell.

Le conseil général dispose également d’une Active Directory.

La vitesse de la liaison internet est de 2*20 Mbits/s à l'Hôtel du département

Les sites distants sont interconnectés selon trois modes :

3 sites connectés en fibre (HDD, GCO, MDH) à 100Mb/s

3 sites connectés en fibre (MD, ADP, Vaucanson) à 10Mb/s

30 sites connectés en liaison 2Mb/s (Circo, Antennes, DRD)

60 sites connectés en ADSL 8 à 18 Mb/s (Districts, Centre d’interventions et permanences)

Dimensionnement et évolution de la capacité de la solution 3.9.3.

La solution doit être dimensionnée par rapport à ces plages de « maximum d’interruption ».

L’architecture technique proposée par le candidat (nombre de serveurs, répartition, puissance) devra

tenir compte de la topologie du réseau ainsi que du nombre de connexions.

Le titulaire travaillera avec le CG63 sur la définition de scenarii de charge en s’appuyant sur son

expérience. L’hypothèse de départ est la suivante :


2000 sessions ouvertes,

300 sessions actives,

Pic de charge de 100 sessions actives simultanées

Les sessions doivent persister suite à une perte/rétablissement de la connexion réseau.

L’architecture proposée doit être scalable pour maintenir le niveau de service. Il doit être possible

d’ajouter de nouveaux serveurs avec une répartition des charges (load balancing).

Dès le départ, la solution doit intégrer un load-balancer qui permettra un premier niveau de

tolérance aux pannes.

A défaut de résultats conformes aux attentes avant et durant la vérification de service régulier (VSR),

le titulaire devra mener les campagnes de tests nécessaires à diagnostiquer le problème.

En outre, le titulaire mettra en place un dispositif de mesure permettant à « usage connu du site »

d’associer une performance du système. Les indicateurs de performance et les moyens de mesure

sont à définir par le titulaire. Ce dispositif permettra d’anticiper des ajustements sur les capacités

d’hébergement et de débit utilisées.


Le soumissionnaire précisera toute information utile permettant de mieux comprendre sa faculté à

évaluer et à dimensionner les capacités nécessaires au bon fonctionnement de sa solution dans le

contexte du CG63.

Le soumissionnaire fournira un schéma d’architecture dimensionné pour répondre à nos attentes. Les licences proposées dans son offre tiennent compte de cette architecture.


L’architecture ciblée devra être mise en œuvre dès le lancement de l’intranet.

Surveillance/exploitation 3.9.1.

L’outil Nagios (v3) permet à la DSI de surveiller à distance les applications et de remonter des alertes

en cas de défaillance. Le prestataire devra fournir à minima les URL de vérifications de la bonne

exécution de la solution.

Par ailleurs, les procédures d’arrêt/sauvegarde/relance/traitements de nuit sont ordonnancées par

l’automate Vega (v5). Le prestataire devra fournir les scripts d’exploitation et conseiller le CG63 sur la

mise en place des procédures d’exploitation.


Le soumissionnaire présentera tout élément d’information permettant d’assurer l’intégration aux

outils de surveillance et d’exploitation


3.10. Respect des normes d’interopérabilité et accessibilité Le soumissionnaire fournira des garanties d’interopérabilité en mentionnant comment il peut

respecter le cadre de recommandation du Référentiel Général d’Interopérabilité notamment son

volet technique. Sont notamment cités dans ce volet : IHM, feuilles de styles, scripts, navigateurs

web, messagerie, téléphonie, services web SOAP et REST, services d’annuaires et de fédérations

d’identités, services réseau IP, TCP, HTTP (GET, POST), HTTPS, transfert de fichiers, streaming vidéo,

horloge.

http://references.modernisation.gouv.fr/rgi-interoperabilite

Par ailleurs, tous les développements réalisés par le titulaire devront être en conformité avec le

RGAA, tel que le précise le Décret n° 2009-546 du 14 mai 2009, mettant en application l'article 47 de

la Loi n° 2005-102 du 11 février 2005 sur l'égalité des droits et des chances, la participation et la

citoyenneté des personnes handicapées. Ce Décret est complété par l’Arrêté du 21 octobre 2009

relatif au référentiel général d'accessibilité pour les administrations. Cette norme française est basée

sur la norme internationale WCAG 2.0 (Web Content Accessibility Guidelines) de la WAI (Web

Accessibility Initiative).

http://references.modernisation.gouv.fr/rgaa-accessibilite/

Sont notamment visés par ces obligations d’accessibilités, mais non limitativement : Images, cadres,

couleurs, multimédia, tableaux, liens, code exécutable, éléments obligatoires, structuration de

l’information, présentation de l’information, formulaires navigation et au niveau de la consultation.

Le soumissionnaire devra proposer des fonctions de publication (y compris éditeur texte riche)

générant du code conforme aux critères techniques d'accessibilité

Lors de la phase de spécifications fonctionnelles et techniques, le pouvoir adjudicateur pourra

décider de déroger à certaines des préconisations si cela s’avère nécessaire pour assurer une

meilleure ergonomie de l’application. Néanmoins, sachant que le contexte réglementaire peut

évoluer, les points non conformes devront être précisément identifiés et délimités par le titulaire de

manière à faciliter une éventuelle amélioration sur ce volet dans un second temps.

Le titulaire est en charge de la réalisation de tests afin de valider que l’interface développée est bien

conforme aux critères d’accessibilité imposés par la réglementation, et ce, tout au long du projet. Il

est d’ailleurs recommandé aux soumissionnaires de consolider leur démarche en s’appuyant sur un

validateur tel qu’Opquast Reporting.

Le cas échéant, le CG63 pourra faire appel à un expert en accessibilité qui évaluera le site. En regard

des conclusions qui seront apportées, le titulaire sera responsable des éventuels ajustements

nécessaires pour atteindre le niveau exigé.

Au cours de la phase de réalisation, le titulaire devra clairement alerter le CG63 si certaines de ses

demandes sont contraires aux objectifs d’accessibilité.


http://references.modernisation.gouv.fr/rgi-interoperabilite

http://references.modernisation.gouv.fr/rgaa-accessibilite/


Le soumissionnaire présentera tout document, rapport certification permettant de justifier ses

engagements en termes de respect de l’accessibilité.

3.11. Développement et personnalisation Le conseil général souhaite disposer d’une solution hautement évolutive dont la maîtrise est assurée

d’une part :

- Par les utilisateurs dans le cadre de leur utilisation quotidienne de l’outil,

- Par les contributeurs et administrateurs fonctionnels grâce aux facilités de création et

d’administration de contenus intégrées à l’outil,

Mais également :

- par la DSI pour répondre aux demandes des services quant à l’ajout de fonctionnalités.

Dans la version actuelle du portail (produit Oracle AS Portal 10g), la DSI est maître de l’ajout de

nouvelles fonctionnalités ou du développement de nouveaux portlets.

Environnement technique : langage Java, portlet Oracle JPDK.

Dans le futur portail, nous souhaitons reconduire dans la mesure du possible ce mode de

fonctionnement apportant souplesse et réactivité, étant attendu que le niveau d’apprentissage

requis pour la maîtrise de l’environnement technique soit acceptable.

Dans certains cas, selon les demandes, le partenaire intégrateur pourra toutefois être sollicité via le

contrat de support.


Le soumissionnaire présentera la plateforme technique de développement de la solution. Il précisera

l’existence le cas échéant de tout élément permettant de faciliter la prise en main de la plateforme

(macro langage, API, framework…). Il précisera également les éléments techniques que devront

maîtriser l’équipe en charge du développement du portail à la DSI.


4. Prestations générales attendues Les prestations générales attendues s’organisent en plusieurs phases :

- La réalisation des spécifications fonctionnelles de la solution pour le CG63

- La création du graphisme et de l’ergonomie

- La mise en œuvre de la solution et des fonctionnalités sur l’environnement de recette

- La mise en œuvre sur l’environnement de production

- Les formations

- Les prestations complémentaires

4.1. Cadrage du projet A l’occasion de la réunion de lancement le titulaire présentera un planning détaillé de la réalisation

en indiquant également les propositions de jalons concernant les actions du pouvoir adjudicateur. Le

titulaire initialisera également la gestion des risques.

Le titulaire adaptera sa méthodologie projet au contexte du CG63. Il présentera une proposition et

engagera une discussion avec le pouvoir adjudicateur pour valider la méthodologie du projet. Le

pouvoir adjudicateur attend une démarche prenant en compte : planning et gestion de

l'avancement, gestion des risques (intégrant ceux perçus par le pouvoir adjudicateur).

Tableaux de bord 4.1.1.

Le titulaire fournit des tableaux de bord permettant de suivre l’évolution du projet tout au long de

son cycle de vie. Les tableaux de bord assurent un suivi de la qualité, de la sécurité et du respect des

engagements relatifs au projet. Ces tableaux peuvent prendre la forme de grilles excel ou tableaux

WORD/PPT.

Environnements 4.1.2.

Le Conseil général souhaite disposer des environnements nécessaires à la recette de la solution livrée

d’une part, ainsi qu’à la mise en exploitation de la solution d’autre part.

Pour la recette : 2 serveurs

Serveur de test : pour essentiellement effectuer des tests techniques (paramétrage,

intégration, développements…). Ce serveur sera supprimé à l’issue des opérations de

vérification et de mise en production.

Serveur de pré-production : pour effectuer la recette proprement dite de la solution.

Ce serveur servira de support aux contributeurs pour la saisie du contenu initial du

portail. Son contenu sera repris lors du passage en production. Ce serveur est

dimensionné pour la recette. Il subsistera en tant que serveur de test à l’issue des

opérations de vérification et de la mise en production.

Pour la production : nombre variable de serveurs selon architecture proposée par le titulaire

Environnement de production : l’architecture de cet environnement est

dimensionnée pour répondre aux contraintes techniques d’exploitation.


4.2. Spécifications fonctionnelles (phase technique 1) Le titulaire proposera une démarche impliquant le pouvoir adjudicateur. Cette démarche consistera à

préciser le besoin en partant du programme fonctionnel détaillé décrit dans les chapitres précédents

et à l’éclairage des solutions retenues. Cette démarche devra à minima comprendre :

Une présentation de la solution au pouvoir adjudicateur dans l’optique de s’approprier des possibilités et contraintes de la solution

Une animation de plusieurs ateliers de spécifications fonctionnelles s’appuyant sur du maquettage et détaillant un maximum d’écrans

La formalisation d’un document de spécifications fonctionnelles (intégrant le maquettage fonctionnel)

Une gestion avertie de la relecture du document et de sa finalisation pour validation

Le titulaire aura la responsabilité des spécifications fonctionnelles. Il s’engage donc à formaliser un

document suffisamment détaillé pour éviter toute approximation dans la réalisation qui suivra. A

défaut, les conséquences de tout élément non précisé (notamment toute contrainte ou limitation

non exposée) d’une fonction décrite seront de la responsabilité du titulaire. Le pouvoir adjudicateur

pourra demander un complément de réalisation à la charge du titulaire.

Livrables attendus

Spécifications fonctionnelles de la réalisation.

Délais de réalisation

Les spécifications fonctionnelles devront être validées un mois et demi après la notification du

marché.

4.3. Graphisme et ergonomie (phase technique 2)

Outre le caractère fonctionnel du site intranet à mettre en place, le CG63 tient à mettre à disposition

des intranautes un portail moderne, au design attractif, et valorisant l’image de la collectivité. Elle

accorde donc une importance certaine à la qualité du graphisme.

Création de la charte graphique 4.3.1.

Le titulaire présentera de façon claire trois orientations graphiques et ergonomiques différentes pour

le portail intranet, en tenant compte du travail déjà réalisé par la MOA (menu, arborescence,

organisation des contenus…). Après que la MOA ait fait un choix, des allers - retours permettront

d’obtenir une version définitive de la charte graphique du site.

Le titulaire présentera une déclinaison de cette charte sur les principales pages ou éléments

identifiés (Environ 6 à 10). Les déclinaisons feront éventuellement l’objet d’adaptations et

d’itérations avant finalisation.


Le titulaire formalisera ensuite la charte graphique dans un document Word, ou équivalent, en

détaillant tous les éléments graphiques utilisés (titres, puces, polices, liens, codes couleurs, contraste

des combinaisons de couleurs texte/arrière-plan etc.).

Le titulaire sera en charge de l’intégration HTML de la charte graphique qui deviendra de facto la

propriété du CG63. Le titulaire cèdera aussi totalement les droits induits : droits pour la reproduction

et l’adaptation des visuels dans le cadre des actions de communication du CG63 et plus

généralement pour tout type de support et pour une durée de 15 ans.

Elaboration de l’ergonomie 4.3.2.

Le titulaire est chargé de concevoir le design de l’information (arborescence du site, organisation des

contenus) et l’ergonomie de navigation. Une attention particulière est attendue sur ce volet afin que

l’intranet soit un outil simple à utiliser, agréable à lire, et organisé selon les standards ergonomiques

en vigueur.

Evolution de la charte graphique 4.3.3.

Par la suite, il sera possible pour l’administrateur de changer une partie de l’habillage de l’intranet

notamment pour générer des feuilles de styles adaptées aux nouveaux gabarits de page.

Accessibilité 4.3.4.

La charte et l’ergonomie devront être conformes aux exigences d'accessibilité prévue dans le cadre

du RGAA au niveau tel que décrit dans le paragraphe correspondant (« Respect des normes

d’accessibilité »), particulièrement en ce qui concerne les contrastes de couleurs, l'utilisation de la

couleur comme véhicule de l'information, la présence du fil d'Ariane et la différenciation des liens

par rapport au texte environnant.

Livrables attendus

- Story-board des écrans principaux (réalisation en parallèle des spécifications fonctionnelles)

- Charte graphique : écrans principaux du portail (PNG ou GIF)

- Fichiers sources (format Photoshop ou équivalent +Illustrator ou équivalent)

- Charte graphique détaillée avec typographie (format Word ou équivalent)

- Montage HTML et CSS commentés.


- Ensemble des écrans principaux type : date précise définie lors de la réunion de lancement

- Charte graphique détaillée : date précise définie lors de la réunion de lancement.

- De manière générale, les délais de réalisation s'insèrent dans le calendrier général du projet


Le soumissionnaire présentera des exemples de réalisations graphiques. Il proposera une

reformulation des objectifs du projet de l’intranet dans un langage graphique, sous la forme d’un

paragraphe rédigé.


4.4. Mise en œuvre sur environnement de recette (phase technique 3)

Le titulaire prendra en charge la réalisation de la solution spécifiée conformément aux différentes

rubriques intitulées « Description de la configuration initiale » présentes dans les descriptions

fonctionnelles et techniques et qui seront précisées dans la phase de spécifications fonctionnelles à

savoir :

La configuration des processus de publications et rôles associés,

La création de tous les comptes et profils utilisateurs et leur synchronisation avec un annuaire interne,

La configuration du rubriquage (page d’accueil et rubriques),

Les différents types de contenus listés dans les paragraphes « Blocs envisagés au lancement de l’intranet » et «Types de contenus »

La configuration des types de contenu et des métadonnées,

La configuration du moteur de recherche,

La configuration de la solution avec le moteur de SSO OpenAM (étude et mise en œuvre),

La configuration de tous les modules et services nécessaires,

Etc.

Le titulaire proposera une démarche permettant au pouvoir adjudicateur de travailler sur la

formalisation des données techniques de configuration nécessaire à l’instanciation initiale de la

solution conformément aux spécifications fonctionnelles.

Pour l’intégration et le développement de la solution, le CG63 souhaite une méthode itérative, incrémentale et adaptative de type AGILE.

Les livraisons intermédiaires pourront se faire au choix sur site du titulaire ou sur site du CG63 selon

la méthodologie du titulaire, étant attendu que la livraison finale pour la recette se fasse sur

l’environnement du CG63 (test et pré-production).

Les moyens techniques nécessaires seront à la charge du titulaire. Il devra fournir les prérequis

techniques à l’installation des logiciels (Os, Base de Données, etc.).

Le titulaire prendre en charge l’installation des logiciels et la documentation associée, adaptée au

contexte du Conseil général.

Un transfert de compétences techniques à la DSI devra être assuré dans le but de permettre

d’appréhender l’environnement technique de la solution d’une part, mais également de permettre à

la DSI d’instancier de manière autonome les blocs ou de développer de nouveaux blocs tel que défini

dans le paragraphe « Blocs envisagés au lancement de l’intranet ».

Pendant les opérations de vérification, le titulaire assurera la correction et la re-livraison des logiciels

avec conservation des contenus de l’intranet et sans perte de la configuration, sauf demande

explicite du CG63.

Livrables attendus


- Licences environnement de recette (test et pré-production)

- Fourniture des logiciels et de leur documentation standard associée

- Démarche et mode opératoire pour la transmission des éléments techniques de configuration

initiale

- Documentations fonctionnelles et techniques des modules spécifiques

- Portail configuré conformément aux spécifications fonctionnelles

- Fonctions opérationnelles dans l'environnement de recette

- Transfert de compétences


L’application devra être livrée en environnement de recette au plus tard 3 mois après le début de la

phase de réalisation afin de démarrer la VA.

- De manière générale, les délais de réalisation s'insèrent dans le calendrier général du projet

4.5. Mise en œuvre sur environnement de production (phase

technique 4) A ce stade, la solution est opérationnelle et validée sur l’environnement de pré-production avec une

configuration initiale, ainsi que le contenu qui a été renseigné par les contributeurs.

Le titulaire prendra en charge l’installation et le paramétrage de l’environnement de production.

L’architecture devra être dimensionnée pour répondre aux contraintes techniques (charge, load

balancing, accès internet DMZ publique/privée…).

Le titulaire prendre en charge la reprise du paramétrage et des contenus de l’environnement de pré-

production.

A la demande du Conseil général, le titulaire effectuera si besoin des paramétrages ou des

développements spécifiques complémentaires nécessaires à la mise en exploitation ou pour

répondre à des demandes fonctionnelles non identifiées jusqu’à lors.

Le titulaire accompagnera la DSI en charge pour l’intégration de la solution au Système

d’Informations du Conseil général (réseau, surveillance, traitement d’exploitation) et fournira tous

les éléments requis.

Le transfert de compétence à la DSI devra être assuré toujours dans le but de permettre une certaine

autonomie.

Pendant les opérations de vérification, le titulaire assurera la correction et la re-livraison des logiciels

avec conservation des contenus de l’intranet et sans perte de la configuration, sauf demande

explicite du CG63.

Livrables attendus

- Licences environnement de production : en phase avec le dimensionnement de l’architecture

proposé pour répondre aux contraintes techniques.

- Dossier d’architecture technique (schéma d’architecture, description des serveurs, licences …)

- Documentation d’exploitation


- Solution paramétrée et intégrée au SI

A noter : Le schéma d’architecture simplifié présenté en annexe montre l’architecture du portail

actuel. Les licences proposées dans l’offre devront être en adéquation avec cette architecture.

Lorsque le soumissionnaire présente une architecture différente de celle proposée, il devra justifier

qu’elle permet tout-de-même de répondre aux contraintes techniques.

4.6. Formations (phase technique 5) Le titulaire prendra en charge la formation de l’équipe de test avant le démarrage de la VA. Cette

formation devra leur permettre de réaliser les opérations de recette.

Le titulaire réalisera également les formations pour :

Les administrateurs techniques : 5 personnes

Les administrateurs fonctionnels : 20 personnes

Les contributeurs : 20 personnes

Pour chacune des formations, le soumissionnaire devra préciser les connaissances et compétences

requises pour participer aux formations.

Les formations se dérouleront sur site CG 63 ; elles seront commandées au marché et valorisées sous

la forme de session (chaque session durant de 1 à x jours selon le contenu méthodologique proposé

par le soumissionnaire).

Le transfert de compétences pour les administrateurs techniques devra porter au minimum sur :

La structure de l’environnement de la solution proposée

La présentation de l’administration centrale de la solution proposée

La gestion des applications web

La gestion, analyse et épuration des logs

La sauvegarde et restauration

La gestion des comptes administrateurs

L’administration en ligne de commande

La configuration du moteur de recherche

La reprise en cas d’incident

Développement de portlets

Consommation de web services,

Intégration de CSS

Accès aux bases de données

Le transfert de compétences pour les administrateurs fonctionnels devra porter au minimum sur :

Manipulation de l’outil WYSIWIG

Mise en forme des pages de contenu

Insertion et configuration des blocs

Gestion de l’arborescence


Manipulation et création des types de contenus

Gestion de la configuration des espaces de stockages

Manipulation des bases documentaires (documents de référence, vidéos, images, sons)

Modification des métadonnées

Personnalisation de la recherche avancée

Utilisation du moteur de recherche

Création de formulaires

Intégration de flux RSS

Livrables attendus

- Support de formation pour les contributeurs de l’intranet. Ce support de formation devra être en

français et modifiable par le CG63 pour en adapter les contenus en phase d’exploitation.

- Support de formation pour l’administration fonctionnelle de l’intranet. Ce support de formation

devra être en français et modifiable par le CG63 pour en adapter les contenus en phase

d’exploitation.

- Documents d’exploitation des solutions fournies


- Formation des équipes de recette au plus tard 1 semaine après le démarrage de la VA

- Formation des administrateurs techniques au plus tard 1 semaine après le démarrage de la VA

- Formation des administrateurs fonctionnels au plus tard 1 mois après le démarrage de la VSR

- Formation des contributeurs au plus tard 1 semaine après le démarrage de la VSR

4.7. Prestations complémentaires (phase technique 6)

Pendant la durée d’exécution du marché, des prestations complémentaires sont envisageables, le cas

échéant, pour faire évoluer l’architecture technique de la solution : prestation d'installation, de

paramétrage, ou encore de développements spécifiques pour répondre à de nouvelles demandes de

fonctionnalités, avec leurs transferts de compétences associés. Le titulaire pourra également être

sollicité pour l’analyse, la conception ou la rédaction de documentation fonctionnelle et/ou

technique complémentaire.

Ces prestations seront commandées à la journée ou demi-journée et pourront être réalisées à

distance ou sur site CG 63 (bons de commandes unitaires).

De la même manière, des licences complémentaires peuvent s'avérer indispensable à l'évolution de

l'architecture. Dans son offre, le soumissionnaire propose un taux de remise unique, applicable sur

son prix public en vigueur au moment de la commande, pour la fourniture de ces licences

complémentaires. Ce taux de remise unique est à valoir sur toute la durée du marché.


4.8. Opérations de vérification La vérification sera réalisée conformément aux règles annoncées dans le Cahier des Clauses

Administratives Particulières (CCAP). Elle portera sur la mise en œuvre de la solution en

environnement de recette ainsi que sur la mise en œuvre de l’environnement de production.

MOM, VA, VSR ou constat de service fait selon la nature des prestations

Durant les opérations de vérification, le titulaire prendra en charge le pilotage de la gestion des

anomalies remontées, de la qualification des anomalies, de la correction des anomalies, des tests de

non régression, de la livraison des anomalies corrigées. Il proposera d’utiliser une application en ligne

de suivi des anomalies permettant de partager un référentiel commun entre tous les acteurs de la

recette.

Un planning, une organisation et un suivi précis des livraisons de correctifs seront gérés par le

titulaire et impliqueront le pouvoir adjudicateur. Le titulaire devra donner la visibilité suffisante au

pouvoir adjudicateur pour que ses ressources puissent s’organiser pour réaliser les opérations de

recette.

Livrables attendus

- PV de recette interne au titulaire

- Dossier de recette

- Dossier des tests élémentaires

- Suivi d'avancement hebdomadaire des anomalies en cours de traitement

- Livraison des correctifs

- PV de tests et liste des correctifs pour chaque livraison

- Formalisation de la demande de configuration

- Instance configurée avec les données et contenus transmis

5. Assistance technique, support et maintenance (phase technique

7) Cette partie détaille les exigences attendues en termes de garantie, maintenances corrective /

évolutive et assistance.

5.1. Conditions de maintenance La DSI souhaite conserver la maitrise de l’évolution de son site intranet / extranet (voir internet).

Le prestataire nous aide à mettre en place la plateforme et à assurer la maintenance en conditions

opérationnelles

Cette prise en charge se déroulera pendant 2 périodes :

1 – dès la livraison de l’intranet par l’intégrateur suite à notre appel d’offres. Cette période

comprendra, le transfert de compétence pour acquérir l’autonomie nécessaire , et la période de


garantie d’un an assurant la correction des dysfonctionnements majeurs et mineurs dans des délais

prévus. Ce contrat couvre pendant la période de garantie, la maintenance corrective et évolutive.

2- au-delà de la période de garantie

C’est le Conseil général/DSI, qui garde la maîtrise des évolutions :

- tant systèmes, nouvelles versions, patchs, …

- que fonctionnelles, modification de l’existant, ajout de modules, développement de

fonctionnalités etc…

Pendant cette période, le Conseil général souhaite disposer d’une part d’un contrat de support et

d’autre part d’un contrat de maintenance, tous les 2 assurés par le prestataire intégrateur qui a la

connaissance de notre site.

Description du contrat de Support

Le Conseil général souhaite les éléments suivants dans le cadre de ce contrat :

- une prise en compte des incidents avec un délai garanti d’intervention (GTI) fonction de la

sévérité du problème. Un accès en ligne à un outil de gestion des incidents doublé d’une

hotline téléphonique est souhaité. L’intervention aura pour but selon la gravité le retour à la

normale du service, soit par correction ou contournement du problème, soit par la délivrance

d’un support technique pour éliminer le problème. Le service support pourra être contacté

pendant les plages horaires d’ouverture définies dans le contrat (9h-18h LMMJV). Les temps

d’intervention proposé ci-dessous seront également définis par contrat :

- Incident bloquant, le service n’est pas assuré 4H

- Incident important, le système fonctionne en mode dégradé 24H

- Incident mineur, le système fonctionne sans impact 48H

- pouvoir répondre sur devis, à partir d’un tarif par profil d’intervenant, pour mettre en place

de nouvelles fonctionnalités, réinstallation de serveurs, ou configurations… soit venir

installer de nouvelles versions du socle de base de l’intranet. La proposition de support

comporte donc par profil d’intervenant les coûts unitaires.

- une prise en compte des demandes d’assistance, sur une base horaire ou de tickets, pour

conseiller la DSI dans ses projets de développements

La majorité des opérations de support et d’assistance pourront se faire à distance via un accès VPN,

mais il faut envisager la possibilité d’une intervention sur site.

Description du contrat de Maintenance

Dans le cadre de ce contrat, le prestataire se doit de nous alerter de toute faille de sécurité de la

solution et les moyens d’y remédier, mais également de nous tenir au courant des évolutions de

version (mineures ou majeures) permettant de résoudre des anomalies. Ces informations doivent

être ciblées sur notre plateforme, système et base de données compris.


En fonction de la criticité des informations remontées, le CG63 prendra la décision on non de mettre

à jour la solution.

Le prestataire doit mettre à disposition de la DSI tous les éléments permettant de réaliser l’opération

de maintenance (fichiers et modes opératoires). Lorsque le DSI effectue elle-même l’opération de

maintenance, le prestataire lui doit assistance dans le cadre du contrat de support.

Le DSI pourra dans certains cas prendre la décision de confier cette opération au prestataire. Dans ce

cas, un devis sera établi sur la base des prix unitaires du marché.

Par ailleurs, nous souhaitons dans le contrat que soient prévue 1 à 2 journées de Maintien en

Conditions Opérationnelles (MCO) par an. Durant ces journées, le prestataire réalise un audit de la

plateforme et émet des préconisations d’évolutions de l'architecture.

Il sera apprécié de disposer d’un site internet, comportant les nouveautés techniques du produit

installé, sa roadmap, les correctifs de sécurité si nécessaire, des fonctions téléchargeables, de la

documentation… ou encore si l’outil choisi dispose d’une communauté, d’avoir connaissance de

l’animation de celle-ci.


Le soumissionnaire décrira la structure d’assistance et les moyens consacrés à la maintenance qu’il

mettra à disposition de le CG63. Il précisera notamment sa garantie de temps d’intervention (GTI).

Il fournira dans sa réponse, son offre (idem contrat) de support, maintenance et assistance

technique.

Le Conseil général prévoit que les modalités contractuelles d’exécution du support et de la

maintenance débutent dès la période de garantie (les modalités standards de la garantie sont

écartées au profit des conditions particulières, préférentielles du support/maintenance).


6. Aide à la formulation de la réponse

Questions-réponses sur le DCE : La consultation sur appel d'offres autorise les questions sur le

cahier des charges dans les délais autorisés (cf. règlement de consultation). Les échanges par

messagerie sont permis mais dès lors que la réponse constitue un apport sur le DCE, l'ensemble des

candidats sera informé par l'envoi d'un CCTP complémentaire.

Identification des personnes "référentes" de l'offre : Il est demandé au candidat d'identifier

clairement en entête de document les personnes référentes de son offre (commercial et/ou

technique) pour faciliter les échanges "questions-réponses" et envoi(s) de courrier.

Cadre de réponse : En complément de son offre détaillée sur les fonctionnalités et la

méthodologie, le candidat doit obligatoirement compléter le cadre de réponse

fonctionnelle/technique fourni au DCE.

Ce cadre de réponse constitue une synthèse de l'offre. A ce titre il permet une appréciation rapide de

la proposition. Il convient également de préciser le renvoi sur l'offre détaillée (numéros de page,

documents,…). Le contenu est contractuel au marché.

Le format de la réponse est demandé en .xls (et non en .pdf). Un double du document en .xls sera en

effet récupéré par le CG63 pour faciliter l'analyse des réponses et ajouter des annotations ou

commentaires.

Calendrier projet : Les jalons de la réalisation du projet ont été posés au présent CCTP, article 1.6.

Néanmoins une proposition calendaire de déploiement est attendue dans la réponse car totalement

inhérente aux contraintes de la solution proposée par chaque soumissionnaire. Il est demandé au

candidat de préciser très clairement pour le déploiement les contraintes de sa solution, les moyens à

mobiliser tant pour lui-même que pour le Conseil général et son engagement à mobiliser ses

ressources propres, la durée de déploiement …

Réponse financière du candidat

Toutes les suggestions (contenu, prix…) permettant la réalisation des prestations du marché doivent

être consignées dans les prix du marché. Les avenants de marché n’auront pas pour objet d’avaliser

des oublis sur le contenu des prestations.

Les prix à valoriser au BPU s'entendent obligatoirement tous frais inclus (déplacement, repas…).

Compléter le Bordereau des prix :

"au forfait": Le prix est formulé forfaitairement pour un ensemble de prestations qui est dû au

marché quel que soit par ailleurs les moyens ou la méthodologie décrits dans l'offre. Le périmètre

contenu/coût/moyens…. proposé dans la réponse - hors réserve(s) - est à ce stade de la

responsabilité exclusive du soumissionnaire.

"coût unitaire" : Le prix est formulé unitairement pour un type de prestation pré déterminé et pour

lequel le besoin et surtout le volume restent de la maîtrise de commande du Conseil général.


"taux unique de remise" : ce taux de remise concerne l'achat de licences complémentaires. Il est

garanti par le titulaire, sur toute la durée du marché, et s'applique sur les prix publics en vigueur lors

de la commande.

L’ajout de prestations supplémentaires au bordereau des prix n’est pas autorisé. Ce dernier doit être

complété dans le cadre fourni au DCE.

Décompte des prix unitaires : la forme du document est laissé à l'initiative du candidat. Le

décompte des prix doit être fourni dans l'offre et doit ventiler en détail, au plus fin, les prix reportés

au bordereau des prix unitaires (toutes les suggestions de prix reconstituant les prix mentionnés au

BPU).

Document de synthèse financière de l'offre : doit être complété et fourni dans la réponse, pour

estimer l'offre financière globale, à partir des coûts exprimés au bordereau des prix unitaires (BPU) et

suivant les estimations quantitatives du Conseil général.

Ce document fait l'objet d'un enregistrement par la Commission d'appel d'offres lors de l'ouverture

des plis. Pour que l'offre soit recevable, le montant total " estimation de l'offre, hors maintenance"

devra s'inscrire dans le seuil budget dévolu au projet.

Les documents fournis au DCE (dossier de consultation d'entreprises) ont vocation à être

complétés et uniquement complétés. Ils ne doivent pas faire l'objet de modification dans leurs

cadres et libellés (tels qu'ajouts ou suppressions..) ; se conformer aux indications portées sur chaque

document pour apporter les précisions attendues.

A défaut la collectivité peut les rejeter et écarter l'offre pour non-conformité si toute

évaluation/comparaison s'avère impossible.


7. Annexes

7.1. Schéma simplifié d’architecture sécurisée

7.1. Architecteur SSO / OpenAM Le schéma de principe sera le suivant :

Infrastructure Frontal

2 x Frontaux

Load balancer

INTRANET DMZ PRIVEE DMZ PUBLIQUE

Load balancing /

failover

Base de données

Poste

intranet

Poste

Internet

INTERNET

Reverse Proxy

Architecture sécurisée à 4 serveurs

- 1 serveur d’infrastructure

- 2 serveurs frontaux internes

- 1 serveur frontal en DMZ privée

http://www.clker.com/clipart-1902.html








1 - L’accès aux ressources WEB s’effectuera à partir d’un point unique (reverseProxy).

2 - Une requête vérifiera que l’agent soit bien identifié

3 - Les données de session complémentaires seront enregistrées dans le profil de l’agent

4 – L’ensemble des informations seront transmises aux serveurs d’applications.

7.1. Tables intermédiaires RH pour synchronisation Ci-dessous la description logique des tables intermédiaires contenant des informations à jour sur les

agents et les groupes hiérarchiques (DG, Directions, Services).

Table : Agents

Champ Type Description

Login Chaîne Login de l’agent

Civilité Chaîne Madame, Monsieur

Nom Chaîne Nom

Prénom Chaîne Prénom

Email Chaîne Adresse de messagerie

Matricule Nombre Matricule agent

Position Nombre Flag pour "Chef de service", "Directeur" ou "DGA"

Téléphone Chaîne Téléphone

Code service Chaîne Code du service d’appartenance

Libellé service Chaîne Libellé du service d’appartenance

Lieu Chaîne Affectation géographique

Table : Groupes Hiérarchiques

Champ Type Description

Code groupe Chaîne Code du groupe

Libellé groupe Chaîne Libellé du groupe

Groupe père Chaîne Code du groupe père

Niveau Nombre Niveau dans la hiérarchie (1...N)


7.1. Gestion actuelle des identités

7.2. Récupération du nombre de messages non lus GroupWise L’appel aux services web suivants permet de récupérer le nombre de messages non lus du compte de

messagerie d’un agent.

LoginRequest() Ouverture de session GroupWise

Entrée : username, password de l’agent

Sortie : numéro de session

GetFolderRequest() Récupération d’informations

Entrée : numéro de session

Sortie : nombre de messages non lus

LogourRequest() Fermeture de session

Entrée : numéro de session

La description précise des services web sera fournie lors de l’implémentation.

La solution de SSO OpenAM prendra en charge la gestion des username et password des requêtes

SOAP.


7.3. Applications accessibles depuis l’intranet SPIDI

Légende 7.3.1.

Colonne : Type d'authentification

Aucun (pas d'authentification)

Base de données Oracle

Base de données MySQL

Externe (application hébergée à l'extérieur)

OID (Annuaire LDAP Oracle Portal)

AD (Active Directory de Microsoft)

Alcatel 4760 (LDAP Alacatel)

e_Dir (Annuaire)

Colonne : Méthode d'authentification

Aucun

Local (propre à l'application)

SSO Partenaire CG63 (Interne à l'environnement OC4J)

SSO Partenaire Oracle (Mod Osso Oracle)

SSO Externe (Capture du Login et mot de passe)

SSO RH (propre à GFI basé sur le Referer)

SSO OSW (propre à OSW basé sur l'identifiant de connexion)

Rappel : au déploiement de la nouvelle solution, l’authentification SSO sera déléguée au moteur de

SSO OpenAM.

Certaines applications sont des développements propres du CG63.


Liste au 08/08/13 7.3.2.

Application Description Méthode d'authentification

Type d'authentification

Alexandrie (GB Concept) Logiciel de documentation SSO Externe Base de données

Astre (GFI) Finances / Ressources Humaines / Subventions Local Base de données Oracle

Bi Publisher (Oracle) Développement de rapports BI Publisher Local OID

Business Objects Développement de rapports Business Objects Local OID

Cartothèque SIG / Cartothèque (base de données de cartes sous divers formats) SSO Partenaire CG63 OID

IntraCité (GFI / PDIPR) SIG / Plan Départemental des Itinéraires de Promenade et de Randonnées Local base de données Oracle

Route Net 2013 Inventaire du patrimoine routier / tracé / gestionnnaire / linéaire route en agglo, info circuit déneigement Local Base de données Oracle

Elise (Archimed) Logiciel de gestion de courriers Local Aucun

1-One (Neuros) Logiciel de prévention / évaluation des risques professionnels SSO Externe Base de données Oracle

Revue de presse (BSV/ZeDoc) Publications d'articles de quotidien régionaux Local Base de données Oracle

Gestor (GFI) Outils de gestion du temps de travail SSO Externe Base de données Oracle

Messagerie (Novell) Messagerie Novell Groupwise SSO Externe e-Dir/Groupwise

Eudoweb (Eudonet) Gestion de contacts Local Base de données Oracle

EasyReco (Exen) Editions de recommandés Local Externe

CervoPrint GenG4 Soumission de travaux d'impression à l'imprimerie Local base de données Oracle

Orphee .Net (C3RB) Logiciel de gestion de bibliothèque Local Base de données Oracle

Ligeo (VTechnologie) Gestion d'archives physiques et électroniques Local Base de données MySQL

Gestion des EPI (Qual Net / Intraqual) Gestion des équipements et vêtements de travail Local Base de données Oracle

Photothèque (Alchemy/Phrasea) Consultation de la photothèque des archives départementales Local Base de données MYSQL

GEDELIB web (Qualigraph) Administration des délibérations du Conseil général Local Base de données Oracle


TC Dome Application TC Dome Local Externe

Parapheur Electronique (GFI/Astre Démat.) Dématérialisation/signature des flux PES avec le payeur départemental

Annuaire ALCATEL Recherche dans l'annuaite téléphonique (interface Alcatel) Local Alcatel 4760

Annuaires admin. Annuaires complet des agents (SPIDI, ASTRE RH, NDS, Alcatel) et syncrhonisation SSO Partenaire CG63 OID

Organigramme Organigramme des services et agents SSO Partenaire CG63 OID

Frais déplacement Gestion des frais de déplacement agents SSO Partenaire CG63 OID

Intention d'achats (consult) Consultation des intentions d'achats publiées sur http://entreprises.cg63.fr Local Base de données Oracle

Intention d'achats (admin) Gestion des intentions d'achats SSO Partenaire CG63 OID

Annonces Petites annonces interne SSO Partenaire CG63 OID

Mes Applis Accès à mes applications back-office (Oracle Forms) SSO Partenaire CG63 OID

Mes Etats Accès mes états (BI Publisher) SSO Partenaire CG63 OID

Réservations Réservations de ressources (salles, videoprojecteur, voiture...) SSO Partenaire CG63 OID

Réservations ENS Réservation de salles Maison ENS SSO Partenaire CG63 OID

Objets Promotionnels Commande en ligne des Objets Promotionnels (ELUS) SSO Partenaire CG63 OID

Guide des aides Adminitration du guide des aides financières SSO Partenaire CG63 OID

Parapheurs Gestion des parapheurs (uniquement DGRM) SSO Partenaire CG63 OID

Enquêtes sociales Saisie et suivi des enquêtes sociales SSO Partenaire CG63 OID

Partage de fichiers Partage de fichiers en ligne avec des partenaires extérieurs Local Base de données Oracle

Educatic Aide en ligne Ms Office Aucun Aucun

QUALIPARC Gestion de parc informatique et incidents Local Base de données Oracle

Délibérations (Qualigraph) Consultation des délibérations du Conseil général Local Base de données Oracle

Virtualisation LEOSTREAM - accès aux postes de travail virtuels Local Base interne Leostream

FAQ FAQ de l'intranet SPIDI SSO Partenaire CG63 OID


Base de connaissances (GLPI) SSO Partenaire CG63 Base de données MySQL

Forum discussion (PhpBB) Forum de discussion global du CG SSO Partenaire CG63

Wiki Wiki pour le groupe projet de F. Ribet Local

Formulaires / Demandes de renfort Saisie/suivi/workflow validation des demandes remplacement SSO Partenaire CG63 OID

Formulaires / Demande de travaux Saisie/suivi/workflow validation des demandes de travaux SSO Partenaire CG63 OID

Formulaires / Gestion signalements Gestion des signalement enfants "en dangers" (DGSAS) SSO Partenaire CG63 OID

Formulaires / Demandes de Renfort TOS Gestion des demandes de renfort des personnels TOS (collèges) SSO Partenaire CG63 OID

Autres… Pas actuellement dans l'intranet mais à intégrer

Novell Vibe Outil collaboratif Local e-Dir

GED Alfresco Actuellement intégrée dans outil métier RH

Futur GPEC Logiciel de Grestion Prévisionnel de l'Emploi et des Compétences

Futur remplaçant de MR4G Suivi analytique aux routes

PareFeu Authentification Internet Local AD

Asalae

IODAS FSL

ASTRERH Consultation du dossier personnel SSO RH Base de données Oracle

OSW Offre social WEB SSO OSW base de données Oracle

https://projets.cg63.fr/

https://projets.cg63.fr/


7.4. Bloc « Petites annonces » Ce paragraphe donne des informations techniques sur la récupération de données relative aux

petites annonces stockées dans une application spécifique du conseil général.

Un transfert de compétence doit être prévu pour permettre à la DSI d’être autonome sur

l’enrichissement de ce bloc.

Exemple :

La ligne de l’annonce est un lien pointant vers l’annonce dans l’application du Conseil

général.

Les données sont récupérées par un accès direct dans la base de données de l’application

« Petites Annonces ». Les informations host, sid, port, login et mot-de-passe seront fournies.

La requête SQL d’extraction de la donnée sera fournie.

7.5. Bloc « Remontée d’application » Ce paragraphe donne des informations techniques sur la récupération de données pour une

sélection d’applications. Le bloc « Remontée d’application » devra être livré avec les exemples de

remontées d’informations qui suivent.

Un transfert de compétence doit être prévu pour permettre à la DSI d’être autonome sur l’ajout de

nouvelles remontées d’information basées sur le même principe.

Logiciel « Frais de déplacement » 7.5.1.

Exemples de remontée d’information

Alizé Votre état de frais numéro E0291654 est en attente de validation

Alizé Votre état de frais numéro E0291654 est validé par la RH

Alizé Votre état de frais numéro E0291654 est en pré-mandatement à la DAF

Alizé Votre état de frais numéro E0291654 est mandaté

Le numéro de l’état est un lien pointant vers l’application (http://srvms235.cg63.fr/FDD).


« Frais de déplacement ». Les informations host, sid, port, login et mot-de-passe seront

fournies.

http://srvms235.cg63.fr/FDD






La requête SQL d’extraction de la donnée sera fournie. Elle nécessitera en paramètre le login

ou le matricule de l’agent.

Logiciel « Demandes de renfort » 7.5.2.


Renforts Votre demande de renfort numéro 1265_20130911083154 est en attente de validation par Alain Aubert (directeur)

Renforts Vous avez 3 demandes de renfort à valider en tant que directeur

Renforts Vous avez 2 demandes de renfort à valider en tant que DGA

Renforts Vous demande de renfort numéro 1265_20130911083154 a été validée par Philippe Bernaz (DGA)

Le numéro de la demande est un lien pointant vers l’application

(http://srvms235.cg63.fr/Formulaires).


« Demandes de renfort ». Les informations host, sid, port, login et mot-de-passe seront

fournies.



Logiciel « Intentions d’achats » 7.5.3.


AAPC Vous avez 2 intentions d’achat en attente d’attribution

AAPC Votre intention d’achat numéro E0335262 est en attente de publication

AAPC Votre intention d’achat numéro E0335262 est en cours de publication

AAPC Votre intention d’achat numéro E0335262 est en fin de publication

Le numéro de la demande est un lien pointant vers l’application

(http://srvms235.cg63.fr/AAPC).


« Demandes de renfort ». Les informations host, sid, port, login et mot-de-passe seront

fournies.



http://srvms235.cg63.fr/Formulaires

http://srvms235.cg63.fr/AAPC










FIN DU DOCUMENT