Formulaire en ligne sans backend équivaut à une gestion analogue avec URL

Depuis des années, de nombreux fournisseurs proposent aux collectivités des formulaires en ligne et des solutions portails. Pourtant, de nombreuses procédures finissent de nouveau par être traitées manuellement, car les registres, les interfaces et les applications métier ne suivent pas. Qui souhaite véritablement investir le marché de la numérisation communale doit cesser de se contenter de livrer des frontends. La logique des processus doit désormais être intégrée au contrat.

Les points clés en bref

Articles connexes :Gouvernance Kubernetes dans les environnements multi-cloud  /  Le Platform Engineering n’est plus un projet DevEx

Là où la promesse OZG fait défaut

La loi sur l’accès en ligne de 2017 avait fixé un objectif clair : 575 services administratifs devaient être accessibles numériquement d’ici 2022. La réalité en décide autrement. Même après la loi de succession OZG 2.0, de nombreuses démarches restent fragmentées sur le plan numérique. Les citoyens remplissent des formulaires à l’écran, mais les pièces jointes PDF finissent dans l’imprimante de l’administration. Un agent humain se charge ensuite de ressaisir les données dans l’application métier.

Du point de vue des fournisseurs, le contrat semble pourtant impeccable : frontend déployé, authentification raccordée, conformité OZG validée. Ce qui se passe en backend relève du maître d’ouvrage. C’est précisément là que réside le véritable problème. L’interface avec l’application métier fait défaut, l’identification repose sur un simple compte utilisateur, tandis que les registres et les systèmes métier ne sont pas interconnectés de bout en bout. La notification est ensuite expédiée par voie postale.

Les publications spécialisées récentes sur la numérisation administrative convergent vers le même constat : tant que les interfaces en ligne seront développées sans repenser les processus en amont, l’administration restera fondamentalement analogique. Le navigateur ne fait que masquer les ruptures entre le numérique et la réalité opérationnelle.

Pour les architectes cloud et les ingénieurs plateforme, il s’agit de bien plus qu’un simple débat administratif. Quiconque a accompagné des marchés publics ces trois dernières années connaît ce schéma : un maître d’œuvre remporte l’appel d’offres relatif au frontend, tandis que l’intégration dans le socle des applications métier communales est répartie sur quatre autres lots. Chaque lot fait appel à un fournisseur différent, suit son propre calendrier et obéit à une logique de sécurité des données qui lui est propre. Le résultat n’est pas une solution unifiée, mais une succession de points de passage où la responsabilité se dilue.

Ce que FIM et XÖV portent vraiment

Qui veut comprendre la numérisation communale doit prendre au sérieux deux acronymes. Le Föderale Informationsmanagement, abrégé FIM, décrit des prestations, des formulaires et des processus lisibles par machine. XÖV fournit les normes XML grâce auxquelles les autorités échangent des informations. Les deux couches sont la condition pour que l’application passe de la page web jusqu’au système métier sans rupture de média.

En pratique, les éléments FIM sont bien disponibles, mais ils ne sont souvent pas intégrés. Les fournisseurs mettent en place leur propre logique de formulaire, car l’appel d’offres évalue le frontend et non la conformité XÖV. Le résultat est un service en ligne qui traite chaque nouvelle prestation OZG comme un cas particulier. Aucune mise à l’échelle entre les communes n’a lieu.

Pour les plateformes cloud, cela implique une exigence précise. Les messages XÖV ne sont pas un format spécial à traiter dans le projet d’intégration. Ils doivent être intégrés au niveau des données comme d’autres schémas. Celui qui construit une logique de locataire comprenant les données FIM comme source et traitant nativement les messages XÖV a un avantage architectural qu’une bibliothèque d’interface utilisateur ne peut remplacer.

Trois configurations, une expérience

Les architectes cloud et les fournisseurs d’intégration qui ont accompagné des projets OZG au cours des deux dernières années connaissent trois modèles récurrents. Dans le premier modèle, le fournisseur fournit le frontend, et le porteur doit lui-même s’occuper de l’interface avec le système métier. Cela arrive rarement, le service en ligne reste donc symbolique.

Dans le deuxième modèle, la commune connecte le frontend à un système métier dont le fabricant ne documente pas l’accès. La compatibilité est achetée via des intégrations spéciales coûteuses. Plusieurs communes résolvent le même problème de manière isolée, au lieu de le faire ensemble.

Dans le troisième modèle, des éléments FIM existent, mais le système métier ne les comprend pas. Les données sont à nouveau converties en PDF côté backend et transmises au traitement. Le frontend semble moderne, mais les délais de traitement restent les mêmes. C’est exactement là que les fournisseurs peuvent créer de la valeur ou non.

La réponse à tous les trois modèles est la même : la compatibilité comme produit standard. Les fournisseurs cloud qui proposent des connecteurs vers les principaux fabricants de systèmes métier comme produit libèrent les communes du mode d’achat individuel. Le bénéfice ne vient pas du frontend, mais de la performance d’intégration. C’est précisément ce bénéfice qui reste chez les fournisseurs qui prennent au sérieux la spécificité communale.

Ce que les fournisseurs doivent mettre sur la table aujourd’hui

Un appel d’offres qui ne laisse plus les fournisseurs en dessous décrit non seulement le formulaire en ligne, mais aussi le processus complet. Quelles données FIM seront chargées, quelles messages XÖV iront vers quel registre, quel endpoint du système métier sera utilisé, comment le décision sera-t-il remis en ligne. Les fournisseurs qui pensent à cette logique avant la phase d’offre gagnent les marchés qui deviennent vraiment productifs.

Cela signifie concrètement : vérifier les contrats API avec le système métier avant que le design des composants ne soit finalisé. Intégrer les messages XÖV et les données FIM dans l’architecture, et non seulement lors du projet d’intégration. Construire des couches d’accès que les communes peuvent réutiliser sans avoir à les acheter à nouveau. Ceux qui ne le font pas seront dépassés lors des appels d’offres des prochaines années par ceux qui le feront.

Comment les fabricants peuvent prendre le marché au sérieux

La digitalisation municipale n’est pas un marché B2C pour des composants attrayants. C’est un marché distribué fédéralement, porté par des processus et des interfaces. Les fabricants qui souhaitent être compatibles avec leurs plateformes cloud ont besoin de connecteurs vers les procédures spécialisées des leaders du marché, d’un couche de mappage XÖV documentée et d’une réponse honnête à la question de savoir qui assume la responsabilité du transfert des données jusqu’au compte citoyen.

Les marchés avec préqualification pourraient réduire cet effort côté fournisseurs. Si la préqualification aux exigences FIM, XÖV et protection des données se déroule une seule fois sur une plateforme d’acquisition municipale, les fournisseurs n’auront plus besoin de prouver à chaque appel d’offres que leurs composants répondent à ces exigences. Cela change l’économie de la branche GovTech et rend la stabilisation planifiable.

Pour les architectes cloud et les équipes de plateformes, cela signifie ne pas traiter les exigences municipales comme une niche. La résidence des données, la traçabilité, la conformité FIM et l’ancrage sécurisé du compte citoyen sont des exigences architecturales qui dépassent désormais le cadre administratif. Qui construit aujourd’hui proprement ces éléments, sert demain aussi bien les domaines de l’économie privée qui travaillent selon des normes similaires.

Foire aux questions

Plus dans le réseau MBF Media

Source de l’image : générée par IA (mai 2026)