Subject: Fwd: [sra-centre] Re: ARP oui mais pas comme ça!
From: BRUNET philippe <[email-masked]>
To: "sg.snac-fsu" <[email-masked]>
Date: Wed, 18 Jan 2012 18:37:10 +0100

/*Pour Info "PERSO"
à propos d'une contestation de "ARP" qui remonte de la base (Lyon et 
autres): au cas où elle ne serait pas remontée jusqu'à toi. Voir mels 
ci-dessous.

Voilà que le "camarade" Marc DROUET (qui semble avoir bien lu (lui) son 
manuel sur le dialogue social, au chapitre ça peut toujours servir)... 
charge les syndicats d'une responsabilité d'évaluation d'un outil 
informatique évidement monter au niveau central de travers, avec des 
moyens insuffisants et une concertation de couloir "aléatoire" - En 
plus, il renvoie  la balle au centre, pour un dégagement vers la 
responsabilité des DRAC pour ce qui concernerait des moyens 
complémentaires  (joueur le garçon?).

Cette position qui n'est pas étonnante de la part d'un sous-directeur, 
dans le contexte..., montre qu'il serait bon de ne pas suivre la CGT sur 
le terrain de la cogestion, et cela même si nous avons des "amis" dans 
la place. A minima, il serait judicieux que les réunions 
inter-syndicales, régulières, avec la SDA, fassent l'objet de compte-rendu.
on en parle vendredi.
Ph.B.*/

-------- Message original --------
Sujet: 	[sra-centre] Re: ARP oui mais pas comme ça!
Date : 	Fri, 13 Jan 2012 17:19:26 +0100
De : 	*DROUET marc <[email-masked]>*
Répondre à : 	[email-masked],DROUET marc 
<[email-masked]>
Pour : 	[email-masked]
Copie à : 	[email-masked], [email-masked], 
[email-masked], [email-masked], 
[email-masked], [email-masked], 
[email-masked], [email-masked], 
[email-masked], [email-masked], 
[email-masked], [email-masked], 
[email-masked], [email-masked], 
[email-masked], [email-masked], 
[email-masked], [email-masked], 
[email-masked], [email-masked], 
[email-masked], [email-masked], 
[email-masked], [email-masked], 
[email-masked], [email-masked], LOMBARD 
Alain <[email-masked]>, Munin 
<[email-masked]>, WILLEMAN laurent 
<[email-masked]>, Bernard Randoin 
<[email-masked]>, [email-masked], Elise 
Boucharlat <[email-masked]>, GUILHOT jean olivier 
<[email-masked]>, 
[email-masked], [email-masked], 
[email-masked], [email-masked], 
[email-masked], [email-masked], isabelle MARÉCHAL 
<[email-masked]>, jean-séverin LAIR 
<[email-masked]>, jean-luc BISCOP 
<[email-masked]>

Bonjour,

merci de votre message et des informations qui l'accompagnent. Je me
permets de vous adresser en retour les termes du message que j'ai envoyé
ce matin à vos collègues d'Alsace qui évoquaient également le sujet :

Bien entendu, nous sommes d'accord pour considérer qu'un nouveau
logiciel n'a d'intérêt que s'il apporte un confort de travail pour les
agents et/ou des fonctions nouvelles dans l'intérêt général de
l'archéologie. La vision des utilisateurs apparaît donc essentielle
notamment aux moments stratégiques de déploiement du nouvel outil.

*Je prends acte de vos interrogations et je propose en conséquence - en
plus des différentes expérimentations en cours avec des SRA pilotes  -
qu'à l'occasion de la prochaine réunion qui se tient régulièrement entre
la sous direction de l'archéologie et les représentants des personnels,
le sujet soit abordé et permette de recueillir ces observations  *dont
vous, et d'autres, vous faites les relais. A la lumière de cet échange,
nous envisagerons en concertation avec l'ensemble des acteurs concernés,
les réponses adaptées qui devront être apportées afin que le projet
demeure conforme aux objectifs fixés à l'origine, etbien entendu
*compatible avec les moyens dont disposent les DRAC*  pour fonctionner.

Bien cordialement

-------- Message original --------
Sujet: ARP oui mais pas comme ça!
De : intersyd<[email-masked]>
Pour : [email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked], LOMBARD
Alain<[email-masked]>, Munin
<[email-masked]>, WILLEMAN laurent
<[email-masked]>, [email-masked], Bernard
Randoin<[email-masked]>, [email-masked],
Elise Boucharlat<[email-masked]>, GUILHOT jean
olivier<[email-masked]>,
[email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked]
Date : Vendredi 13 Janvier 2012 15:00:46
>  Lyon le 13/01/2012
>
>  ARP oui, mais pas comme ça!
>
>
>  L'ensemble des agents du SRA Rhône Alpes se réjouit de la mise en
>  place d'une application destinée à la gestion des procédures
>  d'archéologie tant préventive que programmée. Cet outil nous semble
>  indispensable, tout à la fois pour prendre le relais de nos bases
>  locales en fin de vie, que pour harmoniser des pratiques régionales de
>  plus en plus autonomes.
>
>  Notre région a eu la primeur de l'application, puisque nous sommes
>  testeurs de la partie « archéologie préventive ». Nous avons relevé
>  que cette application, au delà de son indéniable côté chronophage et
>  de sa convivialité de minitel, présente de très nombreux
>  dysfonctionnements structurels, terminologiques et formels (voir la
>  liste en annexe). En dépit d'une apparente concertation tout au long
>  du processus, nous constatons qu'aucun des problèmes importants
>  signalés n'a été pris en compte.
>
>  C'est pourquoi nous sommes extrêmement surpris de découvrir que la
>  Vérification d' Aptitude (VA) est achevée, que la formation et le
>  déploiement de l'application sont prévus dans les plus brefs délais,
>  dès la mi janvier, sans tirer les leçons de la VA ! Il nous apparaît
>  clairement que seule une amélioration importante de la base ARP
>  permettra d'en faire un outil opérationnel qui sera adopté par toutes
>  les régions.
>
>  *En conséquence nous exprimons dès à présent notre refus de participer
>  aux formations programmées en 2012, et nous invitons nos collègues à
>  exprimer le même refus s'ils ne veulent pas perdre leur temps dans des
>  formations prématurées.*
>
>
>  L'ensemble des agents du SRA Rhône-Alpes
>
>
>  Liste non-exhaustive des défauts relevés:
>
>
>  Absence de tableau de bord
>
>  Absence d'historique
>
>  Absence d'échéancier utilisable
>
>  Absence des courriers de notifications des arrêtés
>
>  Impossibilité d'extraire des statistiques détaillées
>
>  Chartes graphiques locales non prise en considération
>
>
>
>  -ONGLET « reception »:
>
>     *
>
>       Pas de liste alphabétique des agents; liste non modifiable
>  localement
>
>     *
>
>       Présentation du tableau de recherche d'un dossier par son nom; non
>       modifiable localement.
>
>           o
>
>             Pour accomplir une recherche quotidienne fluide des
>             dossiers, il faut privilégier l'*année*, le *département,*
>             la *commune* puis le *nom du dossier* et *son numéro*;
>
>     *
>
>       Liste nationale et non régionale; l'accès devrait être hiérarchisé
>       tel que mis en pratique sur l'application PATRIARCHE depuis 2002.
>
>     *
>
>       Enregistrement d'un dossier: Le temps incompressible imparti à
>       l'enregistrement des dossiers est de 10 mn (sans l'édition des
>       courriers d'accusé de réception)
>
>           o
>
>             Cette charge de travail représente *trois fois plus *de
>             temps que l'enregistrement actuel à résultat équivalent.
>
>           o
>
>             Les champs contraints devraient être limités et certains
>             supprimés: par exemple pour une adresse, on remplit 4 champs
>             contraints (dont les listes de termes sont incomplètes)
>             alors qu'un seul champ libre suffirait.
>
>           o
>
>             L'absence de répertoire régional simple est également
>             préjudiciable pour éviter les saisies systématiques et les
>             doublons, le moteur de recherche n'étant pas structuré pour
>             être efficient. Pour exemple, il faut créer un répertoire de
>             services instructeurs ordonnés selon la région puis les
>             départements puis par liste alphabétique.
>
>           o
>
>             Le champ « ressources documentaires » est inutile
>
>           o
>
>             Les champs relatifs au « périmètre » et au terme « unité de
>             Patrimoine » sont confus (statut administratifs différents
>             mélangés) et trop complexes: une simple case à cocher
>             suffirait à savoir, si le dossier est: concerné par une ZPPA
>             (Oui/Non) et/ou par une protection au titre VI du Code du
>             Patrimoine (Oui/Non), les courriers générés par ces derniers
>             cas n'apparaissent pas dans ARP (exemple instruction double
>             des MH et de l'archéo à dissocier).
>
>           o
>
>             Les références cadastrales peuvent être simplifiées sans
>             champ contraints. L'organisation par tableau avec une ligne
>             par section alourdi considérablement la saisie. *Les
>             emprises relevant du domaine public n'apparaissent pas et ne
>             sont pas enregistrables.*
>
>  -ONGLET « description générale du dossier »:
>
>           o
>
>             Le module n'apparait que dans un second temps après avoir
>             cliqué sur « réception », c'est un enchainement peu logique.
>
>           o
>
>             Le mode de saisine du dossier n'apparait pas dans le premier
>             module « réception » mais dans un onglet complémentaire peu
>             accessible intitulé « vérification des antécédents », la
>             terminologie est encore une fois incorrecte.
>
>           o
>
>             La case « étude d'impact » doit être supprimée et ajoutée
>             dans la liste des « type de dossier » dans l'onglet
>             « réception ».
>
>  -ONGLET « édition »:
>
>           o
>
>             Les modèles de courriers n'utilisent pas la charte graphique
>             en vigueur dans les DRAC
>
>           o
>
>             La fusion des informations est incomplète (exemple: pas
>             d'expéditeur)
>
>           o
>
>             La modification des courriers est impossible à réaliser dans
>             ARP et nécessite un enregistrement local qui induit une
>             perte de temps accrue.
>
>           o
>
>             Les délégations de signature ne sont pas encore enregistrées
>             dans les listes contraintes de la version ARP testée, le
>             test ne peut pas être poursuivi sans ces données non
>             modifiables en région.
>