La première session de test en personne, j’ai compris que j’avais un problème. Pas un bug. Pas une panne. Quelqu’un devant moi, un vrai utilisateur, qui regardait l’écran comme si je lui avais remis les instructions d’assemblage d’une fusée. Moi, assis là, qui me retenais pour pas dire “non non, c’est là, le bouton est juste là.”
J’ai fait dix sessions comme ça sur trois mois. Une trentaine d’utilisateurs en beta fermée au total. Des gens ordinaires, pas des experts en technologie. Des profils ben différents, des besoins ben différents. Ce que j’ai appris en les regardant: mon produit était construit pour moi. Pas pour eux.
L’interface que je pensais claire était pas claire du tout
Le flux de création d’identité, j’en étais fier. Logique, propre, trois étapes. Dans ma tête.
Dans la réalité, huit personnes sur dix ont hésité au même endroit: le moment de choisir leur numéro de téléphone. Pas parce que le choix était compliqué, mais parce que l’interface donnait pas assez de contexte. Pourquoi est-ce que ce numéro-là existe? À quoi ça sert vraiment d’en avoir un séparé par identité? La réponse, pour moi, était évidente. Pour eux, pantoute.
Quand tu passes un an à construire quelque chose, tu finis par oublier ce que c’est de le découvrir pour la première fois. Pour moi, le rôle du numéro de téléphone était évident. Mais j’avais oublié de l’expliquer dans l’interface. La page comment ça marche existait sur le site, mais dans l’application web elle-même, ce contexte-là était presque absent. Les gens arrivaient dans le produit sans repères.
J’ai revu les descriptions, les libellés de boutons, les messages d’aide à chaque étape. J’ai ajouté un guide interactif qui te dirige à travers l’application pas à pas quand tu arrives pour la première fois. J’ai réduit le nombre de décisions à prendre avant que l’utilisateur voie son premier vrai résultat. Chaque changement, je l’ai retesté. Pas parfait encore, mais la différence est notable.
Le gestionnaire de mots de passe chiffré avait le même problème. La navigation entre les identités et les mots de passe était confuse pour les nouveaux utilisateurs. Les gens cherchaient leurs mots de passe dans la mauvaise section, puis abandonnaient sans rien dire. Plusieurs itérations de l’interface plus tard, ça coule mieux. C’est jamais vraiment fini, ce genre de travail. T’améliores, tu retestes, tu recommences.
Le moment où j’ai changé d’avis sur l’application mobile
Je vais être honnête: j’étais convaincu qu’une application web installable sur le téléphone suffisait. Ça fonctionne hors ligne, ça envoie des notifications en temps réel. Pas besoin d’une application native, que je me disais. C’est plus rapide à construire, moins cher à maintenir, et pas de dépendance à l’App Store ou au Play Store d’Apple et Google.
J’avais tort. Pas sur la technologie, mais sur l’usage réel.
Dix personnes en session en personne. Neuf sur un iPhone. Sur les neuf, sept ont automatiquement cherché l’application dans leur bibliothèque d’applications. Deux savaient que l’application web pouvait s’installer sur leur téléphone. Je savais que ce genre d’installation est pas bien supporté sur tous les appareils, mais je trouvais que c’était un bon compromis en attendant l’application mobile. Et quand j’expliquais comment l’installer manuellement depuis Safari, j’en perdais trois en chemin, le regard vide.
La même chose s’est répétée session après session. Répétée. Répétée encore.
À un moment, t’as deux choix: défendre ta décision ou l’ajuster. J’ai choisi d’ajuster. L’application web reste notre produit principal, mais l’application mobile iOS et Android est maintenant officiellement sur notre feuille de route pour compléter l’expérience. Je savais depuis le début que ça allait arriver. C’est le “quand” que j’avais pas encore décidé. Les données m’ont montré que je devais accélérer, et c’est ce que j’ai fait.
Je suis encore convaincu que les applications web installables ont leur place. Mais pour WIGGWIGG, avec des utilisateurs qui s’attendent à trouver une icône dans leur App Store parce que c’est comme ça qu’ils comprennent “une application”, l’argument technologique tient pas face à l’argument humain. Et c’est correct. Le but est que les gens puissent utiliser le produit, pas que j’aie raison sur les choix d’architecture.
Deux fonctionnalités que j’avais pas prévues
L’importateur de gestionnaire de mots de passe d’abord. Plusieurs participants avaient déjà leurs mots de passe dans LastPass, Bitwarden ou 1Password. Ils voulaient pas recommencer à zéro, et c’est tout à fait compréhensible. Donc j’ai construit un importateur: tu exportes ton fichier CSV depuis ton ancien gestionnaire, tu l’importes dans WIGGWIGG, tes mots de passe arrivent directement dans ton coffre-fort. Rien transite en clair par nos serveurs. Tes données sont chiffrées sur ton appareil avant d’aller où que ce soit. Je les vois pas parce que je peux littéralement pas les voir.
Ensuite, la surveillance de la santé des mots de passe. Mots de passe réutilisés entre plusieurs comptes. Mots de passe trop courts ou trop prévisibles. Comptes potentiellement compromis selon les bases de données publiques de fuites connues.
Toutes ces vérifications roulent sur ton appareil. Tes vrais mots de passe en sortent jamais. Ça existait pas dans le plan original de lancement. Ça venait des utilisateurs beta, formulé de différentes façons selon les personnes, mais qui revenait toujours au même besoin fondamental.
Le calendrier: pourquoi ça prend plus de temps
J’ai toujours dit printemps 2026 pour l’accès anticipé. C’est encore le plan. Le travail réglementaire avec le CRTC et les avocats ont pris plus de temps que prévu, donc c’est plus tard dans le printemps que je l’aurais voulu.
Ce temps-là, je l’ai pas perdu. J’ai fait de la beta. J’ai testé. J’ai fixé des problèmes que j’aurais mis des mois à identifier post-lancement, quand les avis négatifs auraient déjà été publiés et la première impression déjà gravée dans le marbre des algorithmes de Google.
Partir avec un produit que je pense bon, c’est une chose. Partir avec un produit que des vraies personnes ont trouvé confus, et que j’ai ajusté en conséquence, c’en est une autre.
Quelques mois d’humilité productive.
Ce que l’accès anticipé ressemble maintenant
Les 500 places d’accès anticipé sont pas un chiffre de marketing. C’est le nombre que je suis à l’aise de gérer correctement, avec du vrai support humain, pendant la phase initiale. Je préfère accueillir 500 personnes bien que 5 000 personnes mal.
Ce que tu vas trouver maintenant, c’est un produit qui a été questionné par des vraies personnes, pas juste validé par le fondateur dans sa tête. L’interface est plus claire qu’elle l’était en janvier. L’importateur de mots de passe est là. La surveillance de santé des mots de passe est là. L’application mobile s’en vient. Et en plus, je devrais être capable d’annoncer une date officielle d’accès anticipé dans les prochaines semaines.
Moi, je suis data engineer de formation. Pas designer d’interfaces de carrière. Quelque part, je savais que j’allais avoir des angles morts. La beta m’a montré exactement où ils étaient.
C’est ça qui rend le produit meilleur. Pas moi qui devine ce que les gens veulent, mais les gens qui me montrent ce qu’ils vivent vraiment.
CAB est le fondateur de WIGGWIGG, une plateforme d’identité numérique axée sur la vie privée, bâtie au Québec.