AVIS D’EXPERT COHERIS – Ingénieur avant-vente chez Coheris, détaille les points clefs d’un chantier de Gestion de la Relation Citoyen (GRC) pour une collectivité publique.
A l’occasion de la publication du Carnet d’Expériences « Relation Citoyen », Coheris publie l’avis d’expert éditeur sur la GRC, l’une des interviews de ce dossier qui analyse les défis actuels et les relations de demain entre les citoyens et leurs administrations.
Combien de temps une collectivité doit–elle prévoir pour un projet de Gestion de la Relation Citoyen, une fois qu’elle a choisi sa solution informatique ?
Un tel projet se boucle rarement en moins de 6 mois. Il vaut mieux partir sur 6 à 12 mois. Les collectivités préfèrent prendre le temps de faire les choses bien. Car au delà de l’arrivée d’un nouvel outil informatique, un projet de GRC implique aussi une remise à plat de l’organisation du travail de leurs agents. On passe d’un processus de traitement des demandes artisanal où le papier est très présent, à un processus plus industriel, plus collaboratif où bon nombre d’échanges sont dématérialisés. Cela prend du temps.
Quelles sont les grandes étapes d’un chantier de GRC ?
J’en vois 7. Une fois que le choix de la solution est arrêté, on démarre avec la création des spécifications. Cette phase dure en général 3 mois. Il s’agit de définir les tâches que l’outil va gérer et comment il va le faire concrètement. Pour chaque demande d’un administré, par exemple, on détermine le circuit qu’elle suivra dans l’outil pour arriver jusqu’au service chargé d’y répondre.
Les spécifications sont de deux types : celles qui relèvent des processus métier, ce que l’on nomme le prototypage dans notre jargon, et celles qui ont trait au back-office informatique et que l’on appelle les spécifications techniques. Dans les premières, on détermine les règles de navigation dans l’outil, on construit les écrans et les pages sur lesquels les agents travailleront. Et on le fait avec eux dans le cadre d’ateliers afin de construire un outil qui réponde à leurs besoins. Dans les secondes, il s’agit de penser comment la solution va s’intégrer dans l’ensemble du système d’information de la collectivité. A l’issue de cette phase, on est à 7 mois de la mise en production. C’est là qu’intervient la première validation. La collectivité avalise le projet. Cela dure de 15 jours à un mois, car il y a nécessairement des points de discussion. A l’issue, on aboutit à un document : les spécifications détaillées fonctionnelles et techniques qui inscrit noir sur blanc les principes de fonctionnement de l’outil.
Les trois mois qui suivent (– 7 mois à – 4 mois) sont consacrés à la réalisation de l’outil à proprement dit. Nous transformons la solution conformément aux demandes du client. C’est le paramétrage.
Ce travail fait, la solution est prête ; elle est livrée au client. Il reste alors à vérifier in situ que l’outil s’intègre bien dans le système d’information. C’est la quatrième étape dite des recettes techniques, également appelée phase d’intégration. Il y a forcément de petites anomalies à corriger, ce qui fait que cette étape s’étale sur un mois.
Nous sommes maintenant à 3 mois de la mise en production. C’est le moment de vérifier les recettes fonctionnelles. C’est le pendant des recettes techniques, mais pour les processus métier cette fois. Nous vérifions avec les utilisateurs que l’outil répond à leurs exigences. Ce contrôle se fait au cours d’exercices de simulation. On lance des scenarii pour voir si l’outil répond conformément aux scripts. Des ajustements sont parfois nécessaires. Cette phase dure de 1 mois à 6 semaines.
La solution est maintenant finalisée. Il ne reste plus qu’à former tous les agents qui vont travailler dessus. Prévoyez pour cela de une à 4 semaines.
La septième et dernière étape, est enfin arrivée : c’est l’heure de la mise en production. Mais notre mission d’éditeur ne s’arrête pas là. Nous assurons une semaine d’assistance au démarrage où nous sommes prêts à répondre à la moindre anomalie, puis c’est la phase de vérification de service régulier ou (VSR). C’est un peu le pendant de la clause des vices cachés pour le bâtiment. La collectivité a 3 mois pour vérifier, en conditions normales de fonctionnement, que l’outil répond correctement.
Dans les collectivités, qui sont en général vos interlocuteurs sur de tels projets ?
La direction informatique en fait toujours partie. Après nous souhaitons que la direction métiers ou la directions usagers, selon les terminologies, c’est à dire les équipes opérationnelles, y prennent part également. C’est important que le directeur général des services soit aussi impliqué et sponsor du projet. Quant aux élus, nous les voyons rarement. Pourtant, il serait préférable de leur présenter l’avancement du projet à un ou deux moments clé, avant la mise en production.
Propos recueillis par Olivier Bitoun
**
GLOSSAIRE
Paramétrage : phase du projet au cours de laquelle l’éditeur de la solution de GRC l’adapte aux besoins spécifiques de son client.
Spécifications techniques : phase au cours de laquelle le client et l’éditeur travaillent sur le back-office. Ils envisagent comment la solution va s’intégrer dans l’ensemble du système d’information de la collectivité.
Prototypage ou spécifications fonctionnelles : phase au cours de laquelle le client et l’éditeur déterminent conjointement les caractéristiques de fonctionnement ou spécifications de l’outil. Il s’agit ici de définir les caractéristiques liées à l’usage métier de l’outil (ergonomie, règles de navigation, construction des pages…).
Recettes techniques ou phase d’intégration : phase au cours de laquelle, il s’agit de vérifier en conditions réelles avant de la mettre en service, si la solution de GRC communique correctement avec les autres applicatifs du système d’informations de la collectivité.
Recettes fonctionnelles : phase de vérification avec les utilisateurs futurs de la solution que l’outil répond à leurs besoins métier. Ce contrôle se fait généralement au cours d’exercices de simulation où l’on déroule des scenarii.
