DILA
Contexte
Les équipes travaillant à la rédaction du site service-public.fr ont une organisation très structurée. Des rédacteurs en chef ont la responsabilité de valider les contenus produits pour le site. Une intervention sur le graphe documentaire se fait soit à l'initiative d'un rédacteur, soit à la demande d'un rédacteur en chef. Étant donnée l'importance légale des documents publiés, toute modification doit à la fois être contrôlée pour valider son contenu et documentée pour faciliter la compréhension de son origine et ainsi, faciliter sa maintenance.
Modélisation
La modélisation de ce contexte s'appuie sur le système de tâches. Deux fragments tâches ont été modélisés : un fragment de commande et un fragment de demande de validation. Ces deux fragments sont exploités par le moteur de tâches. L'intégralité de l'activité est à la fois enregistrée (qui a fait quoi et quand) et documentée (dans quel contexte et pour répondre à quel objectif).
Modélisation - fragment de commande
Le fragment de commande est initié par un rédacteur en chef ou un simple rédacteur. Il dispose de trois champs responsabilité (responsable pour le rédacteur, suiveur pour un rédacteur ayant initié une commande et souhaitant être informé de l'évolution de la commande et responsable de la validation pour le rédacteur en chef), d'un titre, d'une date de planification, d'une date d'échéance et d'un fil de discussion. Une commande est le plus souvent effectuée suite à un retour fait par des usagers de la documentation (les lecteurs de la documentation). Le modèle documentaire associé à une tâche contient des informations dédiées à la remontée de l'erreur (date et provenance), une description textuelle du problème et une synthèse des modifications à apporter.
Le fragment de commande peut ainsi être modélisé comme illustré sur la figure 56.
Le fichier suivant est un exemple de fragment de commande :
<stk:task>
<stk:update by="BC0605AB" date="1382370761770">
<stk:execTransition transition="initEnCours" newState="aTraiter" newActStage="pending"/>
<stk:putUser account="GM1001AB" resp="e"/>
<stk:putUser account="RedacChefSpTel" resp="v"/>
<stk:setTitle newTitle="Santé Info Droits"/>
<stk:setDeadline newDt="1385052626845"/>
<stk:setDescription>
<dic:commandeDetails>
<dic:commandeDetailsM>
<sp:date>2013-10-21</sp:date>
<sp:origine>tel</sp:origine>
</dic:commandeDetailsM>
<sp:txt>
<dic:taskTxt>
<sc:para xml:space="preserve" sc:id="t2">
<sc:objectLeaf role="item" sc:id="t3" sc:refUri="id:6RASFlGTRHK3hdImiTGnLp"/> : il faut expliquer à quoi sert le 2ème n° de téléphone.
</sc:para>
</dic:taskTxt>
</sp:txt>
</dic:commandeDetails>
</stk:setDescription>
</stk:update>
<stk:update by="GM1001AB" date="1382535749637">
<stk:execTransition transition="aValider" newState="aValider" newActStage="pending"/>
<stk:addComment>
<dic:taskTxt>
<sc:para xml:space="preserve" sc:id="t2">précision apportée ; lien formulaire vérifié</sc:para>
</dic:taskTxt>
</stk:addComment>
</stk:update>
<stk:update by="BC0605AB" date="1382541368567">
<stk:execTransition transition="close" newState="close" newActStage="completed"/>
<stk:addComment>
<dic:taskTxt>
<sc:para xml:space="preserve" sc:id="t2">OK</sc:para>
</dic:taskTxt>
</stk:addComment>
</stk:update>
</stk:task>
Une fois interprété par le moteur de tâches, ce fichier XML est mis en forme comme illustré sur la figure 57.
Le cycle de vie de la tâche de commande est défini comme illustré sur la figure 58 :
À traiter | Planifié | À valider | À revoir | Clos et re-planifié | Clos | |
Responsable | Exécutant | Aucun | Suiveur | Exécutant | Aucun | Aucun |
Suiveur | Suiveur | Aucun | Suiveur | Suiveur | Aucun | Aucun |
Responsable de la validation | Suiveur | Aucun | Exécutant | Suiveur | Aucun | Aucun |
Lors de son initialisation, le fragment de commande est directement placé en état À traiter si l'intervention est urgente ou Planifié le cas échéant. Un fragment en état planifié ou clos et re-planifié n'est associé à aucun utilisateur. Un déclencheur automatique transforme le fragment en état À traiter le jour de la date de planification. Un fragment validé et clos peut systématiquement être ré-ouvert. L'état Clos et Re-planifié est utilisé pour programmer une réouverture de tâche à effectuer de façon routinière. Il est utilisé dans deux contextes :
Certaines fiches du site sont activées uniquement à certaines périodes de l'année (comme par exemple la fiche sur les primes de fin d'année). L'état Clos et Re-planifié est utilisé afin de réactiver la tâche lorsqu'une fiche doit être ajoutée ou supprimée.
Certaines fiches deviennent fausses soit par changement législatif, soit en raison d'une péremption (par exemple, la fiche sur le calcul des allocations familiales peut contenir des exemples avec des dates de naissance fictives. Ces dates doivent être remises à jour régulièrement afin que les exemples restent justes). L'état Clos et Re-planifié est alors utilisé pour réactiver la tâche lorsque la fiche doit être mise à jour.
Modélisation - fragment de demande de validation
Le fragment de demande de validation est initié par un rédacteur ayant pris l'initiative d'effectuer une intervention sur le graphe. Ce fragment sert à enregistrer le processus de validation de l'intervention. Deux responsabilités lui sont associées : le propriétaire (de la demande) et le responsable de la validation. Outre un intitulé, le modèle documentaire contient un champ de description et un champ de synthèse des modifications.
Le fichier suivant est un exemple de fragment de demande de validation :
<stk:task>
<stk:update by="GM1001AB" date="1363699882998">
<stk:execTransition transition="init" newState="aValider" newActStage="pending"/>
<stk:putUser account="GM1001AB" resp="p"/>
<stk:putUser account="BC0605AB" resp="v"/>
<stk:setTitle newTitle="Remontée messagerie du 13/03"/>
<stk:setDescription>
<dic:validationDetails>
<sp:txt>
<dic:taskTxt>
<sc:para xml:space="preserve">
Item :
<sc:objectLeaf role="item" sc:refUri="id:6ZjSFlGTRHK3hdImiTGnLp"/>
</sc:para>
</dic:taskTxt>
</sp:txt>
<sp:commentaire>
<dic:taskTxt>
<sc:para xml:space="preserve" sc:id="t4">
ajout du certificat d'examen portant la mention favorable
</sc:para>
</dic:taskTxt>
</sp:commentaire>
</dic:validationDetails>
</stk:setDescription>
</stk:update>
<stk:update by="BC0605AB" date="1363700273666">
<stk:execTransition transition="aRevoir" newState="aRevoir" newActStage="pending"/>
<stk:addComment>
<dic:taskTxt>
<sc:para xml:space="preserve" sc:id="t3">J'ai 3 remarques :</sc:para>
<sc:para xml:space="preserve">
1) La formulation "pour les personnes qui n'ont pas encore reçu leur permis de conduire" n'est pas idéale, parce qu'une personne en attente de la réception d'un duplicata suite à perte / vol peut se sentir concernée. J'écrirais "l'original de votre permis de conduire ou, pour si vous avez réussi l'examen pratique du permis mais n'avez pas encore reçu votre titre définitif, l'original du certificat d'examen portant la mention favorable,".
</sc:para>
<sc:para xml:space="preserve" sc:id="t6">
2) Dernière phrase : la construction est maladroite, on ne sait pas à quoi se réfère le "il".
</sc:para>
<sc:para xml:space="preserve" sc:id="t7">3) Il manque ton binôme.</sc:para>
</dic:taskTxt>
</stk:addComment>
</stk:update>
<stk:update by="GM1001AB" date="1363768389641">
<stk:execTransition transition="aValider" newState="aValider" newActStage="pending"/>
<stk:addComment>
<dic:taskTxt>
<sc:para xml:space="preserve" sc:id="t2">remarques intégrées</sc:para>
</dic:taskTxt>
</stk:addComment>
</stk:update>
<stk:update by="BC0605AB" date="1363777064848">
<stk:execTransition transition="close" newState="close" newActStage="completed"/>
<stk:addComment>
<dic:taskTxt>
<sc:para xml:space="preserve" sc:id="t2">OK, c'est validé.</sc:para>
</dic:taskTxt>
</stk:addComment>
</stk:update>
</stk:task>
Une fois interprété par le moteur de tâches, ce fichier XML est mis en forme comme illustré sur la figure 60.
Le cycle de vie d'un fragment de demande de validation est défini comme illustré sur la figure 61.
À valider | À revoir | Close | |
Propriétaire | Suiveur | Exécutant | Aucun |
Responsable validation | Exécutant | Suiveur | Aucun |
Le cycle de vie mobilisé par le fragment de demande de validation est extrêmement permissif. Il est possible de passer à chacun des états depuis chacun des autres états. On distingue bien ici l'objectif de produire un fragment d'assistance à l'organisation de l'activité plutôt qu'une gestion de l'activité par le processus.