ONISEP · Programme national Avenir(s)
Plateforme nationale d’orientation Avenir(s)
Concevoir le socle d’un service public numérique destiné aux élèves, aux enseignants et aux psychologues de l’Éducation nationale — sous contrainte de design system d’État et d’accessibilité réglementaire.
01
Contexte & problème
Avenir(s) est le programme national d’orientation porté par l’ONISEP. L’ambition : donner à chaque élève un espace pour construire son parcours dans la durée — pas un annuaire de métiers de plus, mais un outil de projection utilisable en classe, chez soi, et par les adultes qui accompagnent.
Le produit existant avait été construit par sédimentation : chaque nouvelle brique ajoutait ses propres composants, sa propre navigation, ses propres règles. Résultat, trois problèmes simultanés.
- Un problème d’usage. Les élèves ne revenaient pas. Le service était consulté comme une documentation, pas utilisé comme un outil.
- Un problème de système. Aucun langage d’interface commun entre les modules, donc un coût de conception et de développement qui augmentait à chaque itération.
- Un problème réglementaire. Opérateur de l’État, l’ONISEP est tenu par le RGAA. L’accessibilité ne pouvait pas rester un chantier de fin de cycle.
Comment concevoir un socle d’interface commun, strictement conforme au Système de Design de l’État, qui accélère la production des équipes au lieu de la contraindre ?
Trois publics, trois logiques d’usage
L’élève cherche à se projeter et abandonne vite si l’effort demandé n’est pas immédiatement récompensé. L’enseignant a besoin de suivre une classe entière en quelques minutes, entre deux cours. Le psychologue de l’Éducation nationale (PSY-EN) travaille sur des situations individuelles et a besoin de profondeur, pas de synthèse. Un même design system devait servir ces trois logiques sans se fragmenter.
02
Research & insights
Le diagnostic a été mené en méthodes mixtes, pour que chaque décision de conception puisse être défendue par une donnée et pas par une opinion.
Entretiens semi-directifs — élèves, professeurs principaux et PSY-EN sur 3 académies, guide en 5 blocs
Réponses à un questionnaire stratifié par académie et par voie, marge d’erreur ± 2,8 % à 95 %
Observations en situation (contextual inquiry), en classe et en salle d’orientation
Ce que la donnée a montré
- 62 % d’abandon avant le troisième écran. Le parcours demandait un engagement long avant de rendre quoi que ce soit à l’élève.
- 1,4 session par élève et par trimestre. Un usage ponctuel, jamais un usage de suivi — alors que le produit était conçu comme un carnet de bord.
- 71 % des professeurs principaux tenaient un tableur en parallèle. Le signal le plus net : quand un utilisateur recrée l’outil à côté de l’outil, ce n’est pas un problème d’adoption, c’est un problème de conception.
Les verbatims ont été codés par affinity mapping, ce qui a fait émerger quatre thèmes de friction : l’effort non récompensé, l’absence de continuité entre les sessions, l’illisibilité de la progression et la charge de suivi côté enseignant.
« Je remplis, et après je ne sais pas ce que ça me donne. Alors la fois d’après, je ne remplis pas. »
Analyse concurrentielle
Benchmark des plateformes d’orientation françaises et européennes, ainsi que des produits grand public qui réussissent la mécanique de progression (parcours guidés, jalons, restitution immédiate). L’enseignement principal : la valeur perçue doit arriver avant la fin du parcours, pas à la fin.
03
Exploration & solution
La refonte s’est organisée autour de trois principes de conception, arbitrés avec les Product Owners lors d’ateliers de cadrage réunissant équipes produit, experts métier et représentants du terrain éducatif.
1. Rendre quelque chose à chaque étape
Le parcours a été redécoupé en séquences courtes, chacune produisant une restitution visible immédiatement. L’élève ne « remplit » plus un formulaire long : il construit un profil qui se précise au fur et à mesure et reste consultable entre deux sessions.
2. Rendre la progression lisible
Introduction d’un état de progression persistant, visible dès l’entrée, avec reprise explicite là où l’élève s’était arrêté. La continuité entre sessions devient une propriété de l’interface, pas un effort de mémoire.
3. Donner à l’enseignant la vue qu’il recréait ailleurs
La fonctionnalité la plus discutée a été tranchée par la donnée : puisque 71 % des professeurs principaux tenaient un tableur parallèle, l’interface devait fournir nativement une vue classe triable et lisible en un coup d’œil, avec repérage des élèves en difficulté.
Un onboarding riche avait été proposé en atelier. Les tests ont montré qu’il déplaçait l’abandon sans le réduire : il a été remplacé par une première séquence utile de moins de deux minutes. La donnée a tranché contre l’intuition de l’équipe — la mienne comprise.
Prototypage et validation
Prototypes haute fidélité sous Figma, testés en trois vagues successives avec des élèves, des professeurs principaux et des PSY-EN. Chaque vague se concluait par une mesure SUS et un ajustement du parcours avant la vague suivante.
04
UI & design system
L’ONISEP étant un opérateur de l’État, l’interface devait appliquer le DSFR — Système de Design de l’État. Ce n’était pas une contrainte à contourner mais un socle à exploiter : composants éprouvés, accessibilité documentée, cohérence avec les autres services publics que l’usager connaît déjà.
Ce que j’ai construit sur le socle DSFR
- Fondations respectées à la lettre : couleurs, typographie, espacements et composants natifs du DSFR, sans fork ni surcharge cosmétique.
- Patterns produit spécifiques : les objets métier qui n’existent pas dans le DSFR — carte de progression élève, vue classe enseignant, séquence de bilan — conçus comme des compositions de composants DSFR plutôt que comme des composants nouveaux.
- Documentation d’usage : pour chaque pattern, le quand-l’utiliser, les états, les cas limites et les critères d’accessibilité associés, afin que les équipes de développement n’aient pas à réinterpréter la maquette.
Accessibilité intégrée aux fondations
Les critères RGAA ont été traités comme des critères de conception, pas comme une checklist de recette : hiérarchie de titres définie en maquette, ordre de tabulation spécifié, contrastes vérifiés à la source, alternatives textuelles rédigées par le design et non par le développement, états de focus dessinés explicitement.
Des critères RGAA applicables conformes sur les 7 écrans audités
Écrans passés en audit de conformité
Fork du DSFR — tous les patterns produits sont des compositions
Handoff
Specs rédigées dans Jira et Notion, coordination continue avec les équipes de développement, adaptation des livrables aux contraintes techniques sans compromis sur la qualité d’usage. QA de conformité sur les builds de recette avant mise en production.
05
Impact & apprentissages
Score SUS en 3 itérations — de « à peine acceptable » à « excellent »
Critères RGAA applicables conformes
Publics servis par un socle d’interface unique
Ce que je retiens
Une contrainte réglementaire est un accélérateur si on la prend en amont. Le DSFR aurait pu être vécu comme une limite créative. Traité comme un socle, il a supprimé des semaines de discussion sur des composants déjà résolus et concentré l’effort de conception là où il apportait de la valeur : les objets métier propres au produit.
Un utilisateur qui recrée l’outil à côté de l’outil est le meilleur brief que l’on puisse recevoir. Les 71 % de tableurs parallèles ont plus fait avancer la conception que n’importe quelle session d’idéation.
Mesurer permet de défendre. Présenter un score SUS et un taux d’achèvement change la nature de la conversation avec des décideurs non-designers : on ne discute plus de goût, on discute de résultat.
Ce que je ferais autrement. J’installerais la mesure SUS dès la première vague de tests plutôt qu’à partir de la deuxième : la ligne de base aurait été plus solide et l’arbitrage sur l’onboarding aurait pu être tranché une itération plus tôt.