Cahier des charges fonctionnel Libriciel DELIB · PDF fileCahier des charges – libriciel DELIB v.2.1 - 2 - 1. ... L'administrateur fonctionnel (par exemple le secrétariat de l'assemblée

Cahier des charges – libriciel DELIB v.2.1

Cahier des charges fonctionnel

Libriciel DELIB

Version 2.1

Table des matières1. Aspects fonctionnels clés de la solution ciblée...............................3

1.1. Spectre fonctionnel général du libriciel....................................31.2. Gestion des habilitations.........................................................31.3. Préparation des projets de délibération...................................41.4. Validation des projets de délibération......................................61.5. Visualisation des projets.........................................................7

1.5.1. Vision globale des projets................................................................71.5.2. Vision personnelle des projets.........................................................7

1.6. La gestion de la session de l'assemblée délibérante.................81.6.1. Le calendrier....................................................................................81.6.2. Gestion de l'ordre du jour................................................................81.6.3. Envoi des convocations....................................................................91.6.4. Gestion des présences.....................................................................91.6.5. Gestion des votes..........................................................................10

1.7. La transmission au contrôle de légalité..................................101.8. Suivi, indexation, recherche..................................................111.9. la transformation des délibérations format en pdf/a ..............11

2. Principes ergonomiques à prendre en compte..............................122.1. Les outils de recherche dans l'application..............................122.2. Les liaisons avec la bureautique............................................122.3. Éditions et états...................................................................12

3. Environnement technique et performances requis........................14

Cahier des charges – libriciel DELIB v.2.1- 2 -

1. Aspects fonctionnels clés de la solution ciblée

1.1. Spectre fonctionnel général du libriciel

Le libriciel doit permettre l'instruction des délibérations depuis la rédaction des projets (rapports) jusqu'au contrôle de légalité, avec gestion de la publication des actes et leur archivage.

La solution doit permettre de gérer la vie des assemblées délibérantes, avec la liste des élus, des rapporteurs, des délégations et des membres des différentes commissions de façon indépendante pour chaque mandature (le système d'indexation et de recherche doit permettre un accès aux données de toutes les mandatures).

Les objectifs généraux du libriciel sont les suivants : – assurer la traçabilité des dossiers de leur création à leur archivage– diminuer les transmissions papier– raccourcir les délais de validation des dossiers– fournir une visibilité sur l'état d'avancement des dossiers aux personnes concernées– assister les utilisateurs en automatisant la production des différents documents– faciliter la recherche de documents

Les fonctions majeures de l'application sont :– Création du projet/rapport de délibération– Gestion des droits utilisateurs– Gestion de l'ordre du jour des sessions d'assemblée(s) délibérante(s)– Validation des projets de délibération– Gestion de l'assemblée délibérante– Suivi, indexation et recherche des délibérations– Publication des délibérations– Édition de documents– Liens bureautiques– Transmission au contrôle de légalité– Export dans l'outil de Gestion Électronique de Documents– Génération automatique de CD-ROM fournissant tous les éléments de chaque séance

1.2. Gestion des habilitations

La solution mettra en place différents niveaux d'habilitation concernant les droits utilisateurs. 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 données de l'application (comme toutes les informations relatives aux utilisateurs qui transiteront dans l'outil).La personne connectée à l'application, une fois identifiée, sera dirigée vers sa page d'accueil personnelle.

Cette page d'accueil personnalisée comportera les nouveaux évènements dont l'utilisateur aura, lors du paramétrage de l'application, souhaité être notifié au moment de sa connexion à l'outil.Les rubriques de l'accueil pourront être les suivantes :– nouveaux projets proposés qui le concernent, depuis sa dernière connexion à l'application – nouvelles sessions d'assemblées délibérantes programmées


– tâches à effectuer avec mention du degré d'urgence (dossiers à traiter, ...)– ...

Ces niveaux peuvent être mis en place par individus ou par groupe d'individus, selon les fonctions disponibles (consultation, correction, observation, annotation, visa), les thèmes et les zones confidentielles, avec un paramétrage aisé.

L'administrateur fonctionnel (par exemple le secrétariat de l'assemblée départementale) aura en charge l'établissement des référentiels (définition des circuits du workflow avec les différentes étapes et leur délai à respecter (qui pourront être calculées automatiquement avec le moteur de workflow), ...).

Les droits sur un projet de délibération pourront évoluer en fonction de l'étape d'avancement dans le workflow : par exemple, les modifications pourront être limitées après visa du DGS.

1.3. Préparation des projets de délibération

Le contenu des projets est plus ou moins détaillé selon les collectivités ; il reprend les champs obligatoires figurant sur la délibération finale et comprend une partie de justification du projet et des pièces annexes.

Les projets de délibération sont créés par les différents services des collectivités ; les projets mentionnent les informations suivantes :

– titre du projet de délibération– date de création (champ renseigné automatiquement)– service émetteur, à partir des données de l'annuaire LDAP– date de session de l'assemblée délibérante : date proposée et non obligatoire, elle sera

validée ou reportée par le service des assemblées– nom du rapporteur, à partir des données de l'annuaire LDAP – objet– numéro de saisie (numéro interne à la commune)– numéro de délibération (généré automatiquement (selon la norme de la préfecture))– thème de la délibération– texte du projet de délibération– texte de la note explicative de synthèse– pièces annexes / pièces jointes (avenants, contrats, plans, rapport, etc.)

Lorsqu'un service crée un projet de délibération, il saisit les champs mentionnés ci dessus, ainsi que le texte de la note explicative de synthèse. Dans les organisations déconcentrées, le service émetteur rédige le texte du projet de délibération.

Tous les champs du formulaire de création du projet de délibération seront paramétrables, modifiables et rendus obligatoires (ou non) par l'administrateur de l'application, via l'interface d'administration.L'application permettra la construction du formulaire de création d'un projet de délibération afin de l'adapter totalement au fonctionnement interne de la collectivité.

La liste des services sera un menu déroulant, ainsi que la liste des rédacteurs et la liste des rapporteurs. Le rédacteur aura la possibilité de s'ajouter dans la liste des rédacteurs s'il n'y figure pas. La liste des rapporteurs ne sera modifiable que par l'administrateur de l'application.Le rapporteur est un élu référent du service émetteur, il sera possible de le modifier selon les règles des droits utilisateurs, mais il devra figuré dans la base de données. Sa fonction devra être utilisable dans le workflow (il a le droit d'accéder au workflow).


La date de création du projet de délibération sera automatique renseignée et non modifiable. Le rédacteur aura la possibilité de proposer une date de session pour le passage du projet, en accédant au calendrier des séances répertoriant les séances prévues. Cette date sera définitive si elle est validée par le service des assemblées.

La liste des thèmes figurera dans un menu déroulant avec possibilité pour le rédacteur d'ajouter un thème si celui voulu n'existe pas.

Le système de numérotation du projet de délibération s'auto-incrémentera et sera paramétrable selon un modèle prédéfini par l'administrateur de l'outil en fonction du motif de numérotation utilisé par la collectivité.

Les zones de saisie pour le texte du projet et la note de synthèse donneront la possibilité de faire appel à un éditeur permettant de mettre en forme le texte et de saisir de façon plus aisée en ayant une vision plus globale du texte.

A titre alternatif et complémentaire au mode de création par formulaire, il sera également possible d'importer un fichier bureautique pour :– le texte d'un projet– le texte de la note de synthèse.

Il sera par ailleurs possible d'ajouter autant de pièces jointes que souhaitées.

Chaque projet sera identifié par des données renseignées automatiquement lors de sa création (date de création, date de dernière modification, service émetteur, rédacteur, rapporteur, etc.).

Le système créera un dossier correspondant à un projet de délibération, et associera au dossier les différents documents qui sont à sa disposition (bureautique, image, plans, etc.).

La création d'un projet de délibération par un service déclenchera une notification automatique au secrétariat général ou au service centralisateur via l'interface Web et par e-mail pour ajout du titre du projet à l'ordre du jour de la séance de l'assemblée délibérante. Cette notification devra s'accompagner des données renseignées automatiquement lors de la création du projet. Le corps de l'e-mail de notification contiendra un lien vers le dossier correspondant au projet de délibération.

Dès que l'enregistrement du projet de délibération aura été confirmé, le projet sera enregistré dans la base de données et la génération automatique du document bureautique correspondant sera effectuée. Le projet est consultable via un lien pointant vers le fichier.

Deux principes de génération sont possible :– le projet de délibération est généré au format PDF, donc non modifiable. On a cependant la

possibilité de modifier le projet via l'interface de l'application, et ainsi de re-générer le projet au format PDF.

– Le projet de délibération est généré au format bureautique RTF modifiable directement à partir de l'outil bureautique; il sera dans ce cas possible de laisser les champs texte du projet et texte de la note de synthèse vides et de saisir ainsi le texte du projet directement dans Open Office puisque l'utilisateur aura un accès en lecture et écriture sur son fichier.

Suite à la création du projet de délibération, il est demandé à l'utilisateur de mettre en place le circuit de validation pour le projet qu'il vient de rédiger.

L'ensemble des décisions prises lors de la session de l'assemblée délibérante et présenté en résumé à la session suivante, peut être considéré comme une « délibération particulière » et pourrait éventuellement être géré par la solution.


1.4. Validation des projets de délibération

Le circuit d'instruction inclut dans certaines collectivités la tenue d' « assemblées consultatives » de composition et de nature différentes selon les collectivités (bureau municipal pour les communes, groupement opérationnel pour les SDIS...) qui ont toujours une réelle importance dans le processus de décision, de préparation aux votes et d'arbitrage quand à l'inscription des actes à telle ou telle session de l'assemblée délibérante.

Après la saisie des différents éléments du projet de délibération, un workflow de validation est déclenché par le rédacteur, les différentes étapes étant déterminées par l'identité du service émetteur. Les circuits de validation seront des circuits de validation prédéfinis par l'administrateur de l'application. L'utilisateur n'aura alors qu'à sélectionner le circuit type qu'il désire attribuer au projet de délibération créé. Le circuit de validation sera visible graphiquement pour mettre l'accent sur la clarté et sur un aperçu plus global.Les dates limites de traitement des projets seront calculées automatiquement par le moteur de WorkFlow

Il faudra également une autonomie et un paramétrage possible dans le workflow afin de pouvoir « casser » l'ordre hiérarchique de base, afin de rajouter certaines étapes. Il sera également possible de rendre certaines étapes facultatives.

Le workflow de validation déclenche une notification automatique au destinataire à chaque étape de la validation de la note de synthèse. Si elle n'est pas validée, une notification sera renvoyée à l'émetteur avec un commentaire et des propositions de correction. L'émetteur pourra alors modifier le document et le soumettre à nouveau pour validation.

Il faudra que toutes les personnes présentes dans le workflow sachent où se trouve le projet de délibération à un instant donné. Le circuit sera visible obligatoirement via l'interface Web et l'ensemble des notifications pourront être envoyées par e-mail.

La modification de documents, ou les projets remis sur table seront accessible et possible selon les règles définies par les droits utilisateurs. La plupart du temps, si un service « viseur », c'est-à-dire au milieu du workflow, estime une modification, il pourra renvoyer le projet à l'expéditeur (c'est-à-dire au niveau précédent dans le workflow) et ne pourra pas le modifier. Cependant il pourra ajouter des commentaires.En cas de modification de la part du service des assemblées, un retour d'information via une notification sera effectué vers le service émetteur.

Le rédacteur, c'est-à-dire le service émetteur, pourra effectuer les modifications nécessaires si le projet lui revient.

Un calendrier sera mis en place afin de saisir les dates prévues des sessions délibérantes, et de déterminer automatiquement les dates butoires des étapes du workflow.

Une étape du workflow sera définie par :– nature des intervenants (auteur, fonction, ...)– type d'opération à effectuer (avis, visa, ...)– date butoir (avec des notions d'urgence)– date de réception du projet à traiter– date réelle d'intervention (attribuée automatiquement par le système)– date de renvoi du document traité– commentaire


Dans le circuit du workflow sera disponible un document historisant les différentes étapes suivies par un projet grâce à un système de versioning. Seule la dernière version du projet sera modifiable, en fonction des habilitations. Cette fiche récapitulera également tous les détails du projet de délibération :

– numéro de délibération– objet– mot-clés– nombre de page de chaque pièce du projet– rédacteur– thème– commissions concernées– service émetteur– ...

Si un projet n'est pas prêt pour la date de session à laquelle il a été prévu, il sera reporté automatiquement à la session suivante en se basant sur le calendrier si une prochaine session est programmée, et une alerte par mail sera déclenchée.

Les ordres du jour rentreront également dans un circuit du workflow, afin d'être soumis à validation, permettant ainsi de déclencher l'envoi des convocations avant la session de l'assemblée délibérante selon les délais légaux.

Les procès verbaux suite aux sessions délibérantes pourront éventuellement être aussi intégré dans un circuit du workflow s'il existe un besoin de validation par un service.

1.5. Visualisation des projets

1.5.1. Vision globale des projets

Une vision globale de tous les projets sera accessible pour certaines habilitations (de préférence le service centralisateur (service des assemblées par exemple)), différenciant les projets attribués à une session de ceux qui ne le sont pas encore.

Pour les projets non attribués à une session, il sera alors possible de sélectionner un ou des projet(s) et de les attribuer à une date de session dans le menu déroulant disponible en bas de page.

1.5.2. Vision personnelle des projets

Un projet concernant l'utilisateur identifié correspond à :– la personne identifiée est rédactrice du projet– la personne identifiée est dans le circuit de validation du projet– la personne identifiée appartient au service des assemblées

L'utilisateur identifié aura accès aux projets le concernant via une interface qui lui permettra de visualiser l'état d'avancement des projets dans les différents circuit de validation. Lorsque un projet lui arrivera pour qu'il le traite, il aura accès à l'interface de traitement du projet qui récapitulera les différents champs caractéristiques d'un projet, en donnant également accès au texte du projet généré dans un outil bureautique ainsi qu'aux pièces jointes.

Les différents états possibles pour un dossier seront :– « A traiter » : le projet de délibération est en possession de la personne identifiée, elle peut

accéder à l'interface de traitement du projet afin de continuer le circuit de validation


– « En attente » : le projet de délibération est en amont de la personne identifiée dans le circuit de validation

– « Traité » : le projet de délibération est en aval de la personne identifiée dans le circuit de validation (la personne identifiée à traité le projet) mais n'a pas encore terminé le circuit de validation

– « Validé » : le projet de délibération a terminé le circuit de validation, il a été validé par le service centralisateur (service des assemblées)

– « Refusé » : le projet a été refusé– État complémentaire « Reporté » : le projet de délibération a été reporté à une autre date

de session que celle prévue précédemment– État complémentaire « Urgent » : permet de notifier que le projet n'est pas dans les délais

prévus par le workflow (i.e. Le traitement est en retard)

L'utilisateur identifié pourra valider le projet afin que ce dernier continue le chemin de validation, ou bien le refuser. Dans ce dernier cas, le projet reculera dans le circuit de validation.

En cas de refus, il sera possible de notifier par mail toute ou partie des personnes présentes dans le circuit de validation.Il sera également possible de sélectionner la personne à laquelle on désire renvoyer le projet de délibération. Par défaut, il s'agira du rédacteur.

Si le projet de délibération est validé par la personne identifiée, son état passera à « Traité ». S'il est refusé, son état passera à « Refusé »

L'utilisateur, au moment du traitement du projet de délibération, aura la possibilité de rajouter un commentaire avant de valider ou de refuser le dossier.Les notifications par mail seront également mises en place pour avertir une personne de l'arrivée d'un nouveau dossier à traiter le concernant.

1.6. La gestion de la session de l'assemblée délibérante

1.6.1. Le calendrier

Les dates de session de l'assemblée délibérante seront gérées grâce à un système de calendrier, ce qui permettra de définir les dates de passage des projets de délibération. C'est le service émetteur qui proposera à quelle session est proposée la délibération, cette date sera validée ou modifiée par le service des assemblées.

Un utilitaire de calendrier est donc intégré à l'outil. Le calendrier permet de visualiser si une ou plusieurs sessions sont planifiées à une date donnée par un simple clic sur la date colorée.En cliquant sur une date correspondant à un jour ouvrable, à laquelle aucune session n'est prévu, l'utilisateur sera dirigée vers une page, qui lui permettra de programmer une session. Un typage des sessions sera possible afin de pouvoir gérer plusieurs type de séances, éventuellement le même jour.

1.6.2. Gestion de l'ordre du jour

L'ordre du jour de la séance de l'assemblée délibérante est géré le plus souvent par un service spécifique, sur la base des projets de délibération rédigés (par les différents services dans les organisations décentralisées).

Le libriciel doit donc permettre, pour chaque réunion, la génération automatique de l'ordre du jour à partir des dossiers de projet de délibération attribués à une session.


L'ordre du jour sera organisable via une interface dédiée. Les projets de délibération seront regroupés par thème. Un système de fléchage permettra de modifier l'ordre des projets au sein d'un même thème ou de modifier plus globalement l'ordre des thèmes (transférer un projet dans une autre rubrique thématique par exemple). Il sera également possible de scinder les thèmes, et éventuellement d'organiser les projets à l'aide d'un système d'ordre de passage à la place d'un système de fléchage. Il sera possible d'éditer l'ordre du jour avec des projets de délibération non validés. L'ordre du jour devra pouvoir intégrer un circuit afin d'être également validé.

La génération s'effectuera vers un modèle de documents Open Office, enregistrable, modifiable et transférable directement entre le logiciel et Open Office, et ce jusqu'à la date de la réunion. La forte interaction avec Open Office permettra d'adapter ses propres modèles d'ordre du jour.

Une fois l'ordre du jour validé (état visible dans le workflow), les convocations seront envoyées selon les délais légaux.

L'ajout, la suppression ou la modification d'un titre de l'ordre du jour doit être notifiée au service émetteur par e-mail et/ou via l'interface Web. Cette notification pourra être accompagnée d'un commentaire saisi par le service centralisateur. Si l'ordre du jour a été modifié après l'envoi des convocations, le système doit permettre la production et l'impression d'additifs qui seront transmis aux élus en début de séance.

L'ordre du jour doit contenir les éléments suivants : – la liste des titres des délibérations ; – la liste des rapporteurs ; – le contenu des dossiers :

– le texte du projet de délibération ; – le texte de la note explicative de synthèse ; – des pièces annexes ;

– l'état du dossier ;– liste des pièces ;– liste des actions à réaliser sur chaque pièce.

L'avant-projet de l'ordre du jour doit pouvoir être envoyé à tout moment aux services concernés, via l'interface Web de la solution ou par e-mail.

1.6.3. Envoi des convocations

Les convocations sont envoyées par un service émetteur à destination d'un service ou d'une liste d'élus. Elles pourront être générées à partir d'un modèle prédéfini (squelette) ou à partir d'un message saisi dans la zone prévu à cet effet. Un éditeur de texte sera intégré afin de saisir le texte du message de manière plus ergonomique.La génération des convocations pourra être nominative : le destinataire sera directement imprimé sur la lettre qui pourra être insérée dans une enveloppe à fenêtre. Si on souhaite faire une lettre plus « générique », il sera possible de générer des convocations anonymes, entraînant la génération d'étiquettes à coller sur les enveloppes. Cette génération sera une forme de publipostage à destination d'un outil bureautique.Les convocations seront également envoyées par mail à titre informatif.

1.6.4. Gestion des présences

La présence des élus étant variable au cours même de l'assemblée délibérante, il faut prévoir la gestion des présents et des absents. Cette gestion s'effectuera soit avant la séance, liste qui pourra être remplie avant la séance afin d'établir une liste de départ pour la saisie des votes lors de la séance, soit au moment de chaque vote, sous forme de la liste officielle des élus pré-


cochés sur « présent ». L'absence d'un élu se traduira donc uniquement par le biais de la sélection du statut « absent ». Une zone « mandataire » sera alors active.

1.6.5. Gestion des votes

Pour chaque projet de délibération, l'utilisateur a accès à une interface pour saisir les votes. Les votes peuvent être nominatifs ou anonymes. Il sera possible d'enregistrer des votes nominatifs et anonymes (certaines collectivités publiant par exemple les totaux des votes avec la liste des opposants à un vote d'un projet de délibération).Les projets étant souvent adoptés à la quasi-unanimité, et l'utilisation de l'outil étant possible durant la séance, il sera possible via la bouton « Début du vote nominatif » de cocher tous les votes à « pour ».L'application devra permettre l'importation des votes saisis par sténotypage.

La liste des élus sera gérée comme suit :– présent/absent (bouton radio)– mandant : zone active si bouton « absent » sélectionné, pour saisir le nom du

mandataire– pour/contre/abstention/ne souhaite pas participer au vote : résultat du vote– vote consultatif : pour/contre– commentaire pour chaque vote

Il sera possible de préciser pour chaque votant (délibératif ou consultatif) s'il agit en qualité de titulaire ou de suppléant.

Les personnes qui assistent sans avoir de vois consultative ou délibérative à la séance pourront être éventuellement saisies dans la liste des présents.

Il devra être possible de modifier le contenu des délibérations en fonction des modifications éventuelles qui auront été apportées en cours de séance.

Le système devra permettre une solution de gestion de preuves électroniques pour la gestion des présences et des signatures pendant la séance.

Le système devra également permettre la génération du compte-rendu sommaire à partir des projets de délibération envoyés par les différents services. Le compte-rendu sommaire sera exportable afin de pouvoir être publié sur le site Internet de la collectivité (au format XML si possible). Un import des débats de séances sténotypés sera possible pour générer le PV de séance. Ce compte-rendu est lu en début de séance suivante. Il est à éditer dans les 8 jours qui suivent la session, et est également destiné au public. Le compte rendu de presse (exhaustif) sera rédigé puis affiché.

Le procès verbal de la séance de l'assemblée délibérante est retranscrit dans un document bureautique. Il regroupe tous les rapports avec tous les commentaires.

1.7. La transmission au contrôle de légalité

La solution doit permettre la signature électronique des délibérations par les élus pendant la séance de l'assemblée délibérante.

Le libriciel permettra la transmission des délibérations signées à l'ensemble des dispositifs dispositif de télé-transmission S²LOW, ainsi qu'à d'autres dispositifs homologués.


1.8. Suivi, indexation, recherche

La solution doit permettre le suivi de toutes les étapes de la gestion des délibérations par les utilisateurs autorisés. Tous les documents liés à un projet de délibération devront être indexés et être interrogeables via un système intégré.

Les dossiers de délibération devront pouvoir être associés à une séance de l'assemblée délibérantel. Ils devront pouvoir être classés par titre, numéro, date, signataire ou rapporteur. Ils doivent également supporter une classification par thème, rubrique et sous-rubrique modifiables. Une recherche devra pouvoir être effectuée sur tous les champs associés aux dossiers.

L'outil devra permettre un export vers une GED externe. Ainsi, les recherches « full-texte » ne seront pas implémentées dans l'outil lui-même.

Les délibérations devront pouvoir être scannées après le retour du contrôle de légalité et être associées au dossier de la séance correspondant. Les services émetteurs doivent y avoir accès. Les délibérations doivent également pouvoir être transmises à une liste d'utilisateurs prédéfinie et modifiable liée à chaque service émetteur.

Des mots-clés issus d'un thésaurus devront pouvoir être associés manuellement à chaque projet de délibération.

La recherche sera possible selon différents critères (paramétrage selon la typologie de la collectivité (à 2 ou 3 niveaux)) :

– titre– synthèse– mot-clé– saisie– canton– territoire– pays– numéro– ville– intervalle– combinaison de critères

Les résultats de la recherche seront consultables à l'écran et éditable sous une forme communicable (exportation).

1.9. la transformation des délibérations format bureautique en pdf/a

Les délibérations une fois exécutoires devront pouvoir être transformées automatiquement en format PDF/A en vue d'archivage.

Cette transformation s'effectuera par lots ou délibération par délibération sur action spécifique de l'utilisateur.


2. Principes ergonomiques à prendre en compte

L'objet du présent chapitre est d'énoncer un certain nombre de considérations ergonomiques qui doivent être transcrites dans le logiciel ciblé. Elles concernent :

– les outils de recherche et le principes de navigation dans l'application– les liaisons avec la bureautique– les éditions

2.1. Les outils de recherche dans l'application

La pratique quotidienne d'une application de cette nature par de nombreux services et par des acteurs variés et souvent occasionnelle au sein d'une collectivité, implique la manipulation aisée et une Interface Homme Machine particulièrement intuitive.

La pertinence des instruments de recherche des documents types, des délibérations stockés est un des points ergonomiques majeurs d'une application de gestion de délibérations.

Ces documents doivent donc pouvoir être recherchés, triés , obtenus, et exploités de multiples manières, le plus intuitivement possible.

Des grilles de sélections et de recherches, sur la base de critères combinés s'appuyant sur les champs d'indexation significatifs des grilles de saisie propres à chaque document sélectionné, doivent donc être proposées par l'application.

Les documents définitifs ont par ailleurs vocation à être accessible par les citoyens et les fonctionnaires n'intervenant absolument pas dans les processus de gestion.

2.2. Les liaisons avec la bureautique

D'une manière générale, toute édition, liste de travail issue d'une sélection doit pouvoir être transférée dynamiquement dans la bureautique Open Office pour exploitation.

Les documents définitifs (délibérations validées) doivent impérativement être stocké au format PDF/A, garantissant ainsi le respect des normes en vigueur.

2.3. Éditions et états

La pratique de la préparation des séances des assemblées délibérantes dans les collectivités territoriales induit le recours fréquent et régulier aux éditions, au titre :

– de la production des documents préparatoires obligatoirement distribuées en amont des séances ( ordre du jour, liste des projets...)

– des états de contrôle variés (états des présents , des votants, ...)– d'annexes variées (pièces rattachées )– des éditions de travail ponctuelles (listes des documents transmis au contrôle de

légalité, liste des rapports en retards pour les relances ...)

L'application doit donc impérativement inclure un générateur d'éditions, ainsi qu'un générateur d'états «de travail», à la fois souple et puissant.

Les éditions réglementaires doivent être produite par le libriciel (PV de séance, registre de


délibérations).

Une préférence est donnée aux solutions d'éditions basées sur un développement, à l'opposition de solutions techniques basées sur des macros.

Le format d'impression doit pouvoir être soit du PDF (imprimante poste de travail), ou un flot de type PCL (imprimante serveur). Ce choix s'effectuera, lors de l'utilisation du système, par l'utilisateur.

Concernant la production de ces états de travail, un requêteur intégré à l'application, permettra un accès aux informations stockées selon 2 modes :

– Recherche et affichage à l'écran simple d'un résultat imprimable et/ou exportable en bureautique immédiatement

– Constitution de requêtes plus complexes à partir d'un langage d'interrogation spécifique. Les résultats de ces requêtes doivent pouvoir être exploités immédiatement (impression, export dynamique vers l' outil bureautiques Open Office), mais également être conservées en vue d'une réutilisation ultérieure.

La gestion d'autorisations permettra de garantir la confidentialité de ces traitements.

Dans tous les cas, un choix de formats de sortie doit être laissé à l'utilisateur, parmi lesquels :– Format Tableur (.ods)– Format traitement de texte (.odt)– Format navigateur (.html)– Format acrobat reader (.pdf)– Format fichier texte (.txt)– Format xml.

En matière de restitutions, une fonction de génération de CD-ROM serait appréciée, comme celle d'une synthèse de séance avec publication de liens sur l'ensemble des documents de références sur les contenus traités.

Pour l'édition de statistiques, il est convenu que les outils d'extraction et de reporting Open Source (type TALEND et JASPER) soit utilisés.


3. Environnement technique et performances requis

Le système devra garantir les temps de réponse et des performances générales compatibles avec l'urgence dans lesquels certains traitements préparatoires aux séances sont effectués.

Des fonctions simplifiés, permettront la saisie «temps réel» des votes lors des séances, afin d'éviter toute ressaisie ultérieure. Deux modes de saisie en séances doivent pouvoir cohabiter : Un mode saisie temps réel et un mode « off-line » depuis un module PC ad-hoc permettant la mise à jour ultérieure des informations relatives aux présences et aux votes en séances.

Pour ces opérations réalisées en temps réel (transactions courantes), les temps de réponse souhaités sont inférieurs à 1 seconde. Pour les opérations pouvant être effectuées en léger différé (recherches, états …), les temps de réponse souhaités doivent être inférieurs à 5 secondes.

Dans un souci constant de performance et dans un contexte de maîtrise des coûts, l'application doit être en mesure d'être installée sur des clients légers (Pcs munis d'un navigateur Web de type Mozilla Firefox et d'acrobat reader).

Les O.S clients supportés devront préférentiellement être ceux du monde Open Source (Linux),mais le fonctionnement doit demeurer possible dans un environnement propriétaire Microsoft.

Les technologies LAMP et J2EE (serveurs d'applications libres) seront privilégiées.

Il en est de même pour les bases de données supportées, qui seront PostGreSQL ou/et MySQL.

Le choix final sera effectué à la clôture de la validation du dossier de spécifications détaillées qui induira la meilleure technologie adaptée au contexte mais aussi aux attentes en terme de performance et de facilité de déploiement.

En revanche, la modélisation de l'application sera obligatoirement faite en UML afin de standardiser les échanges mais surtout permettre l'usage de générateur de code à partir du modèle validé.
