LES CORDONS BLEUS
Le vrai défi commence quand la porte du cours se referme.
Entre l’apprentissage guidé en atelier et la pratique autonome en cuisine chez soi, le passage n’a rien d’automatique. Quand l'école Les Cordons Bleus m'a confié ce projet, mon objectif était de façonner une véritable continuité numérique : accompagner l’apprenant une fois le cours terminé, raviver l'enthousiasme de l’atelier — sans jamais transformer son quotidien en deuxième salle de classe.
Avant d'esquisser le moindre écran, j'ai voulu comprendre ce qui se passe une fois la porte du cours refermée : ce que l’apprenant emporte réellement avec lui, ce qu’il risque d’oublier dès le lendemain et surtout ce qui peut l’aider à continuer seul à la maison sans perdre son élan.
J'ai structuré ma recherche autour de ces profils pour me servir de repères de conception vivants : des besoins, des contraintes et des niveaux d’autonomie différents à confronter tout au long de mes choix de design.
À ce stade de mon analyse, le problème s'est imposé à moi : il ne fallait pas simplement ajouter du contenu numérique. Il fallait créer un véritable relais entre le cours présentiel et la pratique à la maison.
Mon parti pris : l'application ne devait pas remplacer le cours, elle devait en être le prolongement naturel.
Pour moi, concevoir une bonne expérience ne suffisait pas. Il fallait aussi vérifier qu’elle puisse réellement exister sur le terrain : avec un budget maîtrisé, une anticipation des aléas et une méthode pour mesurer l'impact réel après le lancement.
UX/UI · gestion de projet · développement · production de contenus · accessibilité
Jusqu’à 20 % d'ajustement selon les retours terrain.
Analyse des KPI à M+1, M+3, M+6 et M+9, pour ajuster mes choix de design à partir des usages réels.
Forfait estimé : 2 500 €
Une fois ce cadre stratégique posé, j'ai construit le diagramme de Gantt pour visualiser les dépendances, les chevauchements et sécuriser les grandes étapes du déploiement sur six mois.
Je ne suis pas partie des écrans. Je suis partie de ce qui devait se passer avant, pendant et surtout après le cours.
J'ai pensé ce service comme un tout indissociable : l’expérience vécue par l’apprenant, l’organisation côté école, les points de contact numériques et la continuité dans le temps.
Avant de structurer les coulisses du service, j'ai cartographié le parcours complet de l’apprenant : ses actions, ses pensées, ses émotions et le point de rupture post-cours.
Le parcours ne se joue pas uniquement dans l’interface. Le service blueprint m’a permis de relier ce que vit l’apprenant à ce qui doit se passer en coulisses pour que cette continuité fonctionne réellement.
Une bonne idée sans ordre de marche reste une intention. La roadmap m'a permis de transformer les besoins en priorités, avec une progression réaliste et des étapes mesurables en 3 phases.
En analysant les parcours, j'ai réalisé que le point de rupture n’était pas dans l'atelier lui-même. Il apparaissait juste après, lorsque l’apprenant basculait d’un environnement très guidé avec le chef à une pratique en autonomie chez soi.
La réponse ne pouvait donc pas être une surcouche de fonctionnalités. Il fallait plutôt construire une passerelle bienveillante, suffisamment présente pour accompagner, mais suffisamment légère pour laisser l’apprenant prendre la main.
À partir de ce constat, j'ai articulé mes solutions autour d’un principe fort : prolonger l’accompagnement sans prolonger artificiellement le cours.
J'ai conçu un compagnon numérique s'appuyant sur des micro-étapes guidées, un suivi personnalisé du geste et une passerelle fluide entre l’atelier présentiel et la cuisine de la maison.
Chaque fonctionnalité retenue dans ma matrice découle directement d'un point de douleur identifié lors de l’analyse terrain.
J'ai appris que la vraie expérience ne s’arrête pas à la porte de l'atelier. Une fois l'élève rentré chez soi, mon rôle était de lui permettre de retrouver, pratiquer et prolonger ce qu'il a vécu avec le chef.
En construisant le service blueprint, j'ai dépassé la simple création d'interfaces. J'ai compris que pour garantir une expérience fluide, je devais orchestrer tout un écosystème : contenus, plannings et suivi.
Pour moi, la mise en ligne n’est pas la ligne d’arrivée. J'ai intégré un suivi des KPI à M+1 puis tous les 3 mois pour vérifier ce qui fonctionne vraiment et ajuster mes choix de conception à partir des usages réels.
Le projet, de la problématique aux solutions retenues, avec les principaux choix de conception et livrables.
✨ Podcast réalisé avec NotebookLM — version 1.
Quelques imperfections de prononciation ou de fluidité peuvent subsister. Merci de votre compréhension.
Une version textuelle accessible reprend les éléments essentiels de la présentation.
Lire la version textuelle (PDF) ↗Apprendre quelques signes pour mieux se comprendre avant les premiers mots.
La crèche Les Bambinets souhaitait un outil simple pour aider les professionnels de la petite enfance — et les parents — à apprendre rapidement quelques signes utiles pour communiquer avec les enfants de moins de 3 ans.
L’objectif : proposer un apprentissage court, visuel et rassurant, adapté à des situations où le temps est limité et l’attention souvent partagée.
Quand la crèche Les Bambinets m’a sollicitée, la promesse était claire : permettre aux parents et aux professionnels de la petite enfance d’apprendre quelques signes clés pour mieux communiquer avec l’enfant avant que le langage verbal soit pleinement installé.
Sur le papier, la demande semblait classique : un glossaire vidéo, des favoris, des microquiz et une FAQ.
Mais sur le terrain, l’application devait fonctionner dans un contexte où l’utilisateur n’est jamais entièrement disponible. À la maison comme en crèche, l’attention se partage en permanence entre l’enfant, le groupe et l’urgence du moment.
Le véritable enjeu n’était donc pas d’accumuler du contenu pédagogique, mais de le rendre immédiatement accessible au moment exact où il peut servir.
Glossaire vidéo, recherche par catégories, favoris et micro-quiz construisent un parcours court :
Bambinets n’était pas un projet complexe parce qu’il fallait concevoir beaucoup de fonctionnalités. Il l’était parce qu’il fallait savoir quoi écarter.
À chaque arbitrage de design, je me posais la même question : comment façonner un outil pédagogique suffisamment riche pour être utile, sans créer de charge mentale superflue pour les utilisateurs ?
J’ai dû calibrer le juste niveau d’information pour des débutants : apporter assez de clés pour apprendre sereinement, sans jamais submerger l’utilisateur.
J’ai fait le choix de restreindre ce prototype à une vingtaine de signes essentiels. L’objectif n’était pas de tout étaler, mais de valider des parcours d’une fluidité irréprochable.
L’identité visuelle préexistait. J’ai donc choisi de respecter ce cadre graphique tout en adaptant certains composants d’interface dès que la lisibilité sur mobile l’exigeait.
Glossaire, recherche, favoris, quiz et FAQ devaient former un tout cohérent. J’ai veillé à ce que l’utilisateur ne ressente jamais la moindre rupture de navigation.
Mon vrai travail n’a donc pas été d’ajouter des écrans. Il a surtout consisté à éliminer la moindre hésitation entre eux.
J’ai d’abord structuré l’application autour de quatre clés d’entrée évidentes : Glossaire, Favoris, Quiz et FAQ.
Depuis le glossaire, l’utilisateur parcourt les signes par catégorie, lance une recherche rapide et accède directement à la fiche du signe. Chaque fiche rassemble la démonstration vidéo, une description claire du geste et la possibilité de l’ajouter aux favoris en un tap.
Pour le quiz, j’ai conçu une logique tout aussi fluide : une question à la fois, un repère de progression rassurant, un feedback immédiat et un bilan bienveillant.
Mon objectif n’était pas de multiplier les chemins possibles. Il fallait au contraire que l’utilisateur sache toujours où il se trouve, ce qu’il peut faire ensuite et comment revenir à l’essentiel.
Le flowchart m’a permis de relier ces parcours, d’anticiper les retours possibles et d’éviter les impasses avant de traduire cette structure avec les composants du design system.
Cette vue est une illustration simplifiée de l’architecture. Le flowchart complet est disponible sur Miro.
À ce stade, pas de couleurs, pas d’illustrations, pas de petites vidéos mignonnes. Juste des blocs gris, des boutons et une question très simple que je me posais à chaque écran : est-ce que le parcours fonctionne vraiment ?
Les wireframes m’ont permis de tester la logique à nu avant l’habillage : comprendre où l’on arrive, comment retrouver un signe en deux secondes, comment lancer le quiz et comment enchaîner sans avoir à réfléchir.
Dès l’accueil, les fonctions principales devaient être suffisamment claires pour qu’un parent ou un professionnel sache quoi faire sans mode d’emploi.
La recherche et les catégories devaient offrir un chemin court vers le bon contenu, surtout quand l’utilisateur n’a ni les deux mains libres ni cinq minutes devant lui.
Dans le quiz, chaque étape devait mener naturellement à la suivante, avec une progression lisible et un retour immédiat après chaque réponse.
C’était mon moment de vérité : si le parcours ne tenait pas avec quelques rectangles gris, aucune couche de peinture ne viendrait le sauver.
Une fois la structure posée, il fallait faire entrer Bambinets dans son univers visuel — sans transformer l’application en sapin de Noël pédagogique.
Le style guide existait déjà. Mon rôle n’était donc pas de réinventer l’identité, mais de faire vivre le parcours à l’intérieur de ce cadre : choisir les bons composants, ajuster la typographie, les pictogrammes et certains éléments d’interface quand cela servait la compréhension.
À ce stade, chaque détail graphique devait avoir une utilité : aider à repérer une action, comprendre où l’on se trouve, reconnaître un contenu ou avancer sans hésiter.
Les boutons, pictogrammes et zones interactives devaient être immédiatement repérables, surtout sur mobile.
Les écrans devaient rester cohérents entre eux pour éviter que l’utilisateur ait l’impression de réapprendre l’application à chaque étape.
Vidéos, couleurs et visuels devaient accompagner l’apprentissage sans prendre le dessus sur l’information.
Le prototype haute fidélité n’était donc pas une couche de finition. C’était le moment où la structure, l’apprentissage et l’interface devaient enfin parler le même langage.
Cette vue rassemble les principaux écrans du projet. Les maquettes complètes et le prototype interactif sont disponibles sur Figma.
Dans Bambinets, la simplicité ne devait pas seulement rendre l’application plus agréable. Elle devait aussi la rendre plus facile à lire, à comprendre et à utiliser pour le plus grand nombre.
Le brief fixait un objectif de niveau AA pour les contrastes et la lisibilité. J’ai donc vérifié et ajusté les couleurs dans Figma, travaillé la hiérarchie typographique, les espacements et la taille des éléments interactifs pour que l’interface reste claire sur mobile.
Les couleurs ont été contrôlées et ajustées afin d’éviter qu’un choix visuel nuise à la lecture ou à la compréhension.
Les boutons et zones interactives devaient être suffisamment visibles et suffisamment grands pour être utilisés sans précision chirurgicale.
Tailles de texte, espacements et densité des écrans ont été pensés pour permettre de comprendre rapidement ce qui est important.
Cette attention portée à l’accessibilité concernait le prototype. Une conformité complète aurait aussi dépendu de l’implémentation : structure sémantique, navigation clavier, alternatives textuelles, attributs ARIA et compatibilité avec les technologies d’assistance.
Autrement dit : le prototype pouvait préparer le terrain. Il ne pouvait pas, à lui seul, garantir l’accessibilité du produit final.
Dans une crèche, personne ne consulte une application dans le calme avec vingt minutes devant soi. L’attention se partage entre l’enfant, le groupe, les gestes du quotidien et ce qu’il faut retrouver tout de suite.
Mon prototype devait donc me permettre de vérifier une chose simple : est-ce qu’on comprend où aller, quoi faire et comment avancer sans réfléchir trop longtemps ?
Ces éléments sont des points d’attention de conception identifiés à partir de mon prototype. Ils ne correspondent pas aux résultats d’une campagne formelle de tests utilisateurs.
Au final, Bambinets m’a surtout appris qu’une interface pédagogique réussie ne doit pas montrer tout ce qu’elle sait faire. Elle doit aider l’utilisateur à apprendre sans lui demander d’apprendre l’interface en même temps.
Mon prototype posait une première expérience fluide et cohérente. Pour moi, la suite logique ne consistait pas à empiler de nouvelles fonctionnalités : il fallait surtout confronter ma maquette à des usages réels sur le terrain avant d'aller plus loin.
Autrement dit : mon prototype fixait un cap clair. La suite devait surtout vérifier que ma vision fonctionnait aussi bien dans le quotidien de la crèche que sur mon écran Figma.
Le projet, de la problématique aux solutions retenues, avec les principaux choix de conception et livrables.
✨ Podcast réalisé avec NotebookLM — version 1.
Quelques imperfections de prononciation ou de fluidité peuvent subsister. Merci de votre compréhension.
Une version textuelle accessible reprend les éléments essentiels de la présentation.
Lire la version textuelle (PDF) ↗Il est 12h30. Au bureau, Foodles permet de réserver un repas disponible dans un frigo connecté.
Côté équipes, les remontées s’accumulent : disponibilité des plats, allergènes difficiles à repérer, navigation peu évidente, manque de repères dans le parcours… Chacun voit une partie du problème.
Mais une remarque interne n’est pas encore une preuve utilisateur.
Mon objectif : transformer ces intuitions en hypothèses testables, les confronter à des usages réels et identifier ce qui mérite vraiment d’être corrigé. Cinq tests utilisateurs, puis une analyse Atomic UX Research, me permettront de relier chaque recommandation à un fait observé.
À l’heure du déjeuner, l’utilisateur ne vient pas explorer une application. Il veut savoir rapidement ce qu’il peut manger, ce qui est encore disponible et si le plat lui convient.
Dans ce contexte, chaque hésitation compte : une information difficile à trouver, un retour en arrière ou un manque de repère suffit à alourdir une expérience pourtant pensée pour être simple.
C’est cette réalité d’usage qui a guidé la recherche : comprendre où l’utilisateur perd du temps, doute ou doit chercher une information qui devrait venir à lui.
À ce stade, j’avais surtout une collection de signaux : des remarques, des doutes, des points de friction supposés.
Mais tant que personne ne regardait un utilisateur chercher un plat, hésiter, revenir en arrière ou passer à côté d’une information, impossible de savoir ce qui comptait vraiment.
Il fallait donc transformer ces intuitions en quelques questions simples, puis laisser le prototype répondre.
Plats, disponibilité, allergènes, informations essentielles.
Navigation, catégories, repères.
Lisibilité de la fiche, hiérarchie des contenus.
Compréhension de l’offre, visibilité des plats, première impression.
Ces questions ont servi de fil conducteur à cinq entretiens semi-directifs menés sur le prototype.
Les hypothèses étaient posées. Il fallait maintenant les confronter à de vraies utilisations.
J’ai mené cinq entretiens semi-directifs sur le prototype, avec des tâches simples à réaliser sans guider les participants.
Ce qui comptait n’était pas seulement ce qu’ils disaient, mais aussi où ils hésitaient, ce qu’ils cherchaient, les détours qu’ils faisaient et les informations qu’ils ne voyaient pas tout de suite.
À la fin des entretiens, j’avais des hésitations, des remarques, des comportements parfois répétés, parfois isolés.
Mais une phrase entendue une fois ne devient pas automatiquement une décision de design.
J’ai donc utilisé Atomic UX Research pour remettre chaque observation dans son contexte, séparer les faits des interprétations et garder une trace claire du chemin qui mène jusqu’à la recommandation.
Autrement dit : partir de ce qui s’est réellement passé pendant le test, comprendre ce que cela révèle, puis seulement décider ce qu’il faut améliorer.
Au départ, l’interface semblait plutôt simple.
Les photos étaient soignées, les plats donnaient envie, et la structure paraissait familière.
Puis les utilisateurs ont commencé à chercher.
Un allergène. Une catégorie. Un plat disponible. Le temps de chauffe. Une confirmation après avoir ajouté quelque chose au panier.
Et c’est là que les petites hésitations se sont accumulées.
Les utilisateurs arrivaient à trouver l’information, mais souvent après plusieurs détours.
Allergènes, régimes alimentaires, pictogrammes : tout était là, sans être assez visible ni assez immédiat.
Le scroll horizontal a surpris plusieurs participants. Certains cherchaient instinctivement à descendre, d’autres ne voyaient pas immédiatement qu’il fallait glisser sur le côté.
La navigation finissait par fonctionner, mais pas toujours de façon évidente.
Les allergènes se perdaient dans la page, le temps de chauffe manquait, certains textes étaient difficiles à lire.
L’information existait, mais elle ne venait pas toujours au bon moment.
Ajouter un plat au panier sans confirmation suffisamment visible obligeait l’utilisateur à se demander : « Est-ce que ça a marché ? »
Ce manque de feedback ajoutait un doute inutile à une action pourtant simple.
Les photos étaient attractives, mais certains participants cherchaient davantage de repères sur la qualité, l’origine ou la composition des plats.
Une belle image ne suffit pas toujours à rassurer quand on choisit ce qu’on va manger.
T’es obligé de scroller sur le côté, ce qui n’est pas forcément ce que t’as envie de faire.
Les allergènes sont noyés dans la page.
Il n’y a pas de temps indiqué, c’est un petit truc qui me ferait hésiter.
Le logo, on dirait “téléchargez mon plat pour imprimante 3D”.
Pris séparément, ces résultats peuvent sembler mineurs.
Mis bout à bout, ils racontent tous la même chose :
l’interface fonctionne, mais elle demande encore trop souvent à l’utilisateur de chercher, interpréter ou vérifier ce qui devrait être évident.
À ce stade, les tests avaient fait leur travail.
On savait où les utilisateurs hésitaient, quelles informations arrivaient trop tard, et à quels moments l’interface leur demandait un effort qui n’aurait pas dû exister.
Il ne s’agissait donc pas de tout reconstruire. Il fallait surtout remettre les bonnes informations au bon endroit, au bon moment.
Au moment de choisir son déjeuner, personne n’a envie d’enquêter. L’utilisateur veut savoir rapidement ce qui est disponible, vérifier qu’un plat lui convient, comprendre ce qu’il doit faire ensuite et être certain que son action a bien été prise en compte.
C’est là que les recommandations ont pris forme.
La disponibilité du plat, les allergènes, la composition ou encore les informations utiles au choix devaient apparaître plus tôt dans le parcours.
L’objectif : éviter que l’utilisateur découvre une information décisive une fois son choix déjà engagé.
Le scroll horizontal, certains pictogrammes ou certaines actions demandaient parfois un temps d’interprétation.
L’interface devait donner davantage de repères et s’appuyer sur des comportements déjà familiers, pour que la navigation devienne presque instinctive.
Ajouter un plat au panier ne devrait jamais laisser place au doute.
Une confirmation claire, un compteur ou un changement d’état visible suffit parfois à transformer une action incertaine en interaction rassurante.
Une belle photo attire l’œil. Mais pour choisir ce qu’on va réellement manger, elle ne suffit pas toujours.
Origine, composition, labels, qualité : quelques informations bien choisies peuvent donner à l’utilisateur les repères qui lui manquent pour décider sereinement.
Les recommandations ne cherchaient pas à ajouter davantage d’interface.
Elles cherchaient au contraire à retirer de l’effort : moins chercher, moins interpréter, moins hésiter — et pouvoir choisir plus simplement.
Concevoir pour un usage quotidien au travail exige d'éliminer les moindres frictions. Une réservation sans effort est le meilleur vecteur d'adoption.
Le projet Foodles, de la problématique aux solutions retenues, avec les choix d'ergonomie et livrables.
✨ Podcast réalisé avec NotebookLM (IA) — Version 1 :
• Forme : Ce podcast est généré automatiquement par IA, de légères imperfections de prononciation ou de fluidité peuvent subsister.
• Fond : Le podcast évoque un « Card Sorting » qui n’a pas été utilisé sur ce sprint (la recherche repose sur 5 entretiens semi-directifs et Atomic UX Research). L’analyse globale reste néanmoins fidèle aux enseignements du terrain.
Une version textuelle accessible reprend les éléments essentiels de la présentation.
J’aide à concevoir des parcours qui demandent moins d’effort — et un peu moins de patience héroïque.
Chaque projet arrive avec ses contraintes, ses usages et ses petites manies.
Je ne plaque pas une méthode toute faite : j’observe, je choisis les bons outils, je teste ce qui mérite de l’être et j’ajuste au fur et à mesure.
L’objectif, c’est de construire un parcours qui fonctionne pour de vraies personnes — pas pour un utilisateur imaginaire qui comprend tout du premier coup.
Je n’arrive jamais avec une solution déjà prête dans la poche. Je regarde d’abord le contexte : qui utilise quoi, dans quelles conditions, avec quelles contraintes, quels objectifs, quelles habitudes déjà installées. Parce qu’un problème d’interface est parfois juste la partie visible. Et partir trop vite sur les écrans, c’est un excellent moyen de résoudre très proprement… le mauvais problème.
Au début d’un projet, il y a souvent beaucoup de signaux : des retours, des intuitions, des chiffres, des comportements observés, parfois des choses qui se contredisent. Mon rôle, c’est de les transformer en questions qu’on peut réellement explorer : qu’est-ce qu’on sait ? qu’est-ce qu’on suppose ? qu’est-ce qu’on doit encore vérifier ? Ça évite de confondre une bonne intuition avec une vérité gravée dans le marbre.
Je ne cherche pas automatiquement la nouvelle fonctionnalité qui va tout sauver. Je regarde d’abord ce qu’on peut rendre plus clair, plus court, plus lisible, plus évident. Parfois, enlever une étape, déplacer une information ou mieux hiérarchiser suffit à transformer l’expérience. C’est moins spectaculaire qu’un grand redesign. Mais en général, l’utilisateur s’en remet très bien.
Je n’ai pas de checklist sacrée. Entretien, benchmark, journey map, prototype, test, blueprint… je prends ce qui aide vraiment à comprendre ou à décider. Et si un outil n’apporte rien au projet, il peut rester tranquillement dans la boîte. La méthode est là pour servir le problème. Pas pour décorer le portfolio.
Quand on a passé plusieurs heures sur une interface, tout finit forcément par sembler logique. C’est exactement pour ça que je préfère regarder quelqu’un d’autre l’utiliser. Je regarde où il hésite, ce qu’il comprend immédiatement, ce qu’il contourne, ce qu’il ne voit pas. Et si une idée à laquelle je tenais ne fonctionne pas, elle n’a pas droit à l’immunité diplomatique.
Pour moi, le travail ne s’arrête pas au moment où les écrans sont livrés. Quand le contexte le permet, je regarde ce qui se passe ensuite : ce qui est utilisé, ce qui est abandonné, ce qui génère des retours, ce qui mérite encore d’être ajusté. Parce qu’un prototype peut être très convaincant dans Figma. La vraie vie, elle, a parfois d’autres projets.
Je suis arrivée à l’UX avec un parcours déjà bien rempli : relation client, management, sciences de l’éducation, histoire de l’art, digital learning, formation front-end, gestion de projet et création.
Ces détours m’ont appris quelque chose d’essentiel : une expérience ne se résume jamais à l’écran qu’on a devant soi. Il y a un contexte, des personnes, des contraintes, des habitudes et des usages réels.
Aujourd’hui, c’est avec ce regard-là que je pratique l’UX : observer, comprendre, simplifier et concevoir des parcours qui fonctionnent dans la vraie vie.
Des détours en apparence. Un même fil rouge : comprendre les usages, transmettre clairement et donner forme aux idées.
Dans le travail
comme dans la vie.
Rendre les choses compréhensibles pour qu’elles puissent vraiment être utiles et partagées.
Explorer les détours, sortir du cadre et imaginer des solutions inattendues quand les réponses classiques ne suffisent pas.
Dire ce que je vois, simplement, même quand la réponse n’est pas celle qu’on espérait.
Écouter, observer et comprendre avant de supposer.
Créer un cadre où l’on peut dire les choses, essayer, se tromper et avancer sans juger.
Ne pas survendre une solution et rester fidèle à ce que montrent réellement les usages.
Les œuvres présentées sont mes créations. Certaines images ont été retravaillées et optimisées avec l’aide de l’IA, sous ma direction artistique.
Avant l’UX, il y avait déjà l’observation. J’ai longtemps dessiné ce que je voyais : des visages, des gestes, des scènes prises sur le vif, des lieux habités.
L’art m’a appris à regarder les détails, les ambiances et tout ce qui donne de la présence, du sens et de l’émotion à une image.
Ce regard m’accompagne encore aujourd’hui en UX : observer avant d’interpréter, comprendre ce qui se joue dans une posture, un usage ou une situation réelle, relier les détails et rendre l’humain visible.
La même curiosité, d’un carnet à l’écran.
Les œuvres présentées sont mes créations. Certaines images ont été retravaillées et optimisées avec l’aide de l’IA, sous ma direction artistique.
Karine a une grande connaissance des Arts et la volonté de partager son savoir.
Elle possède l'énergie nécessaire pour mener à bien et diriger des projets ainsi qu'une très bonne connaissance des sciences éducatives et pédagogiques.
Elle est en plus dotée d'une grande imagination qu'elle sait utiliser à bon escient dans son travail.
Des échanges
qui donnent
du sens.
Outils & pratiques
Je ne choisis pas un outil parce qu’il est à la mode. Je le garde s’il m’aide à mieux comprendre, mieux structurer, mieux collaborer ou aller plus vite sans perdre le sens.
Comprendre · Structurer · Concevoir
Croquis, notes et schémas pour poser les idées, puis des outils pour structurer et partager.
Prototyper · Intégrer · Comprendre
Une culture front-end pour penser des interfaces réalisables et dialoguer avec les développeurs.
Notion : JavaScript
Explorer · Comparer · Affiner
Explorer des pistes, reformuler et comparer, en gardant les choix et le regard critique.
Pratique ponctuelle : Google Flow / Omni
Organiser · Partager · Avancer
Partager l’information, suivre l’avancement et garder un fil commun tout au long du projet.
Un parcours ne se complique jamais d’un seul coup. Une hésitation ici, une information qu’on cherche trop longtemps, une étape de trop — et l’effort s’accumule. J’aide à comprendre ce qui se joue vraiment, à remettre les priorités dans le bon ordre et à concevoir une expérience plus simple à suivre.
Audit, sprint ou accompagnement : on part du problème réel avant de décider ce qu’il faut changer.
Les produits de formation ne sont pas des interfaces comme les autres. Il faut penser l’usage, bien sûr, mais aussi la progression, le contenu, les objectifs pédagogiques, la charge cognitive, les contraintes de production et la manière dont les personnes vont réellement s’approprier le dispositif.
Clarifier les étapes, réduire les frictions et intégrer les recommandations WCAG dès la conception, pour construire des parcours accessibles à tous, compréhensibles et faciles à suivre.
Articuler objectifs pédagogiques, contenus, formats et contraintes de production pour construire un parcours cohérent.
Travailler le rythme, les feedbacks, la progression visible, les micro-interactions et les mécanismes de motivation lorsqu’ils ont un vrai rôle à jouer.
Cadrer, coordonner, arbitrer et accompagner l’adoption lorsque le projet dépasse la seule conception d’écrans.
La ludification n’est pas là pour coller des badges partout. Elle sert à soutenir la progression, donner du feedback et renforcer l’envie de poursuivre lorsque le contexte s’y prête.
Mon expérience en ingénierie e-learning, création de parcours, relation client et chefferie de projet permet d’aborder ces sujets avec une lecture plus large que la seule interface.
Vous avez des retours mais pas encore les priorités ? Une idée à tester avant d’aller plus loin ? Ou besoin d’un regard UX dans la durée ?
Trois façons de travailler ensemble, selon l’étape où en est votre projet.
Un audit n’est pas une chasse aux défauts. Il sert à comprendre ce qui freine réellement l’usage, ce qui relève d’un détail et ce qui mérite une vraie décision de conception.
Je croise l’analyse du parcours avec le contexte du projet, les retours déjà disponibles et, lorsque c’est pertinent, un benchmark ou une recherche ciblée auprès des utilisateurs.
Pour analyser un parcours ou un problème bien délimité et identifier rapidement les priorités.
Pour explorer plusieurs frictions, approfondir les hypothèses et intégrer si nécessaire de la recherche ou des tests utilisateurs.
Le prix final dépend du périmètre et des méthodes réellement nécessaires.
Une idée paraît bonne sur le papier. Encore faut-il vérifier qu’elle tient debout une fois mise entre les mains des utilisateurs. Le sprint permet de cadrer, prototyper, tester et ajuster rapidement avant d’engager plus de temps et de budget.
Je pars d’une question précise et des éléments déjà disponibles pour construire un parcours, rendre une piste tangible et la confronter à l’usage. Les retours servent à ajuster la proposition et à décider de la suite.
Les temps sont indicatifs et s’adaptent au format retenu. Le calendrier dépend aussi de la disponibilité des participants aux tests.
Pour travailler une hypothèse sur un parcours bien délimité, construire un prototype ciblé et l’ajuster à partir des premiers tests.
Pour approfondir la recherche et le parcours, développer le prototype et consacrer davantage de temps aux tests et aux itérations.
Le prix final dépend du périmètre, du niveau de détail du prototype et des modalités de recherche et de tests définies ensemble.
Le projet avance, les décisions s’enchaînent, et l’UX finit parfois par arriver après la bataille. J’interviens au fil du projet pour garder les usages, les parcours et les arbitrages dans la boucle — sans rajouter une couche de réunion pour le plaisir.
Nous définissons les priorités et un rythme de travail adapté à votre équipe. Selon les besoins, je peux analyser un parcours, préparer une recherche, concevoir des écrans, prototyper, tester ou accompagner les échanges avec les personnes qui réalisent le produit.
Le temps se répartit selon les priorités du mois. Les points de suivi font partie des jours prévus et s’adaptent au rythme de l’équipe.
Une bonne expérience ne demande pas plus d’effort. Elle s’intègre naturellement dans la vie des gens, avec leurs contraintes, leurs doutes et leurs objectifs.
Quand tout le monde sent qu’il y a un problème mais que personne ne sait encore vraiment lequel, je vais chercher ce qui se passe côté usages : entretiens, observation, tests, benchmark et analyse.
Une fois les priorités clarifiées, je transforme les constats en parcours, flows, wireframes et prototypes qu’on peut montrer, tester et faire évoluer.
Quand l’expérience doit aussi permettre d’apprendre, je travaille la progression, les contenus, les formats et les repères qui aident réellement l’apprenant à avancer.
Parce qu’une bonne idée ne tient pas toute seule : je peux aussi cadrer le projet, coordonner les interlocuteurs, suivre les étapes et garder les décisions alignées avec l’objectif de départ.
Et quand le nouvel outil ou le nouveau parcours arrive dans la vraie vie, j’accompagne son adoption : communication, formation, retours terrain et ajustements après lancement.
Parfois, le problème n’est pas dans l’écran. Il est dans ce qu’il y a autour : une organisation compliquée, des contraintes qui se télescopent, des équipes qui n’avancent pas au même rythme, un parcours qui fonctionne sur le papier mais beaucoup moins dans la vraie vie.
C’est là que j’aime prendre un peu de recul : comprendre ce qui se joue, relier les morceaux et remettre de la cohérence là où le projet commence à s’éparpiller.
Toutes les missions n’ont pas besoin du même format. Certaines se prêtent à un forfait, d’autres à quelques jours ciblés ou à un accompagnement plus régulier.
Avant de démarrer, on clarifie ensemble le périmètre, les priorités et ce qui doit réellement être livré.
Le tarif est ajusté selon la nature, le périmètre et la durée de la mission.
Les durées affichées dans les offres sont des estimations. Elles peuvent évoluer selon le périmètre, le niveau de recherche nécessaire et les livrables attendus.
Chaque mission commence par un cadrage pour définir les besoins, les livrables et les priorités.
Les frais de déplacement, transport et hébergement sont facturés séparément après accord.
C’est justement ce qu’on peut commencer par clarifier.
Ou forfaits d'accompagnement sur-mesure au projet ci-dessous.
Une idée prend forme, un projet évolue, une envie se précise… dites-moi où vous en êtes. Quelques lignes suffisent pour commencer à tracer la suite.
On échange, mais le café, lui, reste à moi.
La page que vous cherchez a filé à l’anglaise.
Revenons calmement à l’accueil.