Un habitant qui veut régler une démarche auprès d’une administration compare cette expérience non pas à une autre administration, mais à sa banque et à sa boutique en ligne préférée. Il attend de pouvoir déposer une demande depuis son téléphone, à toute heure, et de voir exactement où en est son dossier. C’est pourquoi un portail citoyen et des services publics en ligne ont cessé d’être un supplément à l’administration pour en devenir le premier guichet, souvent le seul qu’un habitant visitera jamais.
D’après notre expérience, le plus difficile dans un tel projet n’est pas le formulaire lui-même, mais ce qui se passe après son dépôt : validation, circuit du dossier, statuts, intégrations avec les systèmes métier, et les exigences strictes d’accessibilité et de sécurité. Nous ne prétendons pas avoir livré un portail citoyen clé en main, mais nous avons accompagné des institutions publiques sur le plan technique, et nous savons concevoir un tel système et le doter des personnes qui le construiront et le maintiendront.
Qu’attendent aujourd’hui les citoyens des services publics en ligne ?
Les applications commerciales fixent le niveau d’exigence : un habitant suppose donc qu’une démarche publique peut se régler entièrement en ligne et qu’il n’aura rien à imprimer ni à se déplacer pour déposer un document. Ce changement d’attentes se traduit par quelques exigences fermes pour le système :
- un accès depuis le téléphone par défaut, et non une version de repli du site de bureau,
- un point d’entrée unique vers de nombreuses démarches, au lieu d’un portail par service,
- un statut transparent, c’est-à-dire une information claire sur ce qui se passe avec la demande et ce que l’administration attend encore,
- un minimum de ressaisie de données que l’administration détient déjà.
Si l’un de ces points échoue, l’habitant revient au guichet et tout l’intérêt de la numérisation se dissout.
Comment concevoir un portail citoyen et des formulaires en ligne ?
Un portail citoyen est en pratique un catalogue structuré de démarches, pas un amas de pages isolées. Chaque e-service doit guider l’habitant pas à pas, veiller à la complétude des données avant l’envoi et refuser d’accepter une demande qui ne reviendrait que pour correction.
Nous concevons la couche de formulaires autour d’une validation côté navigateur et côté serveur : les champs sont contrôlés à la saisie, tandis que les règles métier (dépendances entre champs, pièces jointes obligatoires) sont appliquées par le backend. Lorsque la loi exige une confirmation d’identité ou une demande signée, le système s’intègre à l’identité et à la signature électroniques (en termes généraux : noeuds d’identité nationaux, e-ID, signatures qualifiées) plutôt que de bâtir son propre mécanisme bancal. Le formulaire enregistre aussi des brouillons, pour qu’un habitant puisse terminer plus tard, et les données saisies une fois sont reprises dans les étapes suivantes.
Comment fonctionnent le traitement des dossiers et le suivi des statuts ?
Un formulaire déposé devient un dossier avec son propre cycle de vie. C’est là que se décide si la numérisation soulage vraiment l’administration ou si elle déplace simplement le papier sur un écran. Un bon module de dossiers porte une demande du dépôt, par la vérification et une éventuelle demande de pièces complémentaires, jusqu’à la décision, et chacune de ces étapes laisse une trace visible par l’agent comme par le citoyen.
Pour l’habitant, ce qui compte, c’est un statut et un historique de dossier lisibles : ce que l’administration a déjà fait, ce qu’elle attend du demandeur et pour quand. Pour l’administration, le circuit interne compte tout autant, c’est-à-dire l’affectation des dossiers, les files, les délais et l’intégration avec la gestion électronique de documents et les systèmes métier. Nous concevons ce circuit pour que les statuts montrés au citoyen découlent directement de l’état du dossier dans le système, au lieu d’être mis à jour à la main.
Comment ajouter la prise de rendez-vous aux e-services ?
Toutes les démarches ne peuvent pas se clore à distance, et la prise de rendez-vous en ligne a donc sa place dans le portail plutôt que dans un outil séparé. Nous la relions au calendrier de l’administration et à un dossier précis, pour que l’habitant réserve un créneau au bon guichet et sache d’avance quels documents apporter.
Un module de réservation bien construit raccourcit les files, étale le trafic dans le temps et réduit les absences grâce aux rappels. Les détails décident de son utilité :
- une disponibilité des créneaux calculée à partir des effectifs réels des guichets, et non saisie à la main,
- un lien entre le rendez-vous et le dossier, pour que l’agent soit préparé avant la rencontre,
- une annulation et une modification faciles, qui libèrent le créneau pour d’autres.
Comment construire les notifications par e-mail et SMS pour les habitants ?
Un système qui n’informe pas oblige le citoyen à se reconnecter « au cas où ». Nous traitons donc les notifications par e-mail et SMS comme une partie du traitement des dossiers : nous les envoyons lors d’un changement de statut, d’une demande de pièces complémentaires et avant un rendez-vous réservé. Nous les bâtissons sur des files et des modèles, avec un journal de remise, une gestion des erreurs et des relances, et dans le respect des consentements et des règles de traitement des données. Le contenu d’une notification renvoie toujours au dossier dans le portail, au lieu de déplacer des données sensibles dans le message.
Pourquoi l’accessibilité (WCAG) est-elle une exigence, et non un supplément ?
Dans le secteur public, l’accessibilité numérique conforme aux WCAG est une obligation légale, pas un confort ajouté à la fin. Le portail doit fonctionner avec un lecteur d’écran, au clavier seul et avec un texte agrandi, tandis que le contraste et la structure des titres doivent être corrects dès le départ. Nous intégrons donc l’accessibilité dès la conception des interfaces et la surveillons pendant tout le développement, car la rattraper plus tard revient généralement à réécrire des composants. En prime, tous les utilisateurs en profitent, pas seulement les personnes en situation de handicap.
Comment traiter la sécurité et l’identité dans un portail citoyen ?
Le portail traite des données personnelles et des décisions administratives : la sécurité et la gestion des identités en sont donc un fondement, pas une couche cosmétique. Nous fondons l’authentification sur des standards éprouvés (par exemple OpenID Connect) et sur les noeuds d’identité nationaux, au lieu de maintenir nos propres mots de passe là où ce n’est pas nécessaire. S’y ajoutent le contrôle d’accès par rôles, le chiffrement des données en transit et au repos, des journaux d’audit complets et la conformité au RGPD et aux exigences nationales de sécurité. Ces éléments se conçoivent dès le départ, car les ajouter plus tard coûte cher et comporte des risques.
Quelles compétences fournissons-nous pour un projet d’e-services ?
C’est là que commence notre rôle réel. Même si nous ne mettons pas en avant un portail citoyen clé en main, nous fournissons les personnes qui conçoivent, écrivent et maintiennent de tels systèmes, et nous pourvoyons les rôles selon le cahier des charges du projet :
- un architecte de solution qui relie le portail, le circuit des dossiers et les intégrations,
- des développeurs backend et frontend pour les formulaires en ligne, le module de dossiers et les notifications,
- un spécialiste de l’intégration pour les noeuds d’identité, la gestion documentaire et les systèmes métier,
- un expert accessibilité et QA qui veille aux WCAG et à la qualité,
- un ingénieur DevOps qui construit les déploiements, les environnements et la supervision.
Nous construisons l’équipe autour du périmètre et vérifions les compétences avant le démarrage, plutôt que de doter un projet « au cas où ».
Comment procédons-nous chez RITS ?
Nous intervenons en partenaire nearshore depuis la Pologne qui complète l’équipe d’une institution par les compétences manquantes, sans se substituer à sa responsabilité. Nous avons l’expérience d’un accompagnement technique d’une institution publique et de la construction de systèmes transactionnels où comptent le flux de données, la sécurité et les intégrations. Nous travaillons dans votre fuseau horaire, rejoignons vos revues de code et vos réunions sans longue montée en charge, et faisons grandir l’équipe sous la direction du client. Le plus souvent, nous procédons en logiciel sur mesure construit par notre équipe, ou en renfort d’équipe lorsqu’il faut compléter vite les compétences. Comment choisir entre ces modèles, nous l’avons traité dans notre article sur les modèles de collaboration IT.
Par où commencer pour construire des e-services aux citoyens ?
Commencez par la démarche la plus souvent déposée et parcourez-la à l’envers, c’est-à-dire depuis son traitement à l’intérieur de l’administration et les systèmes qu’elle doit toucher. Cela définit le périmètre du formulaire en ligne, le modèle de circuit, l’ensemble des intégrations et les rôles dont vous avez besoin. Le premier e-service réellement abouti, avec validation, statuts, notifications et accessibilité, devient le gabarit que vous répliquez sur les démarches suivantes, au lieu de bâtir dix portails incohérents.
Vous construisez un portail citoyen ou des services publics en ligne ? Parlons-en - nous adapterons une équipe et une architecture à votre institution.