Cahier des charges fonctionnel

Gestion de Flux Citoyens

2012
 - 2/19 - Cahier des charges fonctionnel
mars 2012

Table des matires

1Introduction....................................................................................................3
1.1 Contexte gnral du projet...............................................................................3
1.2 Limite de l'offre progicielle actuelle..................................................................4
2Prsentation gnrale du libriciel web-GFC...................................................5
2.1 Architecture gnrale et notions structurantes de web-GFC...........................5
2.2 Spectre fonctionnel gnral du libriciel............................................................5
2.3 Gestion des habilitations..................................................................................7
2.4 Administration de l'application..........................................................................8
2.4.1 Gestion de la collectivit.......................................................................................8
2.4.1.1 Services.........................................................................................................8
2.4.1.2 Profils............................................................................................................8
2.4.1.3 Utilisateurs.....................................................................................................9
2.4.2 Gestion des circuits..............................................................................................9
2.4.2.1 tapes.........................................................................................................10
2.4.2.2 Utilisateurs...................................................................................................10
2.4.3 Gestion des types et sous-types........................................................................11
2.4.4 Gestion des donnes descriptives (mtadonnes)............................................11
2.4.5 Gestion des dossiers / affaires...........................................................................12
2.5 Les grandes fonctions de gestion..................................................................13
2.5.1 Gestion des flux entrants....................................................................................14
2.5.2 Gestion des flux sortants....................................................................................15
2.5.3 La fonction consultation (recherches)................................................................15
2.5.4 La fonction d'export GED/SAE...........................................................................16
2.6 Visualisation des flux......................................................................................16
2.6.1 Vision globale des flux........................................................................................16
2.6.2 Vision personnelle des flux.................................................................................17
3Environnement technique et performances requis.......................................18
4Alotissement.................................................................................................18
4.1 Lot 1...............................................................................................................18
4.2 Lot 2...............................................................................................................19
4.3 Lot 3...............................................................................................................19
 - 3/19 - Cahier des charges fonctionnel
mars 2012

1 Introduction

1.1 Contexte gnral du projet

La gestion du flux prend une place part dans les processus d'instruction et de gestion
des collectivits territoriales.
La dmatrialisation lui donne une toute nouvelle place, eu gard au nombre de
correspondances produites quotidiennement par les collectivits comme du fait du trs
grand nombre de flux qui sont reus chaque jour par les collectivits.
Un flux appelle des actions, met en musique de nombreux acteurs et services dans la
collectivit. Tout flux a donc un impact fort dans l'ensemble du systme d'information de la
collectivit (gestion financire, gestion des administrs, gestion des services techniques,
services gestion du protocole et du cabinet, gestion des actes administratifs, GED et
documentation, signature lectronique, archivage lectronique....).
Son aptitude communiquer et son ouverture sont donc tout fait dterminants, comme
son ergonomie qui doit tre la plus efficient et la plus simple possible, compte tenu du
nombre de gestionnaires qui sont amens le manipuler.
Ce grand nombre d'acteurs concerns, comme la confidentialit de certains processus,
induisent la ncessaire gestion fine des habilitations de l'outil cibl, tant sur le plan des
fonctions que sur celui des donnes.
La combinaison de l'ensemble de ces facteurs et rcentes volutions du contexte de
gestion, amnent les collectivits rorganiser leurs processus d'instruction du flux,
comme d'ailleurs la gestion d'autres documents entrants dans la collectivits (factures,
mails, fax ).
Certaines de ces pices, doivent faire l'objet d'instruction, d'indexation, de recherches et
sont amenes tre manipules dans diffrentes procdures de dmatrialisation.
Dans ce contexte et eu gard la relative obsolescence de l'offre diteur actuellement
constate (sur le plan technologique en particulier), l'ADULLACT initie une dmarche
collaborative avec un certain nombre de ces membres visant :
dfinir les contours techniques et fonctionnels d'une application ouverte et
communicante de gestion de flux dpose sous licence libre.
constituer un groupe de travail reprsentatif et prenne, susceptible de valider les
travaux d'ensemble et de mettre en uvre la solution rsultante titre exprimental
et validatoire.
Dfinir un plan de financement des dveloppements ou adaptation de logiciels
existants afin de rpondre au besoin ainsi dfini.
assurer la publication et la communication des travaux collaboratifs du groupe.
assurer la logistique, l'animation et la coordination des sessions de travail.
L'enjeu technologique vise donc doter la collectivit d'un outil en technologie Web,
ouvert, permettant d'tablir des connecteurs avec des logiciels mtiers utiliss par les
collectivits territoriales pour mettre en uvre la dmatrialisation (parapheurs
 - 4/19 - Cahier des charges fonctionnel
mars 2012

lectroniques, GED, plate-forme d'changes scuriss et SAE) et prenant galement en

compte les dernires volutions des pratiques de gestion, en matire d'change de textes
(SMS, PDA, mails, fax, fichiers de natures diverses, etc.).

1.2 Limite de l'offre progicielle actuelle

Sur le march, il existe des logiciels mtiers libres et d'autres non libres. Les logiciels
libres existants proposent une gestion de courriers essentiellement ; ils traitent l'affichage
simplement et intuitivement via un affichage de bannettes (par exemple mes flux
traiter , mes flux en retard ...).
Un de leur point faible est l'absence de gestion de circuits de traitement la fois puissant
et souple ; l'administration n'est pas toujours ni intuitive, ni flexible : la complexit est
parfois lie aux frameworks utiliss ou aux mthodes de programmation.
Les adaptations organisationnelles demeurent donc complexes, pour un domaine pourtant
fortement dpendant des rorganisations rgulires des collectivits.
Les logiciels propritaires proposent une envergure fonctionnelle trs large et trs
complte; L'adhrence certains outils de bureautique MS est parfois un frein leur mise
en uvre en environnement bureautique OOo.
Dans la plupart des cas, il existe un dficit d'ouverture vers les SAE et/ou les systmes de
GED transverses ou vers les parapheurs.
 - 5/19 - Cahier des charges fonctionnel
mars 2012

2 Prsentation gnrale du libriciel web-GFC

2.1 Architecture gnrale et notions structurantes de web-GFC

web-GFC devra proposer les avantages offerts par d'autres outils actuellement
disponibles sur la Forge Adullact.
Il est compos de :
logiques de traitements mtier
de webservices pour permettre les changes entre applications tierces
d'un module de traitement de workflow de traitement
d'un gnrateur de documents bas sur un moteur OOo

2.2 Spectre fonctionnel gnral du libriciel

Le libriciel doit permettre la gestion de flux depuis leur cration jusqu' leur validation,
avec gestion des modles de rponse et accus de rception, et leur archivage.
La solution doit permettre de prendre en compte les diffrents types de flux amens
tre traits aujourd'hui comme demain par les collectivits, (courrier papier, mail, fax mais
aussi les flux mergents comme les messages vocaux, SMS...).
Les objectifs gnraux du libriciel sont les suivants :
suivi et classement des courriers entrants et sortants
 - 6/19 - Cahier des charges fonctionnel
mars 2012

amlioration du dlai de rponse des flux entrants

amlioration du qualitatif rponse dans les cas ou plusieurs services sont
concerns par les rponses
assurer la traabilit d'un courrier
mesurer les dlais
simplifier les autres projets de dmatrialisation
rduire les volumes de papier et les surfaces de stockage, les cots de rexpdition
du courrier entre les diffrents sites, rationaliser la circulation des documents

Les fonctions majeures de l'application sont :

Gestion des courriers entrants
Gestion des courriers sortants
Regroupement des courriers entrants et sortants dans des notions de type
dossiers ou affaires
Gnration des courriers partir de modles d'dition
Lien avec un OCR pour la numrisation
Gestion de formulaires
Gestion des mtadonnes
Lien avec la plate-forme d'changes scuriss PASTELL et d'autres plate-formes
de mme nature (via webservices)
Lien avec l'outil de signature lectronique i-parapheur et d'autres plate-formes de
mme nature (via webservices)
Liens avec la GED ALFRESCO et autres GED (via des exports normaliss
comprenant des fichiers et des metadonnes permettant d'alimenter
dynamiquement des plans de classement pr-dfinis)
Exports avec le SAE As@lae et autres SAE bass sur le SEDA et sur le modle
OAIS
Prise en compte des messages audio et vido
Prise en compte de messages tlphoniques de type sms/mms
Lien avec les messageries (OPO, IMAP) pour tout change d'informations:
possibilit de rcupration des messages et des e-mails en tant que type
particulier de courrier,
possibilit d'envoyer des messages dans la messagerie (par exemple: message
de relance sur une action non ralise dans les dlais impartis, notification,
etc..).
possibilit de rcuprer des mails partir de fax ou de messages vocaux.
Des interfaces doivent pouvoir tre mises en place :
avec l'annuaire en place de la collectivit (type LDAP, AD)
avec l'application du rpertoire tlphonique
Un module administration doit permettre :
une gestion des profils
une gestion des utilisateurs
une gestion des droits sur les fonctions et sur les donnes
une gestion du traitement
une gestion multi-collectivits
Moteur de workflow pour le traitement des demandes
 - 7/19 - Cahier des charges fonctionnel
mars 2012

Pouvoir personnaliser quelques champs de donnes disponibles (meta donnes),

Disposer de zones de commentaires libres

Pour cela, le libriciel proposera :

Un module d'administration simple et une gestion multi-collectivits permettant
la mutualisation
Une sphre de confidentialit as@lae
Une confidentialit des donnes lies aux typologies de flux et l'tanchit des
services
La confidentialit rigoureuse de certaines typologies de flux (exemple : courriers
du cabinet).
Le logiciel sera adaptable toute typologie de flux et tout modle d'organisation
interne (les collectivits utilisatrices pourront dcider des zones de saisie qu'elles
souhaitent inclure dans le cycle d'instruction)
Son IHM sera la fois simple, intuitive et contextualise (adapt aux cadres
comme aux agents chargs de l'instruction)
L'outil pourra voluer vers d'autres langues

2.3 Gestion des habilitations

Il s'agit de l'ensemble des fonctions permettant dassurer lexploitation du systme ainsi
que la gestion des utilisateurs (droits daccs).
Afin de permettre la mise en uvre d'un niveau de confidentialit pouss sur les donnes,
les habilitations doivent tre dfinies sur le plan des fonctions comme sur celui des
donnes (nature des courriers), ainsi qu'au niveau des circuits de traitement.

Ce systme est fondamental puisqu'il sera la base de toute automatisation des transferts
vers les systmes de GED et de SAE en aval.

Chaque profil ainsi dfini, devra pouvoir tre associ un systme de mtadonnes
renseigner, pralablement dfini dans la sphre d'administration de l'application.

Une notion de groupe d'utilisateurs doit exister, afin de permettre la dfinition de droits
d'accs commun dfinis sur le groupe d'utilisateurs; chaque nouvel utilisateur hrite par
dfaut des droits de son regroupement.
L'utilisateur disposera donc aprs connexion d'un accs ses espaces et ses fonctions :
Navigation dans son espace (donnes accessibles, mtadonnes associes)
Oprations autorises

L'identification sera effective lorsque l'utilisateur s'authentifiera sur la page d'accueil de

l'application l'aide de son identifiant et de son mot de passe, via liaison LDAP ou via
liaison directe la base de donnes de l'application (comme toutes les informations
relatives aux utilisateurs qui transiteront dans l'outil).
La personne connecte l'application, une fois identifie, sera dirige vers sa page
d'accueil personnelle.
Les rubriques de la page pourront tre les suivantes :
 - 8/19 - Cahier des charges fonctionnel
mars 2012

nouveaux flux traiter qui le concernent

liste des flux de son service
liste des notifications le concernant
liste des tches traiter
...

Ces niveaux peuvent tre mis en place par individus ou par groupe d'individus, selon les
fonctions disponibles (consultation, modification, suppression, ...), les thmes et les zones
confidentielles, avec un paramtrage ais.

L'administrateur fonctionnel de la collectivit aura en charge l'tablissement des

rfrentiels (dfinition des circuits du workflow avec les diffrentes tapes et leur dlai
respecter, ...).

2.4 Administration de l'application

Le module d'administration de l'application permet de dfinir un grand nombre de
fonctionnalits. Il va permettre de paramtrer l'application pour une collectivit donne.

2.4.1 Gestion de la collectivit

L'administrateur fonctionnel de la collectivit va pouvoir dfinir la structure de sa
collectivit :
liste des services
liste des rles pouvant tre attribus chacun des utilisateurs
liste des utilisateurs, lis chaque service

2.4.1.1 Services
Chaque collectivit possde une liste de services hirarchise. Chaque service enfant
est li son service parent et va, sa cration, hriter des droits de son parent.
L'administrateur peut crer autant de service qu'il le souhaite.

2.4.1.2 Profils
Une liste de profils (rles jous par un agent au sein de la collectivit) est galement
fournie par l'application :
aiguilleur agent charg de la rpartition des diffrents documents dans chacun
des services concerns (ex : le service courrier)
initiateur agent qui va retrouver dans sa bannette les documents (de son service)
envoys par l'aiguilleur
valideur agent charg de la validation du flux
valideur-diteur agent charg de la validation et qui possde galement les
droits de modification sur le flux
documentaliste agent charg d'archiver les flux en fin de traitement

Chaque profil possde des droits la fois sur les donnes (mtadonnes, types/sous-
types, ...) et sur les fonctionnalits de l'application (actions possibles : ajout, dition,
 - 9/19 - Cahier des charges fonctionnel
mars 2012

suppression, ).
Il sera possible de crer un profil personnalis afin que chaque administrateur puisse
dfinir un profil particulier qui ne serait pas couvert par ceux proposs par l'outil.

2.4.1.3 Utilisateurs
L'administrateur peut galement crer autant d'utilisateurs qu'il le souhaite.
Un utilisateur est li un ou plusieurs services et peut jouer un ou plusieurs rles.
Pour cela, lors de la cration de l'utilisateur, l'administrateur devra associer l'utilisateur
un rle principal, et pourra dfinir des rles particuliers (et/ou temporaires). Ceci afin de
permettre la fois de pouvoir dlguer les flux qu'il traite en cas d'absence et galement
afin de pouvoir grer diffrents types de flux.
Par exemple, un agent peut tre uniquement valideur pour le type de flux demande de
subvention, mais valideur-diteur pour le type de flux demande de candidature.

2.4.2 Gestion des circuits

Chaque collectivit va pouvoir dfinir ses propres circuits de traitement.
Le libriciel sera adaptable toute typologie de flux et tout modle d'organisation interne.
Le moteur intgr de workflow est propre a la gamme les libriciels et est utilis par les
applications WebDELIB et as@lae.
Il permet les affectations de traitements simples, concurrentes ou collaboratives :
Simple M. X est charg de l'tape d'instruction,
Concurrente M. X ou Mme Y du service comptable: il suffit que l'une de ses deux
personnes valide le flux pour que celui-ci passe l'tape suivante,
Collaborative M. X et Mme Y : pour passer l'tape suivante, les deux
utilisateurs doivent valider.

Chaque circuit de traitement sera li un ou plusieurs sous-types (cf Gestion des types et
sous-types).
En plus de ces diffrents types de traitement, tout comme dans web-delib, il sera possible
de raliser des rebonds.
En effet, Dans web-delib, plusieurs fonctions de drivation existent. Ces fonctions seront
reprises afin de permettre la modification d'un circuit en cours de traitement.
 - 10/19 - Cahier des charges fonctionnel
mars 2012

Deux cas seront pris en compte :

1. la possibilit de retourner un flux une tape antrieure du circuit en cours ;
2. la possibilit de pouvoir adresser un flux un agent extrieur au circuit. Plusieurs
mthodes seront prsentes :
envoyer avec aller-retour (boomerang): le flux reviendra dans la bannette de
l'acteur en cours (celui qui a dclench la drivation) aprs action de l'agent
extrieur ;
envoyer sans aller-continuer (dtour) : le flux continuera son circuit aprs action
de l'agent extrieur. C'est comme si on avait insr une tape dans le circuit ;
envoyer sans retour (dtournement) : le flux est envoy vers un agent extrieur.
Une fois le flux trait par cette personne, il ne revient pas : soit cet agent clos le
flux, soit il le redirige (dtournement) vers une nouvelle personne.

2.4.2.1 tapes
Lors de la cration du schma du circuit, plusieurs tapes peuvent tre ajoutes. Lors de
l'ajout d'une tape, deux donnes obligatoires sont renseigner :
l'intitul de l'tape
le type d'tape (simple, concurrente ou collaborative).

Les tapes peuvent tre rordonnes par le biais d'un simple bouton.

2.4.2.2 Utilisateurs
A chaque tape d'un circuit, on a la possibilit d'ajouter ou de supprimer un ou plusieurs
utilisateurs (selon le type d'tape : un seul en tape simple, un ou plusieurs pour les cas
concurrents et collaboratifs)
Les utilisateurs associables une tape de circuit sont des utilisateurs dont le rle n'est ni
initiateur, ni aiguilleur et qui ne sont pas dj lis cette mme tape.
 - 11/19 - Cahier des charges fonctionnel
mars 2012

Lors de la slection de l'utilisateur, si ce dernier possde plusieurs rles, il faudra dfinir le

rle qu'il jouera l'tape en question.

2.4.3 Gestion des types et sous-types

Tout comme les circuits, chaque collectivit va pouvoir dfinir ses propres types et sous-
types.
Les types sont des regroupements de sous-types. La seule information renseigner est
l'intitul du type.
Une fois le type cr, l'utilisateur va lui associer un sous-type. A la cration, les
informations devant tre renseignes sont :
un nom
l'association un type
l'association un circuit
le dlai de traitements
s'il s'agit d'un sous-type entrant ou sortant
la dfinition d'un compteur

Ces sous-types ont un rle prpondrant dans l'application. Ils vont tre utiliss afin de :
Grer des dlais de traitements associs aux typologies de flux
Assurer une gestion dynamique et distribue des mtadonnes (dfinies pour
chaque typologie de flux avec association aux agents chargs de leur
renseignement)
Produire des rponses types sur la base de modles associs chaque type de
flux
Grer des modles de rponses types
Prendre en compte les diffrents types de flux traits aujourd'hui par les
collectivits (courrier papier, mail, fax, ) en prenant en compte les flux mergents
(messages vocaux, SMS, )
Joindre un fichier en fonction du type (par exemple un pdf pour une candidature),
un mode texte (pour les appels tlphoniques), un fichier son,

Tout flux cr dans web-GFC doit tre typ. En effet, afin de pouvoir insrer ce flux dans
un (le bon) circuit, il faut dterminer quel type/sous-type il correspond. De ce fait, le flux
sera insr dans le circuit dfini en amont et il sera plus simple de pouvoir le suivre.

2.4.4 Gestion des donnes descriptives (mtadonnes)

Les mtadonnes sont les informations qualifiant un courrier entrant comme sortant.
Ces informations doivent servir aux utilisateurs habilits comme point dentre et
permettre de retrouver les donnes quils recherchent. Elles servent galement de base
lors des exports vers les systmes de GED et/ou d'archivage lectronique (positionnement
dans le plan de classement et mtadonnes des bordereaux de versement.
Les mtadonnes servent galement la recherche des courriers enregistrs, les
principales dj identifies sont les suivantes :
 - 12/19 - Cahier des charges fonctionnel
mars 2012

Liste - non exhaustive - des informations prvoir dans le cadre du formulaire de

saisie des courriers dpart et arrive :
Nom de lorganisme expditeur / Direction / Service, accessible depuis un
annuaire des contacts
Le type du courrier (demande de subvention, demande dintervention,
rclamations, note de service) : liste droulante prdfinie et entirement
paramtrable
Numro denregistrement : N de chrono, champ UNIQUE renseign
automatiquement par le systme
Rfrence : champ texte libre
Date denregistrement du courrier (slection dans un calendrier)
Objet du courrier : reprise de lexistant sur le document (un thsaurus doit
pouvoir tre constitu pour faciliter lutilisation de la fiche recherche)
Description ou commentaires sur le courrier,
Date dchance de traitement du courrier, (slection dans un calendrier)
Date dalerte avant le dlai thorique du traitement
Type denvoi (normal, recommand, recommand avec AR)
Destinataire arrive en envisageant plusieurs destinataires (sans limite) et en
envisageant pour chacun dentre eux la mention pour attribution avec suite
donner, pour information. Cette liste dactions possibles devra tre paramtrable
Mots cls,
Pices jointes (numriques ou non),
Des champs libres paramtrables selon le besoin.
Certains de ces champs devront pouvoir tre dfinis en saisie obligatoire.
Informations gnres par le logiciel ou proposes automatiquement
lenregistrement :
Code courrier (n de chrono interne)
Date denregistrement (date du jour par dfaut),
Informations lies au traitement ultrieur des courriers :
Dlai thorique de ralisation en fonction du type de courrier,
Dlai dalerte avant le dlai thorique
Caractre durgence,
Service et / ou personne attributaire,
Actions ralises,
tat du courrier (enregistr, en cours de traitement, en attente, en retard,
cltur,)
Mots cls
Mtadonnes archivistiques

2.4.5 Gestion des dossiers / affaires

En fin de circuit, il sera possible de classer des flux dans des affaires et/ou dossiers
d'affaires :
 - 13/19 - Cahier des charges fonctionnel
mars 2012

Les affaires sont des regroupements de flux.

Les dossiers d'affaires sont des regroupements d'affaires.

Cette fonctionnalit permet de lier des flux les uns aux autres. Comme dcrit
prcdemment, un flux est li un type/sous-type, lui-mme li un circuit. Dans le cas
o plusieurs flux (typs diffremment donc appartenant des circuits diffrents)
concernent la mme personne, ou la mme affaire , il sera possible de les lier les uns
aux autres en les associant la mme affaire. Du coup, si on effectue une recherche sur
une affaire particulire, l'ensemble des flux lis cette dernire ressortiront.
Dans la mme ide, les dossiers vont regrouper un ensemble d'affaires
Il sera donc possible de classer un ensemble d'informations communes par le biais de ces
2 fonctionnalits.

2.5 Les grandes fonctions de gestion

Le libriciel doit proposer les phases de traitement suivantes :
Une phase de numrisation, de saisie ou de dpt/entre des documents (ex via
PASTELL)
Une phase daffectation qui consiste dterminer le circuit du courrier, saisir les
mtadonnes adaptes
Une phase de traitement (qui peut s'accompagner d'une rponse et qui
s'accompagnera de la clture du dossier/de l'affaire).
Une phase d'export vers la GED /le SAE

Comme dcrit dans le schma d'Architecture gnrale et notions structurantes de web-

GFC (cf 2.1), un couplage avec PASTELL, permettra de rcuprer tout dpt sur la plate-
forme (cas des courriers relatifs une demandes citoyennes).
 - 14/19 - Cahier des charges fonctionnel
mars 2012

2.5.1 Gestion des flux entrants

Enregistrement d'un courrier arriv

Prvoir une saisie rapide (limitation aux seules donnes utiles)
Saisie dans les services (responsabilisation) ce qui revient lier le dossier un
ou plusieurs groupes ou utilisateurs suivant les besoins.
Plusieurs types de courrier "arrive": le terme courrier doit tre tendu aux notes
papier, notes de messagerie lectronique, FAX, e-mail, notes de conversations
tlphoniques
Possibilit de rcupration au cas par cas des messages et des e-mail de la
messagerie, ventuellement, leurs fichiers joints.
Informations ncessaires: identification de l'metteur, type et date du courrier, objet,
date de rception, notions de classement (dossier, thme...), mots-cls.
Existence d'une zone de saisie Demande d'intervention regroupant toutes les
informations requises pour rgler le problme signal.
Existence dune zone de commentaires lie au module de scurit permettant la
saisie et la consultation de notes internes au service concern.
Un courrier ''arrive'' devra pouvoir tre rattach un autre courrier ''arrive''.
Un Accus de rception sera gnr en fin de traitement, accessible avant insertion
dans un circuit.

Affectation d'un courrier arrive :

II peut tre affect un circuit de traitement ou un destinataire directement.
Un destinataire est un lment de l'organigramme hirarchique des services de la
collectivit :
soit au niveau d'une cellule de l'organigramme (groupes d'agents): direction
 - 15/19 - Cahier des charges fonctionnel
mars 2012

gnrale, direction centrale, service

soit au niveau d'un agent particulier.

Adaptation obligatoire de l'outil la structure hirarchique de la collectivit et ses

ventuelles volutions dans le temps : clatements ou regroupements de services.
Ce courrier arrive pourra galement tre diffus pour information une liste d'agents
''en copie''.
Informations ncessaires : date de transmission, identification des destinataires, type
d'action attendu des destinataires (avis, excution ...), date d'chance pour l'action
attendue.
Pouvoir attacher le courrier scann (une ou plusieurs pages) son enregistrement
synthtique: tous les destinataires du courrier peuvent alors le visualiser.

2.5.2 Gestion des flux sortants

Le logiciel sera capable de gnrer des courriers de rponse, de manire automatique ou
via une saisie manuelle.
L'dition et la mise en page des courriers se fera par fusion documentaire grce
GED'OOo et des modles d'dition pr-enregistrs (documents modles).
Un courrier dpart devra pouvoir tre rattach un ou plusieurs courriers arriv .
Le processus courrier Dpart est le suivant :
Enregistrement du courrier Dpart
Numrisation des pices jointes ventuellement
Rattachement des courriers Dpart au circuit de traitement et validation, avec
possibilit de retour et de rorientation
Validation et signature lectronique du courrier Dpart le cas chant (lien avec
le i-parapheur)
Envoi du courrier Dpart , impression, courriel, fax
Versement du courrier vers la GED /le SAE

L'outil exploitera l'API SLOW mails scuriss pour assurer l'envoi dmatrialise et trac
avec AR, autoriss par le systme.
De mme, il autorisera le dpt de rponse sur la plate-forme PASTELL.

2.5.3 La fonction consultation (recherches)

La pratique quotidienne d'une application de cette nature par de nombreux services et par
des acteurs varis et souvent occasionnelle au sein d'une collectivit, implique la
manipulation aise et une Interface Homme Machine particulirement intuitive.
La pertinence des instruments de recherche des documents types, des flux stocks est
un des points ergonomiques majeurs d'une application de gestion de flux.
Ces documents doivent donc pouvoir tre recherchs, tris, obtenus, et exploits de
multiples manires, le plus intuitivement possible.
 - 16/19 - Cahier des charges fonctionnel
mars 2012

Des grilles de slections et de recherches, sur la base de critres combins s'appuyant

sur les champs d'indexation significatifs des grilles de saisie propres chaque document
slectionn, doivent donc tre proposes par l'application.
La recherche doit pouvoir se faire par le biais des critres suivants :
Par intitul (nom) du flux
Par dates d'entre et de sortie du flux
Par date de rception du flux
Par nom du contact li au flux
Par type de flux
Par sous-type de flux
Par mtadonnes
Par circuits
Par dossiers
Par affaires
Par tches

Le rsultat de toute recherche peut tre imprim (pdf) ou export vers un tableur (csv).
Il sera galement possible d'enregistrer des recherches personnalises pour permettre
l'utilisateur de stocker les critres qu'il utilise frquemment et de pouvoir les rutiliser
ultrieurement.

2.5.4 La fonction d'export GED/SAE

A l'issue de toute phase de saisie, d'import de scan ou plus largement de traitement de
circuit d'instruction, le logiciel permettra la clture de l'instruction d'un dossier (les
lments qui y figurent ne sont plus modifiables et seul les ajouts de documents sont
possibles).
La notion de dossier ou d'affaire figure en tant que mtadonnes dans le logiciel .
La clture d'un circuit de traitement activera les fonctions d'exports vers la GED
ALFRESCO ou les fonctions d'export vers le SAE.
Le logiciel permettra de gnrer un message mail au service(s) instructeur(s) afin de leur
indiquer qu'un export du dossier a t ralis vers la GED (avec l'adresse du lien
correspondant).

2.6 Visualisation des flux

2.6.1 Vision globale des flux

Une vision globale de tous les flux par agent sera accessible pour certaines habilitations
(de prfrence le service centralisateur (service des courriers par exemple)), diffrenciant
les flux traits de ceux qui ne le sont pas encore (classs par bannettes).
Pour les flux non traits, il sera alors possible de les slectionner et de les traiter .
 - 17/19 - Cahier des charges fonctionnel
mars 2012

2.6.2 Vision personnelle des flux

Un flux concernant l'utilisateur identifi (valideur) correspond :
la personne identifie est valideur du flux
la personne identifie est dans le circuit de validation du projet
la personne identifie appartient au service courrier

L'utilisateur identifi aura accs aux flux le concernant via une interface qui lui permettra
de visualiser l'tat d'avancement des flux dans les diffrents circuit de validation.
Lorsqu'un flux lui arrivera pour qu'il le traite, il aura accs l'interface de traitement du flux
qui rcapitulera les diffrents champs pralablement saisis par l'initiateur, en donnant
galement accs aux pices jointes.
Les diffrents tats possibles pour un flux seront :
A traiter : le flux est en possession de la personne identifie, elle peut accder
l'interface de traitement du flux afin de continuer le circuit de validation
Trait : le flux est en aval de la personne identifie dans le circuit de validation
(la personne identifie trait le flux) mais n'a pas encore termin le circuit de
validation
Valid : le flux a termin le circuit de validation, il a t valid par le service
centralisateur (service des courriers)
Refus : le flux a t refus

L'utilisateur identifi pourra valider le flux afin que ce dernier continue le chemin de
validation, ou bien le refuser. Dans ce dernier cas, le flux reculera dans le circuit de
validation.
En cas de refus, il sera possible de notifier par mail toute ou partie des personnes
prsentes dans le circuit de validation.
Il sera galement possible de slectionner la personne laquelle on dsire renvoyer le
flux. Par dfaut, il s'agira de l'initiateur.
Si le flux est valid par la personne identifie, son tat passera Trait . S'il est refus,
son tat passera Refus
L'utilisateur, au moment du traitement du flux, aura la possibilit de rajouter un
commentaire avant de valider ou de refuser le dossier.
Les notifications par mail et dans l'application seront galement mises en place pour
avertir une personne de l'arrive d'un nouveau flux traiter le concernant.
 - 18/19 - Cahier des charges fonctionnel
mars 2012

3 Environnement technique et performances requis

Le systme devra garantir les temps de rponse et des performances gnrales
compatibles avec les besoins des utilisateurs.
Pour les oprations ralises en temps rel (transactions courantes), les temps de
rponse souhaits sont infrieurs 1 seconde. Pour les oprations pouvant tre
effectues en lger diffr (recherches, tats ), les temps de rponse souhaits doivent
tre infrieurs 5 secondes.
Dans un souci constant de performance et dans un contexte de matrise des cots,
l'application doit tre en mesure d'tre installe sur des clients lgers (PCs munis d'un
navigateur Web de type Mozilla Firefox et d'Acrobat Reader).
Les O.S clients supports devront prfrentiellement tre ceux du monde Open Source
(Linux), mais le fonctionnement doit demeurer possible dans un environnement
propritaire Microsoft.
Les technologies LAMP et J2EE (serveurs d'applications libres) sont privilgies.
Il en est de mme pour les bases de donnes supportes qui seront sous PostGreSQL.
En revanche, la modlisation de l'application sera obligatoirement faite en UML afin de
standardiser les changes mais surtout permettre l'usage de gnrateur de code partir
du modle valid.

4 Alotissement
Le libriciel se prsente sous diffrents lots.

4.1 Lot 1
Les diffrentes fonctionnalits prsentent dans le lot 1 sont les suivantes :
Confidentialit et administration
Typage / sous-typage des flux
Workflow de traitement (CakeFlow)
Gestion des mtadonnes et intgration de thsaurus
Fusions documentaires
Typage des destinataires
Recherches multi-critres
Fonction de numrisation en entre
Couplage avec PASTELL
 - 19/19 - Cahier des charges fonctionnel
mars 2012

4.2 Lot 2
Les diffrentes fonctionnalits prsentent dans le lot 2 sont les suivantes :
Fonctions d'export CMIS
Export as@lae
Couplage unitaire et par lots avec le i-parapheur

4.3 Lot 3
Les diffrentes fonctionnalits prsentent dans le lot 3 sont les suivantes :
Imports de masse et fonction OCR
Exports mails scuriss (SLOW)
Exports autres serveurs de flux