Réflexions sur la dématérialisation via Publik

 

Dans la recherche d’une nouvelle organisation sur l’écosystème Publik pour la ville et l'eurometropole de Metz, j’apporte quelques éléments de précisions et réflexions. Le marché est à reconduire début 2022, après un retour d’expérience de 4 ans.

L’objectif est de trouver des leviers pour accélérer la modernisation des métiers et notre capacité à y répondre.

 

Le possible

La solution Publik peut être utile sur :

  • De la gestion de la relation usager par essence. La partie formulaire n’est qu’une petite partie ; portail agent, citoyen, base de connaissance, processus, statistiques…etc
  • Sur de la dématérialisation de procédure et processus
  • Sur la création de portail (elus, familles..)
  • Sur des applications métiers simples
  • Sur la réalisation de prototypes, « pièces à casser », de solution « sur mesures » afin de permettre des « passages à l’échelle » (ideation)

Nous pouvons discuter de ces cas, et trouver pour chacun des points des preuves par l’ exemple, dans le portefeuille de démarches.

 

Quel cout, quels moyens ?

Pour le territoire de l'eurometropole de Metz, d’un point de vue budget, les couts de fonctionnement actuels sont d’environ 30k€ par an, sans limite d’utilisateur, sans limites de démarches. Cette enveloppe contient l’hébergement, les maintenances applicatives et évolutives : autrement dit, 2 fois par mois, nous bénéficions des nouvelles fonctionnalités commandées par d’autres collectivités (GrandLyon, Strasbrourg, Montpelier…etc)… le travail de veille est nécessaire.

Que nous en fassions plus ou moins c’est le même prix (hors développements spécifiques) ; un argument intéressant dans les réductions et efficiences budgétaires auxquelles nous sommes contraints. Actuellement avec un peu mois de 100 000 demandes par an, nous sommes à 20 centimes d’euros par habitant métropolitain.

Le point d'achoppement n'est pas tant le budget, car des fincancements sont possibles, mais notre volonté à capitaliser sur la solution et notre autonomie.

La ressource et capacité à faire du « sur mesure » est le point critique à équilibrer : 

  • en fonction des usages et de ce que nous voulons faire (feuille de route, et positionnement)
  • entre des directions métiers (DSI mutualisée incluse)

La capacité à gagner notre degré d’autonomie, était un critère de notation des offres, et est un axe fort de la politique de développement de l’éditeur Entrouvert.

 

D’un point de vue direction métier

  • Pour le simple (démarche avec un formulaire sans champs conditionnels complexes, sans champs calculés, sans champs préremplis ou enrichis, sans geolocalisation, et surtout sans workflow), la direction métier peut se prendre en main sous réserves :
    • D’être un minimum orientée, conseillée (le simple pour nous est parfois compliqué ou pas possible par la direction métier). Ce point nécessite une entente collégiale.
    • D’être sensible au principe de Privacy by design, RGPD, statistics by design, éléments de langage et guides de bonnes pratiques. L’ensemble de ce point peut être à charge d’un réfèrent.
  • Pour ce qui n’est pas simple, un accompagnement est nécessaire, pour expliquer le champ du possible, discuter les processus métiers et proposer une assistance à maitrise d’ouvrage : ou par un réfèrent, ou par un CPI ou AMO si des processus sont à redéfinir.

 

La séparation fonctionnel et technique

De mon retour d’expérience, il n’y a pas lieu de séparer le technique du fonctionnel (voir présentation au club utilisateur)

  • En reprenant la matrice de referent technique et référent fonctionnel de la DSI de l'eurometropole de Metz, et en considérant la solution en saas, il n’y a pas de taches de la simple compétence du RT. En complément dans les préconisations Publik, le seul rôle existant est le role d'"administrateur fonctionnel". Les seuls référents nécessaires sont fonctionnels.
  • Pour les interopérabilités, workflows complexes, une expertise produit et développement est nécessaire.

La fonction de Réfèrent technique (au sens de la collectivité), n’est pas nécessaire.

L’usage que nous souhaitons faire de la solution doit être partagé pour définir le degré d’implication de la DSI :

  • Ou ne pas porter la solution, car elle ne couvre pas ou ne correspond pas à des cas d’usages
  • Ou à porter la solution, et faire évoluer le métier de RT en RF.

Pour être exploitée efficacement et en fonction des usages, la solution Publik ne doit pas être de la seule compétence d’une direction Relation Usager. Si l’écosystème couvre un périmètre ville et eurométropole, l’action de services support prend plus de sens. 

L'action des personnes en compétences sur la solution Publik, ne doit pas arriver en toute fin de la conceptualisation de nos processus et méthodes. Si l'idéation ne doit pas être dictée par les solutions techniques, elle ne peut pas pour autant multiplier les déclinaisons et solutions, mais apporter une cohérence dans les usages et dans le systéme d'information.

L'expertise des compétences Publik doit être intégrée dés la phase d'idéation. A la fois pour révéiller le champs du possible du numerique, pour apporter une cohérence, faciliter le prototypage et le passage à l'échelle, et réduire les temps de réalisation.

Publik n'est pas la réponse omnisciente, n'est pas "l'aplha et omega" au besoin, mais un sorte de "pate à modeler" qui peut être utilisée pour ce qu'elle sait faire (voir les usages dans le paragraphe "le possible"). Exploitons et rentabilisons nos solutions. Au pire, nous affinerons nos expressions de besoins et cahiers des charges. Les solutions techniques ne sont plus des freins, mais des solutions de plus en plus souples. 

Accélérons notre modernisation.

 

Pour partage et réflexions,

 

Olivier Renard