Dernière modification : 9 février 2026
Je fais du web depuis plus de 25 ans et j’ai conçu des sites internet de toutes tailles :
des petits, des gros, des sites graphiques, des blogs, des sites e-commerce.
Majoritairement sous WordPress, mais aussi avec Wix ou en développement sur-mesure.
J’ai rédigé des contenus, créé des centaines d’interfaces, imaginé autant de parcours utilisateurs.
Parfois sur des projets bien cadrés, bien pensés et bien livrés.
Parfois sur des projets plus bancals.
Passer du web au SaaS n’a pourtant pas été une simple continuité dans mon parcours.
Malgré mon expérience, j’ai rapidement compris que beaucoup de mes réflexes ne suffisaient plus.
J’ai aussi enseigné mon métier à des centaines de personnes — parfois à des promotions entières de plus de 100 élèves.
J’ai exercé de nombreux rôles dans le web : développeur front, infographiste, webdesigner, UX designer, copywriter, conceptrice-intégratrice, testeuse, référenceuse, community manager, cheffe de projet, référente en qualité web.
Toujours avec professionnalisme. Toujours avec passion.
Entre 2000 et 2007, j’ai déjà travaillé sur des applications SaaS pour un grand groupe international.
C’était déjà du web, mais avec un objectif très différent : mettre à disposition des utilisateurs des outils en ligne, directement liés à leurs métiers.
À l’époque, j’étais webdesigner puis testeuse. J’intervenais sur des produits complexes, déjà utilisés à grande échelle.
Et pourtant, je vivais une forme de frustration.
Je faisais ce qu’on me demandait, mais l’utilisateur final était rarement au centre des réflexions.
On parlait peu de ses processus réels, de la façon dont il utilisait l’application au quotidien, des raccourcis nécessaires pour aller vite et bien.
L’accessibilité, quant à elle, n’était tout simplement pas un sujet.
Et pourtant.
Il y a quelque temps, je me suis retrouvée à faire de la gestion de projet pour une application SaaS existante, utilisée au quotidien par des professionnels.
Et là, j’ai compris que beaucoup de mes réflexes web — et même mes anciens réflexes SaaS — ne suffisaient plus.
Je ne parle pas ici de technique pure.
Je parle de posture.
De la manière de penser un produit numérique quand il n’est plus un support de discours, mais un outil de travail vivant, avec son histoire, ses utilisateurs, son équipe et ses contraintes.
Bref, je pensais savoir faire du web
Pendant plus de vingt ans, j’ai conçu des sites.
J’ai appris à structurer l’information, à hiérarchiser les contenus, à optimiser les parcours, à améliorer l’ergonomie, la lisibilité, les performances, le référencement, la cohérence globale.
J’ai aussi beaucoup travaillé sur la qualité web :
l’accessibilité, la clarté des interfaces, la compréhension des actions, la prévisibilité des comportements.
J’ai même fini par en faire un véritable socle professionnel, notamment à travers Opquast.
Bref, je pensais avoir des bases solides.
Quand je suis arrivée sur un produit SaaS, je ne me suis pas dit que je changeais de métier.
Je pensais simplement changer de format.
En réalité, je changeais profondément de nature de produit — et donc de posture.
Un site vitrine, c’est un discours. Un SaaS, c’est un outil.
Un site web, même très fonctionnel, reste fondamentalement un support de lecture.
Il raconte quelque chose.
Il laisse une certaine liberté à l’utilisateur.
Une application SaaS, elle, n’est pas là pour être lue.
C’est un outil.
Un outil utilisé au quotidien, souvent sous pression, parfois dans l’urgence.
Sur un site vitrine :
- l’utilisateur peut hésiter,
- il peut ne pas tout comprendre immédiatement,
- il peut quitter et revenir plus tard.
Sur une application SaaS :
- l’utilisateur est pressé,
- il a un objectif précis,
- il manipule des données réelles,
- une incompréhension peut bloquer toute une chaîne de travail.
Une erreur sur un site est visible.
Une erreur dans un SaaS est bloquante.
C’est là que j’ai compris que mes réflexes de conceptrice web devaient évoluer.
Ce que j’ai dû désapprendre
J’ai d’abord dû désapprendre le réflexe “contenu”.
Dans un SaaS, expliquer n’est pas toujours la bonne réponse.
Bien souvent, la meilleure aide est une interface suffisamment claire pour ne pas avoir besoin d’être expliquée.
J’ai aussi dû désapprendre la recherche de la page parfaite.
Un SaaS vit avec son histoire : des choix passés, une dette technique, des contraintes métier fortes.
On ne repart pas de zéro.
On améliore, pas à pas, sans brusquer ni les utilisateurs, ni l’équipe technique.
Enfin, j’ai dû désapprendre l’idée qu’un bon design suffit.
Un produit peut être esthétiquement réussi et pourtant mal vécu par ses utilisateurs.
À l’inverse, une interface imparfaite peut être très efficace si elle respecte les usages réels.
Faire entrer la qualité web dans un SaaS existant
L’un des défis majeurs a été d’intégrer les principes de qualité web — notamment ceux issus d’Opquast — dans une application SaaS déjà en production depuis longtemps.
Accessibilité, lisibilité, cohérence des libellés, prévisibilité des actions…
Ce sont des sujets que je maîtrise, mais qui n’avaient jamais été formalisés au sein de l’équipe.
L’enjeu n’était pas d’imposer un cadre théorique ou une liste de règles.
Il s’agissait de traduire ces principes en décisions concrètes, utiles au produit :
- clarifier les interfaces,
- réduire les ambiguïtés,
- fiabiliser les parcours,
- améliorer l’expérience sans casser l’existant.
C’est un travail progressif, qui demande de la pédagogie, de la patience et beaucoup d’échanges.
Mais c’est aussi un formidable levier pour faire évoluer une culture produit.
Faire évoluer les méthodes de travail, progressivement
En parallèle, j’ai dû adapter ma manière de travailler avec une équipe habituée à son propre fonctionnement.
Les changements ne se font jamais d’un coup. Ils se construisent dans la durée.
Nous avons commencé par une réunion globale le lundi matin : un point d’alignement avec la direction, le technique et le commercial.
Un temps pour partager la vision, les priorités et les contraintes.
Puis j’ai proposé la mise en place de dailies très courts, autour de trois questions simples :
- qu’ai-je fait hier ?
- que vais-je faire aujourd’hui ?
- quels blocages ai-je rencontrés ?
Au départ, cette réunion a suscité des résistances.
Mais elle a progressivement amélioré la communication, en particulier dans un contexte de télétravail à 100 %.
Aujourd’hui, ces quinze minutes sont devenues indispensables.
Elles déclenchent souvent des échanges techniques ciblés et évitent de nombreux malentendus.
Nous mettons également en place des outils de suivi comme les burn-up charts, avec une tâche repère servant d’échelle pour estimer la complexité, le temps et les risques.
Là encore, l’objectif n’est pas la méthode pour la méthode, mais une meilleure lisibilité du travail réel.
Télétravail, autonomie et confiance
L’équipe travaille en full télétravail.
Nous communiquons beaucoup à l’oral, souvent sans caméra — au point que je ne reconnaîtrais probablement pas certains collègues dans la rue.
Ce mode de fonctionnement a ses avantages, mais il demande aussi de l’autonomie, de la rigueur et une vraie capacité de concentration.
Dans notre cas, cela fonctionne justement parce que la communication est structurée et régulière.
Les clients comme source d’inspiration
Une part essentielle de mon travail consiste à échanger avec les utilisateurs.
Je prends le temps de discuter avec eux, de faire des visios, de leur demander de me montrer leurs processus réels.
C’est indispensable, car nos clients ont des métiers, des contraintes et des façons de travailler très différents.
L’application doit être suffisamment souple pour s’adapter à cette diversité.
Ces échanges sont une source d’inspiration constante, et j’ai développé avec beaucoup de clients des relations de confiance que j’apprécie énormément.
Où j’en suis aujourd’hui
Mon quotidien est parfois intense, parfois stressant, souvent très chargé.
Mais j’y travaille de manière sereine.
Parce que chacun fait de son mieux.
Parce que le produit évolue.
Parce que le travail est profondément humain, même lorsqu’il est informatique.
Et parce que j’aime ce que je fais.