L E SITE P REVADIES FR

Les adhérents peuvent s’inscrire sur le site Internet Prévadiès.fr. Cela impose d’y apporter certaines évolutions. Après étude des besoins avec le service communication, les évolutions ont été reportées dans le tableau suivant.

Déc. Démat. Depuis le. (01/01/2008 – )

Déc. Démat. Depuis le. (01/01/2008 – )

69

Formulaire ou page web fonctionnalités

Formulaire d’inscription et de demande de code

Existant :

Identification de l’Internaute à partir des numéro d’adhérent, date de naissance et code postal

Collecte de l’adresse e-mail Evolutions :

adhésion au service de décomptes dématérialisés acceptation des C.G.U.

Formulaire d’inscription sans demande de code (adhérents préalablement inscrits)

Fonctionnalités :

adhésion au service de décomptes dématérialisés acceptation des C.G.U.

Possibilité de mettre à jour l’adresse e-mail

Page d’accueil des relevés santé

Existant :

lien d’accès au prochain relevé au format HTML lien d’accès aux derniers relevés santé au format HTML Evolution :

Ajout d’un nouveau lien dynamique pour accéder au formulaire d’inscription au service de dématérialisation (adhérents non inscrits) ou aux relevés santé en ligne (adhérents préalablement inscrits) Page de présentation des

relevés santé

Fonctionnalité :

Affichage sous forme graphique (icône) des relevés santé reçus Téléchargement des documents dématérialisés

E-mails de confirmation

Fonctionnalité :

Envoi d’un e-mail après validation d’une inscription au service de relevés santé

Envoi d’un e-mail pour validation de l’adresse e-mail (si modification de l’adresse e-mail)

La difficulté dans cette étape du projet tient à l’intégration des modifications tout en tenant compte des contraintes de l’outil de gestion de contenu Nohéto WCM. Cet outil partage les pages web du site en deux catégories (voir la copie d’écran ci-dessous en exemple) :

- les menus et le design des pages identiques à toutes les pages, paramétrables dans l’outil Nohéto ;

- le contenu informationnel pour lequel une page web spécifique doit être développée. Des copies d’écran du contenu informationnel sont données en exemple en ANNEXE K: Les formulaires web du service de dématérialisation.

70

Figure 24 : Page web générée par Nohéto 6.1.4.4. LE STOCKAGE DE L’INFORMATION

Il existe une règle implicite pour conserver une indépendance maximale du serveur de production G***** et ne pas engendrer un trafic réseau trop important : les applications de production doivent attaquer la base SIPRE de façon exclusive.

Or les données liées à l’inscription doivent être accessibles à la fois aux applications de production (CAPRI et SIPRE), mais également au site Internet. En conséquence, il a été décidé de créer une même structure de tables sur les bases de données SIPRE et InternetDB et de les synchroniser pour avoir le même niveau d’information, sachant que la désinscription n’est possible qu’à partir de l’application CAPRI. Pour cela, deux passerelles sont mises en place et exécutées quotidiennement dans le but de comparer et mettre à jour les données sur les deux systèmes.

6.1.4.4.1. La modélisation des bases de données

Finalement, deux tables sont proposées au support bases de données pour évolution du modèle de données SIPRE et InternetDB. Ces évolutions respectant la 3ème _{forme normale, ce lot d’évolutions}

est appliqué sur les 2 bases de données :

- l’une servant de référentiel des services proposés (table TYPSERV) contenant les enregistrements suivants (identifiant et libellé associé) :

71

IDTYPSERV LIBELLESERV

--- --- 1 Décomptes dématérialisés

2 Alerte e-mail de dépôt d'un décompte 3 Validation des CGU

- l’autre conservant l’historique des inscriptions pour chaque Internaute suivant le dictionnaire des données suivant

Nom Description

--- --- --- --- --- IDINSCRSERV Numéro séquentiel

IDPERSPHY Numéro d’adhérent de l’Internaute IDTYPSERV Type de service (clé étrangère sur la table TYPSERV) DTDEBUT Date et heure de saisie de l’inscription

DTFIN Date et heure de clôture de l’inscription

IDUTILDEBUT Identifiant de l’utilisateur qui a validé l’inscription IDUTILFIN Identifiant de l’utilisateur qui a clôturé l’inscription

L’une des caractéristiques du développement de sites Internet est de concevoir des pages de taille limitée de sorte que leur chargement soit aussi rapide que possible. En effet, une étude de Jacob Nielsen montre que les utilisateurs ont tendance à fermer une page Web qui met plus de 10 secondes à se charger. C’est pourquoi les accès aux bases de données se doivent d’être aussi rapides que possible. Pour cela, il peut être judicieux d’avoir recours à l’indexation des tables.

6.1.4.4.2. Les index SQL

Lorsqu’une table est accédée par une requête SQL, celle-ci est parcourue par défaut dans son intégralité pour y trouver les enregistrements correspondants aux critères de sélection. Si cette opération est rapide dans le cas de tables de taille très réduite, elle peut s’avérer plus coûteuse en temps pour des volumes importants de données.

6.1.4.4.2.1. Structure d’un index

Pour parer à ce problème, les SGBD relationnels (SGBDR) offrent la possibilité de créer des index. Ce sont des structures permettant de retrouver une ligne dans une table à partir de la valeur d'une colonne ou d'un ensemble de colonnes. Un index contient la liste triée des valeurs des colonnes,

PERSPHY IDPERSPHY NOM PRENOM DTNAIS DTDECES … UTIL IDUTIL LIBELLE … TYPSERV IDTYPSERV LIBELLESERV USAG IDUSAG … DESTDEC IDDESTDEC … DESTPAY IDDESTPAY IDINFOBQ … Adhère DtDebut DtFin Est un A pour Dest. Pay. A pour Dest.Déc Est un

72

indexées avec les adresses des lignes (numéro de bloc dans la partition et numéro de ligne dans le bloc) correspondantes.

Dans le cas du SGBDR Oracle, les index sont stockés sous forme d'arbres équilibrés : une structure arborescente permet de retrouver rapidement dans l'index la valeur de clé cherchée, et donc l'adresse de la ligne correspondante dans la table. Dans un tel arbre, toutes les feuilles sont à la même profondeur, et donc la recherche prend approximativement le même temps quelle que soit la valeur de la clé.

6.1.4.4.2.2. Choix des index

L’efficacité d’un index dépend de la ou les colonnes qui le composent. Lors de sa création, il faut ainsi tenir compte des règles suivantes :

- indexer en priorité : - les clés primaires,

- les colonnes servant de critères de jointures

- les colonnes servant souvent de critères de recherche, - éviter d’indexer :

- les colonnes dont la valeur et « NULL » : les valeurs « NULL » ne figurent pas dans l’arbre d’index pour en limiter la taille,

- les colonnes contenant peu de valeurs distinctes - les colonnes fréquemment mises à jour

6.1.4.4.2.3. La création des index

D’après nos estimations du nombre d’inscrits au service de relevés santé en ligne, la table INSCRSERV contiendra après un an d’inscriptions 300 000 enregistrements, ce qui semble justifier son indexation.

L’analyse des données de cette table aboutit à choisir la colonne IDPERSPHY comme clé d’index car ses valeurs sont distinctes et non nulles et elle est le point d’entrée de toutes les requêtes effectuées à partir des applications transactionnelles.

Le stockage des autres données manipulées dans le cadre du projet de dématérialisation est hors du périmètre du projet. Les structures de données utilisées existaient préalablement au lancement du projet et n’ont pas posé de problème pour nos travaux.

6.2. L

La solution retenue pour créer les décomptes dématérialisés et de confier le processus à SATI. Pour cela, des adaptations sont à prévoir sur les processus existants, que ce soit à Prévadiès ou chez SATI.