Cadrer un projet UX dans les services publics au Québec n'est pas une étape « pré-projet » qu'on expédie avant d'attaquer Figma. C'est la phase qui détermine si un programme de 18 à 36 mois tiendra ses promesses ou glissera d'un trimestre à chaque audit de conformité. Cet article décrit la méthode en 4 phases telle que je l'ai appliquée chez Levio sur le portail PISG du Ministère de la Famille du Québec, livré en 2025 pour 250 000 familles québécoises. La méthode est générique — les chiffres sont ceux d'un projet livré. Cible lecteur : Product Manager, CTO, équipes produit qui préparent un portail citoyen, un service public numérique ou un parcours d'enrôlement au Québec.
Pourquoi le cadrage occupe le premier mois.
Un Senior Product Designer en services publics québécois ne part pas de la maquette. Le cadrage occupe les premières semaines — parfois le premier mois entier.
La raison tient en trois verrous qu'on ne lève pas en sprint planning. Le premier : plusieurs ministères se croisent sur un même périmètre, chacun avec son arbitrage, son cycle de validation, sa terminologie. Le deuxième : les cadres réglementaires (WCAG 2.1 AA, Loi 95, Système de design gouvernemental du Québec) sont des prérequis fixes, pas des paramètres ajustables. Le troisième : les workflows réels — ceux des parents, des agents publics, des partenaires métier — n'apparaissent pas dans le brief.
Le coût d'un mauvais cadrage est mécanique. Refaire au sprint 6 quand un blocage Loi 95 ou un défaut WCAG arrive tard, c'est multiplier par les cycles de validation conformité encore à franchir — un trimestre perdu chaque fois. À l'inverse, un cadrage serré sur les 3-6 premières semaines tient la route pendant les 18 à 36 mois suivants.
Sur le portail PISG (Levio / Ministère de la Famille du Québec, livré 2025), ces premières semaines ont servi à cartographier 4 ministères impliqués, 3 profils utilisateurs (parents, agents CPE, agents ministère) et à arrimer un guichet unique à un parc d'outils existant — pas à dessiner d'écrans. Le périmètre minimum testable n'a été validé qu'après cette phase. C'est cette discipline qui a rendu possible la migration de 250 000 familles depuis l'ancien portail La Place 0-5 sans incident bloquant au lancement.
Le cadrage n'est pas un préambule. C'est la phase qui produit le plus de levier sur le résultat final.
Phase 1 — Cartographier les parties prenantes et leurs contraintes.
Le premier livrable du cadrage n'est pas un écran — c'est une matrice de parties prenantes. Elle croise quatre catégories sur le terrain québécois.
- Métier : le ministère commanditaire, ses agences déléguées, ses partenaires terrain (sur PISG, les CPE et garderies subventionnées). Ce sont eux qui détiennent la connaissance du workflow réel.
- Conformité : juridique, accessibilité, langue française (Loi 95), parfois protection de la vie privée (loi 25 au Québec). Chaque conformité a son cycle de validation, son délai, son pouvoir de bloquer.
- Tech : équipes sécurité, intégrations existantes (CRM, ERP, identité numérique). Sur PISG, l'orchestration passait par Salesforce — non négociable.
- Utilisateurs : citoyens, agents internes, partenaires terrain. Pas une catégorie homogène — trois protocoles de recherche différents.
Pour chaque partie prenante, on documente quatre points : son pouvoir d'arbitrage (qui peut bloquer quoi), la contrainte apportée (réglementaire, technique, métier), son cycle de validation (jours, semaines, mois), et sa fréquence de sollicitation sur le projet.
Cette matrice n'est pas un exercice cosmétique. Elle évite l'erreur classique consistant à traiter compliance, juridique et accessibilité en séquence — celle où on découvre un blocage Loi 95 au sprint 6. Le modèle correct est dual-track : la discovery utilisateur et la validation conformité avancent en parallèle, pas l'une après l'autre.
Sur PISG, 4 ministères se croisaient sur un seul maître d'ouvrage (le Ministère de la Famille du Québec). Équipe pluri-disciplinaire métier, conformité, tech sur deux ans, 5 designers. La matrice était mise à jour à chaque palier — pas figée en début de projet.
Phase 2 — Recenser les cadres réglementaires applicables.
En services publics québécois, l'accessibilité et la conformité linguistique ne sont pas des bonnes pratiques — ce sont des obligations légales. Trois cadres se croisent.
WCAG 2.1 AA
Référence internationale d'accessibilité. Critères concrets pour un portail citoyen : contraste 4.5:1 minimum sur le texte courant, navigation clavier complète sans piège de focus, hiérarchie sémantique HTML correcte (un seul H1, structure cohérente), lecture lisible par lecteur d'écran (NVDA, JAWS, VoiceOver), landmark roles, libellés associés à chaque champ de formulaire.
Loi 95 (langue française au Québec)
Spécificité québécoise. Tout contenu citoyen doit être disponible en français — primauté sur toute alternative langue. La terminologie suit l'Office québécois de la langue française, pas le français de France pour les termes techniques. Les libellés sont explicites en FR-CA, pas des calques de l'anglais (un « courriel » et non un « email »).
Système de design gouvernemental du Québec
Référence pratique sur design.quebec.ca. Combine accessibilité (WCAG 2.1 AA déjà intégré dans les composants) et conformité linguistique FR-CA. Travailler à partir de ce système plutôt qu'un kit générique évite de re-tester l'accessibilité de chaque composant à la main, et garantit la cohérence visuelle entre les services publics québécois.
AODA si périmètre hors-QC
Si le service est consommé en Ontario (par exemple un portail interprovincial), l'Accessibility for Ontarians with Disabilities Act s'ajoute. C'est rare sur un portail purement québécois, mais à vérifier dès le cadrage — pas après.
En pratique, le test de conformité ne se réduit pas à une checklist Lighthouse. On teste aux limites avec des utilisateurs en situation de handicap — utilisateur aveugle sur NVDA, utilisateur motrice clavier-only, utilisateur cognitif sur parcours long. Un audit en fin de projet ne remplace pas ces tests.
Sur PISG, 100 % de conformité WCAG 2.1 AA a été atteinte sur le périmètre livré. Résultat d'un design pensé conforme dès la phase 2 — pas d'un correctif en fin de cycle.
Phase 3 — Discovery sur les workflows réels.
Le brief n'est jamais le workflow réel. En services publics, l'écart est souvent énorme : un formulaire papier scanné, un fichier Excel partagé en interne, des raccourcis téléphone entre agents, des contournements documentés dans aucune procédure.
La discovery sur les workflows réels obéit à trois principes en environnement expert.
Accès par intermédiaires métier
Pas de panel générique sur un service public. On passe par les chefs de service, les directions, parfois les syndicats, les partenaires terrain. Sur PISG, l'accès aux agents CPE et aux agents du ministère a été négocié via les directions de service, créneau par créneau — pas via un panel marketing.
Créneaux courts
Un médecin, un contrôleur aérien ou un agent public n'a pas une heure pour un test utilisateur. On négocie des sessions de 15 à 30 minutes maximum, on s'adapte aux horaires opérationnels, on ne perd pas de temps sur la mise en contexte (on l'a faite avant).
Observation in situ plutôt qu'hypothèses
On évite les questions du type « est-ce que vous utiliseriez ». On observe l'usage réel — parfois en shadowing, parfois en demandant de reproduire une tâche récente. C'est là que se cachent les vrais problèmes : un agent qui contourne le système, un raccourci clavier non documenté, un fichier Excel parallèle.
Sur PISG, trois profils utilisateurs avec trois protocoles distincts.
- Parents : citoyens hétérogènes, niveau numérique variable, multi-âges, francophones unilingues sur-représentés en région. Test in situ chez les familles ou via session distance courte.
- Agents CPE : experts terrain — vocabulaire métier dense, contraintes opérationnelles fortes (gestion places, listes d'attente, contractualisation). Shadowing prioritaire.
- Agents ministère : interne, multi-rôles, intégrations Salesforce. Test sur leurs propres outils existants pour comprendre le déficit fonctionnel.
Trois cibles, trois protocoles. Le coût d'un protocole unique appliqué aux trois aurait été un brief partiel — et donc des écrans qui auraient manqué les vrais pain points opérationnels.
Phase 4 — Définir un périmètre minimum testable.
Le cadrage se conclut sur un livrable précis : le périmètre minimum testable. Pas un MVP de fonctionnalité — un MVP de parcours.
La différence est structurelle. Un MVP de fonctionnalité demande « quel est le plus petit ensemble de fonctionnalités à livrer ». Un MVP de parcours demande « quel est le plus petit cas d'usage bout-en-bout qu'un utilisateur peut accomplir, instrumenté pour mesure ». Sur un portail citoyen, c'est par exemple : un parent peut s'identifier, soumettre une demande d'inscription, choisir trois préférences d'établissement, et recevoir une confirmation.
Ce périmètre est ensuite testé par paliers, pas en bloc.
Sessions courtes, paliers fréquents
10-15 minutes sur 1-2 écrans clés, 5-8 participants par palier. On valide une étape avant de débloquer la suivante. Cela évite la situation classique d'un test long en fin de cycle qui révèle un blocage majeur quand toutes les décisions de déploiement sont déjà figées.
Documentation continue pour l'audit trail
Chaque test produit un livrable : protocole utilisé, consentement signé, verbatim anonymisés, décisions design qui en découlent. C'est exigé par la conformité — et ça sécurise les arbitrages face au leadership quand une décision est challengée trois mois plus tard.
Coût d'une refonte tardive
En régulé, refaire un parcours au sprint 6 plutôt qu'au sprint 2 multiplie par le nombre de cycles de validation conformité encore à franchir. Sur un programme de 24 mois, c'est l'écart entre livrer à temps et glisser d'un trimestre.
Sur PISG, la validation utilisateur par paliers a été menée sur trois profils en parallèle de la discovery compliance. Les premiers paliers ont validé l'identification et la soumission ; les suivants la gestion des préférences ; les derniers les workflows internes des agents CPE et ministère. À aucun moment un parcours complet n'a été testé en fin de cycle « pour validation ».
Le périmètre minimum testable, validé en cadrage, est ensuite étendu à la roadmap 24-36 mois — pas l'inverse.
Ce que ça a produit sur le portail PISG.
Le portail PISG a été livré en 2025, après deux ans de programme. Équipe pluri-disciplinaire de 30 personnes (dont 5 designers) chez Levio pour le Ministère de la Famille du Québec. Cinq résultats mesurables.
- 100 % de conformité WCAG 2.1 AA atteinte sur le périmètre livré.
- 95 % de taux de succès en autonomie sur l'inscription, sans recours au support.
- ÷4 sur la charge du centre de relations clientèle — quatre fois moins d'appels qu'avec l'ancien portail La Place 0-5.
- −58 % de temps de saisie côté agents CPE.
- 250 000 familles québécoises migrées depuis l'ancien système.
Ces chiffres ne sont pas le résultat d'un design isolé. Ils sont le produit de la chaîne cadrage → conformité → discovery → mesure, portée par une équipe pluri-disciplinaire dès la phase 1. Aucun de ces résultats n'aurait été atteint si l'accessibilité, la conformité linguistique ou les workflows agents avaient été traités en fin de cycle.
Mon rôle sur ce périmètre : Lead UX chez Levio (société de conseil québécoise), mandataire du Ministère de la Famille du Québec. Cadrage initial, gouvernance design pluri-équipes, validations utilisateurs sur les trois profils, hand-off engineering continu. La méthode complète en 4 phases est documentée à part — elle articule réflexion business, architecture, découpage / prototypage et mesure d'impact.
Le portail unique remplace l'ancien système « La Place 0-5 » et orchestre l'inscription sur Salesforce. L'arrimage à l'existant ne pouvait pas être inventé en cours de route — greenfield n'existait pas. Ce qui s'inventait, c'était la qualité de l'expérience par-dessus une couche tech déjà décidée.
Ce que je referais autrement.
Une erreur centrale qu'il faut éviter de répliquer : concevoir le modèle « famille » sur un stéréotype — deux adultes et un ou plusieurs enfants dans un seul foyer. La réalité québécoise est plus diverse, et la modélisation des données qui en découle a un impact direct sur le parcours d'inscription.
Le vrai panorama des familles qui inscrivent en services de garde au Québec : familles monoparentales, familles recomposées (enfants partagés entre deux foyers), garde partagée avec deux adresses, grands-parents qui assument l'inscription, foyers d'accueil, configurations LGBTQ+. Sur un portail provincial, ces configurations ne sont pas des cas marginaux à traiter en V2 — ce sont des cas courants que le modèle doit absorber dès la V1.
L'impact technique est direct : qui peut inscrire un enfant ?, qui peut consulter une demande ?, qui peut modifier les préférences d'établissement ?, qui reçoit les notifications ? ne sont plus des champs implicites. Ce sont des règles métier explicites qui touchent le schéma de données, le contrôle d'accès et les écrans d'identification au démarrage du parcours. Un modèle stéréotypé qu'on déconstruit au sprint 6 = un trimestre de retravail.
À retenir pour un prochain cadrage en services publics au Québec : la première chose à challenger n'est pas le brief — c'est le modèle de domaine implicite que tout le monde porte sans s'en rendre compte. « Famille », « foyer », « parent », « adresse » sont des termes qui semblent simples et qui cachent une diversité réelle. Le cadrage doit produire le modèle explicite avant tout écran. Sur les services qui touchent à la cellule familiale, ce travail vaut bien deux semaines de plus en phase 1.
Synthèse — les 4 phases en un livrable.
Le cadrage d'un projet UX dans les services publics québécois tient en quatre phases enchaînées sur 3 à 6 semaines. Phase 1 : cartographier les parties prenantes (métier, conformité, tech, utilisateurs) avec leur pouvoir d'arbitrage, leur contrainte, et leur cycle de validation. Phase 2 : recenser les cadres réglementaires applicables (WCAG 2.1 AA, Loi 95, Système de design gouvernemental du Québec, AODA si périmètre interprovincial). Phase 3 : discovery sur les workflows réels par intermédiaires métier, créneaux courts, observation in situ. Phase 4 : définir un MVP de parcours bout-en-bout, testé par paliers, documenté pour l'audit trail.
Le livrable final n'est pas une maquette mais une matrice vivante : matrice des parties prenantes mise à jour à chaque palier, périmètre minimum testable validé par les trois profils utilisateurs, métrique cible verrouillée comme prérequis avant la moindre spécification produit. Cette matrice survit aux changements d'équipe sur la durée du programme — 24 à 36 mois sur un portail provincial — et sert d'argument quand un arbitrage est challengé plusieurs trimestres après l'avoir pris.
Sur PISG (Levio / Ministère de la Famille du Québec, livré 2025), cette discipline a produit 100 % de conformité WCAG 2.1 AA, 95 % d'autonomie utilisateur, une charge support divisée par 4, et 250 000 familles migrées sans incident bloquant. Ces résultats n'auraient pas été atteignables si les premières semaines avaient servi à dessiner des écrans plutôt qu'à cadrer.