Comment une simple frustration utilisateur m’a conduit à développer un système d’authentification unique entre mon application et mon blog — et ce que j’ai appris en chemin.
Prologue : une question qui change tout
Il y a des questions qui semblent anodines mais qui, une fois posées, deviennent impossibles à ignorer.
« Pourquoi je dois me reconnecter alors que je suis déjà connecté ? »
Cette question m’a hanté pendant des jours. Elle tournait en boucle dans ma tête, me réveillait la nuit, s’invitait dans mes moments de réflexion. Pas parce qu’elle était complexe — au contraire, elle était d’une simplicité désarmante. Mais parce qu’elle pointait du doigt une incohérence que j’avais acceptée sans la questionner.
Et accepter l’inacceptable, c’est le premier pas vers la médiocrité.
Chapitre 1 : Le contexte — VulTask et son blog
VulTask : une application née d’un besoin personnel
Pour comprendre cette histoire, il faut d’abord comprendre ce qu’est VulTask.
VulTask est une application de gestion de projet en mode Kanban que je développe seul depuis plusieurs mois. Elle est née d’une frustration personnelle : les outils existants étaient soit trop complexes, soit trop limités, soit trop chers pour un usage personnel ou pour une petite équipe.
J’ai voulu créer quelque chose de différent. Un outil qui soit :
- Simple à prendre en main
- Puissant dans ses fonctionnalités
- Gratuit pour un usage personnel
- Respectueux de la vie privée des utilisateurs
VulTask propose une structure en trois niveaux : des Bureaux (espaces de travail), des Projets, et des Cartes (tâches). On peut y ajouter des étiquettes, des dates d’échéance, des pièces jointes, des commentaires, des sous-tâches. Un système de gamification avec Tasko, le renard mascotte, encourage les utilisateurs à rester productifs.
L’arrivée du blog : partager plus qu’un outil
Après plusieurs mois de développement, j’ai ressenti le besoin de partager davantage que du code. Je voulais partager des idées, des conseils, des réflexions sur la productivité, l’agilité, la gestion de projet.
D’où l’idée d’ajouter un blog.
Le choix de WordPress s’est imposé naturellement. C’est le CMS le plus utilisé au monde, il est robuste, bien documenté, et dispose d’un écosystème de plugins immense. Plutôt que de réinventer la roue en développant un système de blog from scratch, autant utiliser un outil éprouvé.
J’ai donc installé WordPress dans un sous-répertoire /blog/ de VulTask. Configuration rapide, thème personnalisé aux couleurs de VulTask, premiers articles rédigés. Tout semblait parfait.
Jusqu’au moment où j’ai voulu laisser un commentaire.
Chapitre 2 : Le drame — Deux mondes qui s’ignorent
La friction invisible devenue visible
Le scénario était le suivant :
- Je me connecte à VulTask avec mon compte
- Je navigue vers le blog pour relire un article
- Je scrolle jusqu’à la section commentaires
- Je vois… un formulaire me demandant mon nom et mon email
Attendez. Quoi ?
Je suis connecté. Je viens de passer 30 minutes sur VulTask à organiser mes tâches. Mon avatar est affiché en haut à droite de l’écran. L’application sait parfaitement qui je suis.
Et pourtant, WordPress me traite comme un parfait inconnu.
Nom : _____________ Email : _____________ Site web : _____________
Cette friction, je l’avais vécue des dizaines de fois sur d’autres sites. Je l’avais acceptée comme « normale ». Mais la vivre sur mon propre produit, sur mon propre domaine, avec mon propre compte… c’était différent.
C’était inacceptable.
Le réflexe du développeur solo : minimiser
Ma première réaction a été celle de tout développeur débordé : minimiser le problème.
« Ce n’est pas si grave. Les utilisateurs comprendront. Ils rempliront le formulaire une fois, le navigateur retiendra leurs infos, et voilà. »
« J’ai des fonctionnalités plus importantes à développer. Le système d’automatisation n’est pas fini. La gamification a des bugs. Le mode sombre a besoin d’ajustements. »
« Personne ne va vraiment commenter de toute façon. »
Ces excuses, je les connais par cœur. Je les ai utilisées des centaines de fois. Et elles sont toutes fausses.
Chapitre 3 : Pourquoi la friction est l’ennemi numéro un
Le coût caché de chaque étape supplémentaire
Il existe une règle non écrite en UX : chaque étape supplémentaire divise par deux le nombre d’utilisateurs qui vont au bout du processus.
C’est ce qu’on appelle parfois la « loi de l’entonnoir ». Si 100 personnes arrivent sur votre formulaire de commentaire :
- 50 vont commencer à écrire
- 25 vont terminer leur commentaire
- 12 vont remplir leur nom et email
- 6 vont effectivement cliquer sur « Publier »
Chaque champ à remplir, chaque clic supplémentaire, chaque micro-hésitation… c’est une opportunité pour l’utilisateur d’abandonner.
Et un commentaire perdu, c’est quoi exactement ?
C’est une idée qui ne sera jamais partagée. Une question qui ne sera jamais posée. Un feedback qui ne sera jamais reçu. Une connexion humaine qui ne sera jamais établie.
Multiplié par des dizaines, des centaines, des milliers d’utilisateurs potentiels… le coût devient astronomique.
Le message implicite de la déconnexion
Au-delà de la friction pratique, il y a le message implicite.
Quand deux applications sur le même domaine ne se reconnaissent pas, que dit-on à l’utilisateur ?
- « Nos systèmes ne communiquent pas entre eux. » → Manque de cohérence technique
- « Ton expérience n’est pas notre priorité. » → Manque d’attention
- « On n’a pas pris le temps de bien faire les choses. » → Manque de professionnalisme
- « Débrouille-toi. » → Manque de respect
C’est dur à entendre. Mais c’est la réalité.
Les utilisateurs ne verbalisent pas ces pensées consciemment. Mais ils les ressentent. Et ces micro-frustrations s’accumulent jusqu’à former une impression générale : « Ce produit n’est pas vraiment fini. »
Mon identité professionnelle en jeu
Et puis il y a eu cette réalisation qui a tout changé.
Je suis intégrateur logiciel. Mon métier, c’est de faire dialoguer les systèmes entre eux. De créer des interfaces fluides. Des passerelles invisibles. De prendre deux applications qui s’ignorent et de les faire collaborer comme si elles n’en formaient qu’une.
C’est littéralement ce pour quoi on me paie au quotidien.
Alors laisser deux applications sur le même domaine — mon domaine — s’ignorer mutuellement ? C’était plus qu’une question d’UX. C’était une question d’intégrité professionnelle.
Si je ne suis pas capable d’intégrer mes propres outils, comment puis-je prétendre aider les autres à intégrer les leurs ?
La décision était prise. J’allais résoudre ce problème, peu importe le temps que ça prendrait.
Chapitre 4 : Plongée dans les entrailles du SSO
Qu’est-ce que le SSO exactement ?
SSO signifie Single Sign-On, ou « authentification unique » en français.
Le concept est simple : tu te connectes une fois, tu es connecté partout.
Vous l’utilisez tous les jours sans le savoir. Quand vous vous connectez à Gmail et que vous êtes automatiquement connecté à YouTube, Google Drive et Google Calendar, c’est du SSO. Quand vous utilisez « Se connecter avec Facebook » sur un site tiers, c’est du SSO. Quand vous accédez à toutes les applications de votre entreprise avec un seul mot de passe, c’est du SSO.
Les grandes plateformes ont des équipes entières dédiées à ces systèmes. Des protocoles standardisés existent : OAuth 2.0, OpenID Connect, SAML. Des services tiers proposent des solutions clé en main : Auth0, Okta, Firebase Authentication.
Mais quand tu es développeur solo, avec une application PHP custom d’un côté et WordPress de l’autre, les choses sont moins simples.
Première approche : partager les sessions PHP
Ma première idée était la plus intuitive : puisque VulTask et WordPress tournent tous deux sur PHP, sur le même serveur, pourquoi ne pas simplement partager les sessions PHP ?
Une session PHP, c’est un mécanisme qui permet de stocker des informations côté serveur et de les associer à un visiteur via un cookie (généralement nommé PHPSESSID). Quand vous vous connectez à VulTask, votre user_id est stocké dans la session. À chaque requête suivante, PHP récupère cette session et sait qui vous êtes.
L’idée était donc :
- VulTask crée une session avec les infos utilisateur
- WordPress lit cette même session
- WordPress sait qui vous êtes
- Magie !
J’ai codé un prototype en quelques heures. Confiant, j’ai testé.
Ça n’a pas marché.
Le problème ? Chaque application PHP démarre sa propre session. WordPress a son propre mécanisme de gestion des sessions, ses propres cookies, sa propre logique. Il n’utilise même pas les sessions PHP standard de la même manière que VulTask.
Même en forçant les deux applications à utiliser le même identifiant de session, WordPress ne savait pas interpréter les données que VulTask y stockait. Et vice versa.
Retour à la case départ.
Deuxième approche : les cookies partagés
Si les sessions ne peuvent pas être partagées directement, pourquoi ne pas créer un système indépendant basé sur les cookies ?
L’idée :
- Quand un utilisateur se connecte à VulTask, générer un token unique
- Stocker ce token en base de données avec l’ID de l’utilisateur
- Créer un cookie contenant ce token, accessible par tout le domaine
- Côté WordPress, vérifier ce cookie à chaque chargement de page
- Si le token est valide, connecter automatiquement l’utilisateur à WordPress
Cette approche semblait solide. J’ai implémenté le système côté VulTask, créé un plugin WordPress pour la vérification, et testé.
Le cookie était créé. Le plugin le détectait. Le token était validé en base. L’utilisateur était connecté.
Ça marchait ! Enfin… dans certains cas.
Le bug mystérieux : www vs non-www
Parce que dans d’autres cas, ça ne marchait pas du tout. Et impossible de comprendre pourquoi.
J’ai passé des heures à debugger. Des logs partout. Des var_dump() dans tous les sens. Le cookie était là côté VulTask, absent côté WordPress. Puis présent des deux côtés. Puis absent à nouveau.
C’était à devenir fou.
Jusqu’à ce que je remarque un détail dans l’URL.
Quand j’accédais à VulTask via www.vultask.fr, tout fonctionnait. Quand j’accédais au blog via vultask.fr/blog (sans le www), le cookie disparaissait.
Le coupable : la politique de même origine des navigateurs.
Pour un navigateur, www.vultask.fr et vultask.fr sont deux domaines différents. Un cookie créé sur l’un n’est pas accessible par l’autre, sauf configuration explicite.
La solution ? Forcer une redirection systématique vers www.vultask.fr, quelle que soit l’URL d’entrée. Une simple règle dans le fichier .htaccess :
RewriteEngine On
RewriteCond %{HTTP_HOST} ^vultask\.fr$ [NC]
RewriteRule ^(.*)$ https://www.vultask.fr/$1 [R=301,L]
Sauf que cette règle a créé d’autres problèmes. Des boucles de redirection. Des conflits avec les règles WordPress. Le .htaccess du blog qui interférait avec celui de la racine.
Encore quelques heures de debugging plus tard, tout était enfin en ordre.
Le cauchemar des collations MySQL
Mais le parcours n’était pas terminé.
Le système de token fonctionnait. Le cookie était partagé. WordPress détectait la connexion VulTask. Il ne restait plus qu’à récupérer les informations de l’utilisateur pour le connecter à WordPress.
Simple requête SQL : trouver l’utilisateur WordPress dont l’email correspond à l’utilisateur VulTask.
SELECT * FROM wp_users WHERE user_email = 'user@example.com'
Sauf que cette requête échouait avec une erreur cryptique :
#1267 - Illegal mix of collations (utf8mb4_unicode_ci,IMPLICIT)
and (utf8mb4_unicode_520_ci,IMPLICIT) for operation '='
Bienvenue dans le monde merveilleux des collations MySQL.
Pour les non-initiés : une collation définit comment MySQL compare et trie les chaînes de caractères. Est-ce que « é » est égal à « e » ? Est-ce que « Café » vient avant ou après « cafe » dans l’ordre alphabétique ?
VulTask utilise la collation utf8mb4_unicode_ci (une collation Unicode standard). WordPress utilise utf8mb4_unicode_520_ci (une version plus récente basée sur Unicode 5.2).
Quand vous essayez de comparer des chaînes provenant de tables avec des collations différentes, MySQL refuse. Par sécurité. Parce que le résultat pourrait être imprévisible.
La solution ? Forcer explicitement la collation dans chaque requête :
SELECT * FROM wp_users
WHERE user_email COLLATE utf8mb4_unicode_ci = ?
Ce n’est pas élégant, mais ça fonctionne.
La synchronisation complète
Une fois ces obstacles surmontés, le SSO de base fonctionnait. Mais j’ai voulu aller plus loin.
Puisque les deux systèmes communiquent maintenant, pourquoi ne pas synchroniser davantage ?
La photo de profil : Sur VulTask, les utilisateurs peuvent uploader une photo de profil. Sur WordPress, par défaut, c’est Gravatar qui gère les avatars. J’ai donc créé un système qui injecte l’avatar VulTask dans WordPress, remplaçant Gravatar pour les utilisateurs connectés.
La bio : VulTask permet d’ajouter une description à son profil. Cette information est maintenant synchronisée avec le champ « Biographie » de WordPress, qui apparaît sous les articles et les commentaires.
Les rôles : VulTask distingue les utilisateurs normaux des administrateurs. Cette distinction est maintenant reflétée dans WordPress : un admin VulTask devient automatiquement administrateur WordPress.
Chapitre 5 : Le résultat — L’expérience invisible
Le parcours utilisateur aujourd’hui
Aujourd’hui, voici ce que vit un utilisateur de VulTask :
- Tu te connectes à VulTask avec ton email et ton mot de passe
- Tu navigues vers le blog en cliquant sur le lien dans le menu
- Tu es automatiquement connecté — pas de formulaire, pas de question
- Ton avatar apparaît dans les commentaires
- Ta bio s’affiche sous tes commentaires
- Tu te déconnectes de VulTask ? Tu es déconnecté du blog aussi
Et dans l’autre sens :
- Tu arrives sur le blog et tu te connectes via WordPress
- Tu navigues vers VulTask pour gérer tes projets
- Tu es automatiquement connecté — zéro friction
Une expérience fluide. Invisible. Comme ça aurait toujours dû être.
La magie de l’invisible
Vous savez ce qu’il y a de beau dans ce résultat ?
Personne ne le remarquera.
Aucun utilisateur ne se dira : « Wow, c’est génial, je n’ai pas eu à me reconnecter ! » Parce que c’est le comportement attendu. C’est ce qui aurait dû se passer depuis le début.
La magie, c’est quand la technologie disparaît.
Les meilleures interfaces sont celles qu’on ne remarque pas. Personne ne devrait avoir à penser aux tokens, aux cookies, aux sessions, aux collations MySQL. L’utilisateur veut juste que ça marche. Point.
Et maintenant, ça marche.
Chapitre 6 : Les leçons apprises
1. Les détails « mineurs » ne le sont jamais
Cette intégration SSO n’était pas dans ma roadmap. Ce n’était pas une fonctionnalité demandée par les utilisateurs. Ce n’était même pas visible — au sens où personne ne la verra fonctionner.
Et pourtant, elle fait une différence énorme.
Ce qui nous semble acceptable en tant que créateur est souvent frustrant pour celui qui utilise notre produit au quotidien. Nous sommes habitués aux limitations de notre propre système. Nous connaissons les contournements. Nous savons pourquoi les choses sont comme elles sont.
L’utilisateur, lui, ne sait rien de tout ça. Il veut juste que ça marche.
2. La dette d’expérience s’accumule silencieusement
On parle beaucoup de dette technique : ce code qu’on devrait refactorer, ces tests qu’on devrait écrire, cette architecture qu’on devrait repenser.
Mais il existe aussi une dette d’expérience : ces frictions qu’on tolère, ces incohérences qu’on ignore, ces petits irritants qu’on remet à plus tard.
Cette dette ne génère pas d’erreurs dans les logs. Elle ne fait pas planter l’application. Mais elle s’accumule. Et un jour, elle se paie. Sous forme d’utilisateurs qui partent sans explication. De commentaires qu’on ne reçoit jamais. D’engagement qui s’érode.
3. L’intégration est un métier à part entière
Faire dialoguer des systèmes qui n’ont pas été conçus pour communiquer, c’est un vrai défi. Ce n’est pas juste « connecter deux APIs ». C’est comprendre les paradigmes de chaque système, leurs contraintes, leurs particularités. C’est trouver le terrain d’entente.
C’est mon métier d’intégrateur logiciel, et j’en apprends encore tous les jours.
4. Le temps investi dans l’expérience n’est jamais perdu
Ces heures passées à debugger des cookies et des collations auraient pu être consacrées à développer de nouvelles fonctionnalités. Un nouveau type de vue. Un nouvel outil de reporting. Une nouvelle intégration avec un service tiers.
Mais une expérience fluide fidélise. Une friction, même mineure, fait fuir.
Sur le long terme, investir dans l’expérience utilisateur rapporte toujours plus qu’empiler les fonctionnalités.
5. Documenter le parcours a autant de valeur que le résultat
En écrivant cet article, je réalise que le chemin parcouru est aussi instructif que la destination. Les erreurs commises, les impasses explorées, les solutions trouvées… tout cela constitue un savoir précieux.
Si cet article peut éviter à un autre développeur de perdre des heures sur les mêmes problèmes, alors le temps passé à le rédiger aura été bien investi.
Chapitre 7 : Et maintenant ?
Les fondations sont posées
Cette intégration SSO n’est qu’un début. Elle pose les fondations d’un écosystème unifié où l’utilisateur navigue sans friction entre différents services.
VulTask n’est plus une application isolée. C’est le cœur d’une plateforme qui peut s’étendre, intégrer d’autres outils, créer de nouvelles synergies.
Les prochaines étapes envisagées
Maintenant que VulTask et WordPress se parlent, de nouvelles possibilités s’ouvrent :
Commentaires → Journal d’activité : Les commentaires postés sur le blog pourraient apparaître dans le journal d’activité VulTask de l’utilisateur. Une façon de garder trace de ses contributions, de valoriser son engagement.
Articles → Tâches : Quand je commence à rédiger un article, je pourrais automatiquement créer une tâche dans VulTask pour suivre sa progression. « Rédiger l’article sur le SSO », avec des sous-tâches : « Plan », « Premier jet », « Relecture », « Publication ».
Gamification étendue : Le système de points et d’achievements de VulTask pourrait récompenser l’engagement sur le blog. Commenter un article ? 10 points. Avoir son commentaire liké ? 5 points supplémentaires. Être le premier à commenter ? Un achievement débloqué.
Notifications cross-platform : Recevoir une notification dans VulTask quand quelqu’un répond à votre commentaire sur le blog. Ou l’inverse : être notifié par email quand une tâche VulTask est modifiée.
Les possibilités sont infinies quand les systèmes communiquent.
Épilogue : La question qui reste
J’ai commencé cet article avec une question : « Pourquoi je dois me reconnecter alors que je suis déjà connecté ? »
Cette question a trouvé sa réponse. Techniquement, du moins.
Mais une autre question demeure, plus large, plus fondamentale :
Quelles sont les frictions que nous acceptons sans les questionner ?
Dans nos produits. Dans nos processus. Dans nos vies.
Ces petits irritants qui « ne sont pas si graves ». Ces incohérences qui « fonctionnent quand même ». Ces étapes supplémentaires qui « ne prennent qu’une seconde ».
Parfois, les plus grandes améliorations viennent de la résolution des plus petits irritants.
Et toi ?
C’est quoi le petit détail UX qui t’a rendu fou récemment ? Cette friction que tout le monde accepte mais qui te semble inacceptable ?
J’adorerais lire ton histoire dans les commentaires. Et cette fois, tu n’auras pas à te reconnecter pour la partager. 😉
VulTask est gratuit et open source. Si tu cherches un outil de gestion de projet simple, efficace, et maintenant parfaitement intégré à son blog, crée ton compte gratuitement sur VulTask.fr. 🦊
À propos de l’auteur
Je suis Daniel, intégrateur logiciel et développeur solo derrière VulTask. Quand je ne debugge pas des cookies ou des collations MySQL, je réfléchis à comment rendre la gestion de projet plus simple et plus humaine. Tu peux me suivre sur LinkedIn pour plus d’histoires de ce genre.
