Guide pratique pour planifier, concevoir et lancer un portail d'information gouvernemental ou de services publics : accessibilité, contenu, sécurité, hébergement et maintenance.
Un portail de services publics ne peut pas être « tout pour tout le monde » dès le premier jour. Commencez par rédiger une déclaration d'objectif claire qui tienne sur une page et puisse être lue par les services achats, la direction et les équipes de terrain.
Décidez si le portail est principalement :
Cette décision influence tout le reste — de la structure du contenu à la vérification d'identité et au support.
Listez vos groupes clés et les tâches principales qu'ils doivent accomplir :
Restez pragmatique : les publics se définissent par ce qu'ils essaient de faire, pas par des critères démographiques.
Mettez-vous d'accord sur un petit ensemble de résultats mesurables, tels que :
Planifiez comment vous mesurerez ces éléments (analytics, invites de feedback courtes, étiquetage des centres d'appel).
Notez les réalités qui façonnent le périmètre :
Un bref document objectifs-et-métriques devient le point de référence lorsque les priorités se concurrencent plus tard — et maintient le projet centré sur la valeur publique.
Les bons portails gouvernementaux commencent par la clarté : que cherchent réellement à accomplir les utilisateurs à leur arrivée ? Si vous concevez autour des services internes, vous forcerez les résidents à traduire la bureaucratie en intentions simples. La recherche vous aide à inverser cela.
Commencez par collecter les « tâches principales » à partir des sources déjà disponibles :
Cherchez des schémas comme « renouveler », « postuler », « payer », « signaler », « vérifier le statut ». Ces verbes façonneront plus tard les libellés de navigation, les pages d'accueil et les flux de formulaires.
Choisissez une poignée de services prioritaires (par exemple : permis, prestations, paiements) et cartographiez le parcours du point de vue de l'utilisateur. Incluez :
Cela évite un portail qui explique des politiques mais n'aide pas les gens à terminer.
Gardez les personas simples et pratiques : « Quelqu'un qui demande une aide pour la première fois », « Un petit entrepreneur payant une taxe », « Un résident avec une maîtrise limitée du français ». Concentrez-vous sur les contraintes (temps, stress, appareil, alphabétisation, besoins d'accessibilité) plutôt que sur des données démographiques.
Faites de courts entretiens ou tests d'utilisabilité légers avec des prototypes ou même des croquis. Demandez aux participants d'accomplir des tâches clés et de narrer ce qu'ils s'attendent à trouver. Vous détecterez tôt des termes confus, des étapes manquantes et des problèmes de confiance — avant que le contenu et la construction ne se durcissent en retours coûteux.
Un portail de services publics réussit quand les gens peuvent trouver ce dont ils ont besoin rapidement — même s'ils ne savent pas quel service départemental en est responsable. L'architecture de l'information (IA) est la « carte » de votre site : quel contenu existe, comment il est regroupé et comment les utilisateurs s'y déplacent.
Avant de dessiner des menus, collectez ce que vous avez déjà :
Étiquetez chaque élément avec des métadonnées de base (thème, public, type de service, date de mise à jour, équipe propriétaire). Cela évite de reconstruire des pages existantes — et met en lumière le contenu obsolète ou dupliqué.
La plupart des résidents arrivent avec une intention : « renouveler un permis », « postuler pour une aide », « signaler un problème ». Structurez les catégories autour de ces tâches plutôt que des noms d'agences. Un test simple : si quelqu'un ne devine pas le bon élément de menu sans connaître la structure gouvernementale, le regroupement doit être retravaillé.
Quand plusieurs agences contribuent à un même parcours, traitez-le comme un service unique avec des étapes claires. Liez les pages de support (exigences, documents nécessaires, contacts) depuis un hub de service unique.
Visez les services clés en 2–3 clics depuis la page d'accueil. Utilisez un petit ensemble de catégories de premier niveau, plus des raccourcis bien en vue pour les tâches à forte demande. Évitez les « mega menus » remplis de termes internes ; utilisez des libellés clairs que les gens prononceraient à voix haute.
La recherche devient souvent la navigation principale. Planifiez-la intentionnellement :
Bien faite, votre IA et la navigation réduisent les appels, les réclamations et les abandons — tout en rendant le portail calme et digne de confiance.
L'accessibilité n'est pas un « plus » pour un site gouvernemental — c'est faire en sorte que les services soient accessibles à tous. Visez la conformité WCAG (typiquement WCAG 2.2 AA) et traitez l'accessibilité comme une exigence de conception, pas comme une revue finale.
Utilisez une structure de page claire : un seul titre principal (H1), sous-titres logiques (H2/H3) et un texte de lien descriptif (évitez « cliquez ici »). Une navigation cohérente et des mises en page prévisibles aident tout le monde, y compris les personnes ayant des troubles cognitifs et les utilisateurs de lecteurs d'écran.
Facilitez la lisibilité : choisissez des contrastes élevés, maintenez des longueurs de ligne confortables et évitez les textes microscopiques. Les éléments interactifs doivent avoir des états de focus cohérents pour que les utilisateurs au clavier sachent toujours où ils se trouvent.
Les contrôles automatisés sont utiles, mais ils ne repèrent pas tout. Incluez des tests manuels dans votre définition de fini :
Le design inclusif concerne aussi les mots. Utilisez un langage simple, expliquez les étapes requises et évitez le jargon et les acronymes non expliqués. Si un terme doit être utilisé (p. ex. un terme juridique), définissez-le là où il apparaît.
Les formulaires sont souvent le point de blocage. Assurez-vous que chaque champ a une étiquette visible, un texte d'aide clair là où la confusion est probable, et des messages d'erreur précis annoncés aux technologies d'assistance (par exemple, « Entrez votre numéro de sécurité sociale » plutôt que « Entrée invalide »). Ne vous fiez pas à la couleur seule pour indiquer les erreurs.
Ajoutez une déclaration d'accessibilité expliquant le statut de conformité, les problèmes connus et les options de contact pour signaler des problèmes. Placez-la dans un lien de pied de page cohérent (par ex. /accessibility) et assurez-vous que les retours sont surveillés et traités.
Commencez par décider si le portail est principalement d'information, de transactions, ou les deux avec un petit ensemble de services pour le lancement. Ensuite, rédigez une déclaration d'objectif d'une page et mettez-vous d'accord sur quelques résultats mesurables (par exemple : taux de réussite des tâches, réduction des appels, temps de publication des mises à jour).
Cela maintient le périmètre réaliste et fournit un point de référence lorsque les priorités entrent en conflit.
Nommez les publics selon les tâches qu'ils doivent accomplir, pas selon des critères démographiques. Les groupes typiques incluent les résidents, les visiteurs, les entreprises et le personnel interne.
Pour chacun, listez les tâches principales comme « postuler », « renouveler », « payer », « signaler », ou « vérifier le statut », et utilisez ces tâches pour guider la navigation et les priorités de contenu.
Utilisez des métriques qui reflètent de vrais résultats de service et sont faciles à suivre :
Décidez dès le départ comment vous allez les mesurer (analytics, invites de feedback, étiquetage des appels).
Commencez par les signaux de demande dont vous disposez déjà :
Recherchez des verbes récurrents (« postuler », « renouveler », « payer ») puis validez par de rapides entretiens ou tests d'utilisabilité avant de vous engager dans une construction complète.
Cartographiez le parcours pour une poignée de services à fort impact du point de vue de l'utilisateur :
Cela évite un portail qui explique des politiques sans aider les gens à terminer leurs démarches.
Faites d'abord un inventaire de contenu honnête (pages, PDF, formulaires, microsites) et étiquetez les éléments avec des métadonnées de base comme le sujet, le propriétaire et la date de dernière mise à jour.
Organisez ensuite la navigation autour des tâches des usagers (par ex. « Postuler », « Payer », « Signaler »), en visant l'accès aux services clés en 2–3 clics depuis la page d'accueil.
Considérez l'accessibilité comme une exigence de conception et une définition de « terminé ». Pratiques clés :
Publiez une déclaration d'accessibilité à un chemin cohérent comme /accessibility et fournissez un canal de retour surveillé.
Définissez un système simple pour qui écrit, révise, approuve, publie et met à jour le contenu — avec des rôles nommés, pas « le département ».
Ajoutez des règles de cycle de vie (dates de révision, archivage) et un guide de style qui normalise la terminologie, le formatage (dates/heures/adresses) et la rédaction des liens. Cela maintient l'information exacte et cohérente dans le temps.
Priorisez la traduction des pages qui affectent la capacité d'une personne à accomplir ses tâches principales :
Évitez la traduction automatique pour les instructions critiques (juridiques/sécurité/financières). Assurez-vous que le sélecteur de langue garde l'utilisateur sur la même page et intégrez le statut de traduction et les délais de revue dans le workflow éditorial.
Choisissez un CMS qui prend en charge les permissions par rôle, les workflows d'approbation, les pistes d'audit et l'historique des versions avec restauration facile. Structurez le contenu en champs (éligibilité, frais, délais de traitement, documents) pour pouvoir le réutiliser dans les résultats de recherche et les pages liées.
Planifiez les intégrations tôt (formulaires, paiements, systèmes de dossiers, réservation) et définissez des impératifs comme HTTPS, MFA pour le personnel, minimisation des données, cache/CDN pour les pages publiques et supervision dès le jour 1.
