7 Min. de lecture<\/p>\n
Depuis des ann\u00e9es, de nombreux fournisseurs proposent aux collectivit\u00e9s des formulaires en ligne et des solutions portails. Pourtant, de nombreuses proc\u00e9dures finissent de nouveau par \u00eatre trait\u00e9es manuellement, car les registres, les interfaces et les applications m\u00e9tier ne suivent pas. Qui souhaite v\u00e9ritablement investir le march\u00e9 de la num\u00e9risation communale doit cesser de se contenter de livrer des frontends. La logique des processus doit d\u00e9sormais \u00eatre int\u00e9gr\u00e9e au contrat.<\/strong><\/p>\n Articles connexes :<\/span>Gouvernance Kubernetes dans les environnements multi-cloud \/<\/span> Le Platform Engineering n’est plus un projet DevEx<\/p>\n La loi sur l’acc\u00e8s en ligne de 2017 avait fix\u00e9 un objectif clair : 575 services administratifs devaient \u00eatre accessibles num\u00e9riquement d’ici 2022. La r\u00e9alit\u00e9 en d\u00e9cide autrement. M\u00eame apr\u00e8s la loi de succession OZG 2.0, de nombreuses d\u00e9marches restent fragment\u00e9es sur le plan num\u00e9rique. Les citoyens remplissent des formulaires \u00e0 l’\u00e9cran, mais les pi\u00e8ces jointes PDF finissent dans l’imprimante de l’administration. Un agent humain se charge ensuite de ressaisir les donn\u00e9es dans l’application m\u00e9tier.<\/p>\n Du point de vue des fournisseurs, le contrat semble pourtant impeccable : frontend d\u00e9ploy\u00e9, authentification raccord\u00e9e, conformit\u00e9 OZG valid\u00e9e. Ce qui se passe en backend rel\u00e8ve du ma\u00eetre d’ouvrage. C’est pr\u00e9cis\u00e9ment l\u00e0 que r\u00e9side le v\u00e9ritable probl\u00e8me. L’interface avec l’application m\u00e9tier fait d\u00e9faut, l’identification repose sur un simple compte utilisateur, tandis que les registres et les syst\u00e8mes m\u00e9tier ne sont pas interconnect\u00e9s de bout en bout. La notification est ensuite exp\u00e9di\u00e9e par voie postale.<\/p>\n Les publications sp\u00e9cialis\u00e9es r\u00e9centes sur la num\u00e9risation administrative convergent vers le m\u00eame constat : tant que les interfaces en ligne seront d\u00e9velopp\u00e9es sans repenser les processus en amont, l’administration restera fondamentalement analogique. Le navigateur ne fait que masquer les ruptures entre le num\u00e9rique et la r\u00e9alit\u00e9 op\u00e9rationnelle.<\/p>\n Pour les architectes cloud et les ing\u00e9nieurs plateforme, il s’agit de bien plus qu’un simple d\u00e9bat administratif. Quiconque a accompagn\u00e9 des march\u00e9s publics ces trois derni\u00e8res ann\u00e9es conna\u00eet ce sch\u00e9ma : un ma\u00eetre d’\u0153uvre remporte l’appel d’offres relatif au frontend, tandis que l’int\u00e9gration dans le socle des applications m\u00e9tier communales est r\u00e9partie sur quatre autres lots. Chaque lot fait appel \u00e0 un fournisseur diff\u00e9rent, suit son propre calendrier et ob\u00e9it \u00e0 une logique de s\u00e9curit\u00e9 des donn\u00e9es qui lui est propre. Le r\u00e9sultat n’est pas une solution unifi\u00e9e, mais une succession de points de passage o\u00f9 la responsabilit\u00e9 se dilue.<\/p>\n Qui veut comprendre la num\u00e9risation communale doit prendre au s\u00e9rieux deux acronymes. Le F\u00f6derale Informationsmanagement, abr\u00e9g\u00e9 FIM, d\u00e9crit des prestations, des formulaires et des processus lisibles par machine. X\u00d6V fournit les normes XML gr\u00e2ce auxquelles les autorit\u00e9s \u00e9changent des informations. Les deux couches sont la condition pour que l\u2019application passe de la page web jusqu\u2019au syst\u00e8me m\u00e9tier sans rupture de m\u00e9dia.<\/p>\n En pratique, les \u00e9l\u00e9ments FIM sont bien disponibles, mais ils ne sont souvent pas int\u00e9gr\u00e9s. Les fournisseurs mettent en place leur propre logique de formulaire, car l\u2019appel d\u2019offres \u00e9value le frontend et non la conformit\u00e9 X\u00d6V. Le r\u00e9sultat est un service en ligne qui traite chaque nouvelle prestation OZG comme un cas particulier. Aucune mise \u00e0 l\u2019\u00e9chelle entre les communes n\u2019a lieu.<\/p>\n Pour les plateformes cloud, cela implique une exigence pr\u00e9cise. Les messages X\u00d6V ne sont pas un format sp\u00e9cial \u00e0 traiter dans le projet d\u2019int\u00e9gration. Ils doivent \u00eatre int\u00e9gr\u00e9s au niveau des donn\u00e9es comme d\u2019autres sch\u00e9mas. Celui qui construit une logique de locataire comprenant les donn\u00e9es FIM comme source et traitant nativement les messages X\u00d6V a un avantage architectural qu\u2019une biblioth\u00e8que d\u2019interface utilisateur ne peut remplacer.<\/p>\n \n”<\/span><\/p>\n Le Conseil de contr\u00f4le des normes critique \u00e9galement en 2024 le fait que le d\u00e9ploiement des services administratifs num\u00e9riques reste lent et que la num\u00e9risation bout-\u00e0-bout est souvent absente. L\u2019\u00e9cart se cr\u00e9e rarement au frontend, mais plut\u00f4t aux registres, aux interfaces et \u00e0 la connexion aux syst\u00e8mes m\u00e9tier.<\/p>\n<\/blockquote>\n<\/figure>\n Les architectes cloud et les fournisseurs d\u2019int\u00e9gration qui ont accompagn\u00e9 des projets OZG au cours des deux derni\u00e8res ann\u00e9es connaissent trois mod\u00e8les r\u00e9currents. Dans le premier mod\u00e8le, le fournisseur fournit le frontend, et le porteur doit lui-m\u00eame s\u2019occuper de l\u2019interface avec le syst\u00e8me m\u00e9tier. Cela arrive rarement, le service en ligne reste donc symbolique.<\/p>\n Dans le deuxi\u00e8me mod\u00e8le, la commune connecte le frontend \u00e0 un syst\u00e8me m\u00e9tier dont le fabricant ne documente pas l\u2019acc\u00e8s. La compatibilit\u00e9 est achet\u00e9e via des int\u00e9grations sp\u00e9ciales co\u00fbteuses. Plusieurs communes r\u00e9solvent le m\u00eame probl\u00e8me de mani\u00e8re isol\u00e9e, au lieu de le faire ensemble.<\/p>\n Dans le troisi\u00e8me mod\u00e8le, des \u00e9l\u00e9ments FIM existent, mais le syst\u00e8me m\u00e9tier ne les comprend pas. Les donn\u00e9es sont \u00e0 nouveau converties en PDF c\u00f4t\u00e9 backend et transmises au traitement. Le frontend semble moderne, mais les d\u00e9lais de traitement restent les m\u00eames. C\u2019est exactement l\u00e0 que les fournisseurs peuvent cr\u00e9er de la valeur ou non.<\/p>\n La r\u00e9ponse \u00e0 tous les trois mod\u00e8les est la m\u00eame : la compatibilit\u00e9 comme produit standard. Les fournisseurs cloud qui proposent des connecteurs vers les principaux fabricants de syst\u00e8mes m\u00e9tier comme produit lib\u00e8rent les communes du mode d\u2019achat individuel. Le b\u00e9n\u00e9fice ne vient pas du frontend, mais de la performance d\u2019int\u00e9gration. C\u2019est pr\u00e9cis\u00e9ment ce b\u00e9n\u00e9fice qui reste chez les fournisseurs qui prennent au s\u00e9rieux la sp\u00e9cificit\u00e9 communale.<\/p>\n Un appel d\u2019offres qui ne laisse plus les fournisseurs en dessous d\u00e9crit non seulement le formulaire en ligne, mais aussi le processus complet. Quelles donn\u00e9es FIM seront charg\u00e9es, quelles messages X\u00d6V iront vers quel registre, quel endpoint du syst\u00e8me m\u00e9tier sera utilis\u00e9, comment le d\u00e9cision sera-t-il remis en ligne. Les fournisseurs qui pensent \u00e0 cette logique avant la phase d\u2019offre gagnent les march\u00e9s qui deviennent vraiment productifs.<\/p>\n \n”<\/span><\/p>\n Celui qui vend \u00e0 une commune uniquement un frontend lui vend un promesse. Celui qui livre \u00e9galement la connexion aux registres, au FIM et aux syst\u00e8mes m\u00e9tier lui vend un r\u00e9sultat. Pr\u00e9cis\u00e9ment ces deux offres vont diverger au cours des prochaines ann\u00e9es.<\/p>\n<\/blockquote>\n<\/figure>\n Cela signifie concr\u00e8tement : v\u00e9rifier les contrats API avec le syst\u00e8me m\u00e9tier avant que le design des composants ne soit finalis\u00e9. Int\u00e9grer les messages X\u00d6V et les donn\u00e9es FIM dans l\u2019architecture, et non seulement lors du projet d\u2019int\u00e9gration. Construire des couches d\u2019acc\u00e8s que les communes peuvent r\u00e9utiliser sans avoir \u00e0 les acheter \u00e0 nouveau. Ceux qui ne le font pas seront d\u00e9pass\u00e9s lors des appels d\u2019offres des prochaines ann\u00e9es par ceux qui le feront.<\/p>\n La digitalisation municipale n\u2019est pas un march\u00e9 B2C pour des composants attrayants. C\u2019est un march\u00e9 distribu\u00e9 f\u00e9d\u00e9ralement, port\u00e9 par des processus et des interfaces. Les fabricants qui souhaitent \u00eatre compatibles avec leurs plateformes cloud ont besoin de connecteurs vers les proc\u00e9dures sp\u00e9cialis\u00e9es des leaders du march\u00e9, d\u2019un couche de mappage X\u00d6V document\u00e9e et d\u2019une r\u00e9ponse honn\u00eate \u00e0 la question de savoir qui assume la responsabilit\u00e9 du transfert des donn\u00e9es jusqu\u2019au compte citoyen.<\/p>\n Les march\u00e9s avec pr\u00e9qualification pourraient r\u00e9duire cet effort c\u00f4t\u00e9 fournisseurs. Si la pr\u00e9qualification aux exigences FIM, X\u00d6V et protection des donn\u00e9es se d\u00e9roule une seule fois sur une plateforme d\u2019acquisition municipale, les fournisseurs n\u2019auront plus besoin de prouver \u00e0 chaque appel d\u2019offres que leurs composants r\u00e9pondent \u00e0 ces exigences. Cela change l\u2019\u00e9conomie de la branche GovTech et rend la stabilisation planifiable.<\/p>\n Pour les architectes cloud et les \u00e9quipes de plateformes, cela signifie ne pas traiter les exigences municipales comme une niche. La r\u00e9sidence des donn\u00e9es, la tra\u00e7abilit\u00e9, la conformit\u00e9 FIM et l\u2019ancrage s\u00e9curis\u00e9 du compte citoyen sont des exigences architecturales qui d\u00e9passent d\u00e9sormais le cadre administratif. Qui construit aujourd\u2019hui proprement ces \u00e9l\u00e9ments, sert demain aussi bien les domaines de l\u2019\u00e9conomie priv\u00e9e qui travaillent selon des normes similaires.<\/p>\n La loi sur l’acc\u00e8s en ligne initiale de 2017 devait rendre 575 prestations administratives accessibles en ligne d’ici 2022. Cet objectif a \u00e9t\u00e9 manqu\u00e9. La loi de modification OZG, commun\u00e9ment appel\u00e9e OZG 2.0, reformule l’obligation et place davantage l’accent sur des processus enti\u00e8rement num\u00e9riques plut\u00f4t que sur une simple disponibilit\u00e9 frontend.<\/p>\n<\/details>\n FIM est la Gestion f\u00e9d\u00e9rale des informations et d\u00e9crit les prestations administratives, les champs de donn\u00e9es et les processus de mani\u00e8re uniforme et machine-lisible. X\u00d6V fournit les normes XML pour l’\u00e9change de donn\u00e9es entre administrations, par exemple entre une commune et un registre. Ces deux normes sont la condition pr\u00e9alable pour des services administratifs sans rupture de m\u00e9dia.<\/p>\n<\/details>\n Parce que les appels d’offres \u00e9valuent souvent uniquement le frontend. L’int\u00e9gration aux registres, aux proc\u00e9dures sp\u00e9cialis\u00e9es et \u00e0 la notification des d\u00e9cisions est souvent confi\u00e9e \u00e0 des appels d’offres ult\u00e9rieurs ou est absente. Sans ces int\u00e9grations, la demande en ligne reste un processus papier num\u00e9ris\u00e9 : saisie en ligne, traitement manuel.<\/p>\n<\/details>\nLes points cl\u00e9s en bref<\/h2>\n
\n
L\u00e0 o\u00f9 la promesse OZG fait d\u00e9faut<\/h2>\n
Ce que FIM et X\u00d6V portent vraiment<\/h2>\n
Trois configurations, une exp\u00e9rience<\/h2>\n
Ce que les fournisseurs doivent mettre sur la table aujourd\u2019hui<\/h2>\n
Comment les fabricants peuvent prendre le march\u00e9 au s\u00e9rieux<\/h2>\n
Foire aux questions<\/h2>\n
Quelle est la diff\u00e9rence entre OZG et OZG 2.0 ?<\/strong><\/summary>\n
Quels sont les acronymes FIM et X\u00d6V exactement ?<\/strong><\/summary>\n
Pourquoi les frontends OZG \u00e9chouent-ils si souvent sur le backend ?<\/strong><\/summary>\n