Portfolio

Ornikar

De zéro à un

Faire passer 15 000 personnes par 96 préfectures

Premier product manager, salarié nº 8 · 2014–2016 · Marketplace B2C sur un marché réglementé

De zéro à 15 000 utilisateurs payants en 18 mois Trophée de design stratégique 2015 145 M$ levés 2018–2021

Le contexte

En 2014, Ornikar a quelques mois d'existence, huit salariés et déjà un procès. Les syndicats d'auto-écoles attaquent la société en avril pour exercice illégal et perdent en juin, pendant que la commission qui délivre l'agrément d'auto-école le refuse à chaque demande. L'agrément n'arrivera qu'en mars 2016, après la loi Macron. Pendant toute cette période, un élève Ornikar apprend le code en ligne, prend ses leçons avec un moniteur indépendant et passe l'examen en candidat libre : il doit être inscrit auprès de la préfecture de son département, qui lui attribue un numéro de candidat puis une place d'examen.

J'arrive comme premier product manager, rattaché aux deux fondateurs. On m'a confié l'équipe produit à monter, les parcours élèves et moniteurs, l'équipe support à créer et la chaîne d'inscription à l'examen de bout en bout.

Le vrai problème

Une startup qui vient de lever a un brief implicite, la courbe d'acquisition, sauf que le problème que je voyais dans les tickets était ailleurs. Un élève qui a payé et qui n'arrive pas à être inscrit à l'examen demande un remboursement, ouvre un ticket et laisse un mauvais avis. Il en arrivait à chaque cohorte, chacun plus coûteux qu'un élève jamais acquis.

L'inscription était difficile pour deux raisons. Les règles n'étaient écrites nulle part où nous pouvions les lire, puisque chacune des quatre-vingt-seize préfectures avait ses formulaires, ses délais et sa propre lecture des textes, qui vivaient dans la pratique des guichets plutôt que dans des documents. La population, elle, était celle de tous ceux qui passent le permis, ce qui m'interdisait de supposer quoi que ce soit de l'élève, ni son équipement, ni son aisance avec le français écrit, ni la validité de ses papiers.

Les contraintes

Une équipe de huit personnes, pas de cadre légal puisque l'agrément était refusé et les procès en cours, ce qui interdisait toute solution passant par le statut d'auto-école, quatre-vingt-seize administrations à faire fonctionner sans pouvoir leur imposer quoi que ce soit, sous le regard d'investisseurs qui attendaient une courbe de croissance plutôt qu'une équipe support.

Les options et ce que j'ai choisi

Ce que j'ai fait, dans l'ordre

• Faire les inscriptions à la main d'abord. J'ai monté une équipe support interne qui inscrivait les élèves un département à la fois. Le but était moins de tenir la charge que d'apprendre des règles qui n'existaient que dans la pratique des guichets.
• Automatiser chaque département une fois ses règles stables. Quand le support n'avait plus de surprise sur un département, je faisais encoder ce qu'il avait appris. Automatiser avant aurait encodé des suppositions.
• Alléger ensuite le parcours côté élève. Formulaires, documents, messages, redessinés sans rien supposer de la personne en face. Chaque étape retirée côté élève était une étape que le support avait d'abord faite à la main.
• Monter les deux équipes. J'ai recruté et dirigé l'équipe produit depuis la première embauche, ainsi que le support, que j'ai traité comme l'organe d'apprentissage du produit plutôt que comme un centre de coût.

L'ordre comptait, parce que chaque phase produisait la connaissance dont la suivante avait besoin.

Le parcours d'inscription, avant et après

Ce que ça a donné

Tout ce qui est décrit ici a été livré et a tourné en production. En dix-huit mois, Ornikar est passé de zéro à 15 000 utilisateurs payants, avec une chaîne d'inscription qui grandissait avec les cohortes au lieu de grandir contre elles et une charge support que la marketplace pouvait porter. Les remboursements pour inscription impossible ont cessé d'être un sujet de cohorte. En 2015, Ornikar a reçu le Trophée de design stratégique, catégorie design de services. L'entreprise a ensuite obtenu son agrément, dépassé le million d'inscrits et levé 145 millions de dollars entre 2018 et 2021, sur le socle d'inscription construit pendant ces deux ans.

Ce que j'en ai retenu

Chaque écran que j'ai conçu en supposant quelque chose de l'élève, un ordinateur plutôt qu'un téléphone, une lecture facile du français administratif, des papiers en règle, a cassé sur les cent premiers utilisateurs. C'est comme ça que j'ai appris la règle qui a ensuite décidé de l'ordre des trois phases : tant qu'une règle n'avait pas été vérifiée sur de vrais dossiers, elle n'entrait pas dans le produit.

Expertise technique

Encodage des règles de quatre-vingt-seize préfectures, capture et validation de documents, une chaîne d'inscription construite pour suivre les cohortes.

Management

Équipe produit montée et dirigée depuis la première embauche, équipe support créée et staffée, une priorisation défendue contre le réflexe acquisition devant les fondateurs et les investisseurs.

Écosystème

Les candidats, les moniteurs indépendants, les préfectures, les fondateurs et leurs investisseurs, sans oublier des syndicats d'auto-écoles en procès avec l'entreprise.

Méthode et références

Faire les choses à la main avant de les automatiser est le plus vieux conseil des startups, « Do things that don't scale » de Paul Graham (2013). Ici la phase manuelle servait moins à tenir la charge qu'à lire des règles écrites nulle part. Prioriser par friction retirée plutôt que par acquisition découle du marché : sur un produit réglementé, un utilisateur acquis qui échoue coûte plus cher qu'un utilisateur jamais acquis. La règle d'apprentissage qui a fixé l'ordre des phases, une hypothèse ne vaut qu'une fois confrontée à de vrais dossiers, est celle que j'ai décrite plus tard dans Vitesse et vision.

Lucca : revue de salaires

Fonctionnalité

Vingt vues candidates, trois qui restent

Directeur produit à temps partagé · depuis 2023 · Nouveau module sur une suite de 13 modules et 7 800 clients

De vingt vues à trois Livré en septembre 2024 Un modèle qui se lit à chaque étape

Le contexte

Lucca est un éditeur RH de treize modules, plus de 7 800 clients, qui partagent le dossier salarié, le modèle de permissions et la chaîne de validation. Un module nouveau hérite des contraintes des douze autres, comme une décision de design prise dans l'un remonte dans tous. J'y travaille depuis 2023 comme directeur produit à temps partagé, en lien direct avec le responsable de chaque suite métier. Sur ce module, j'ai travaillé avec le responsable de la suite business, la designer et les ingénieurs de l'équipe. J'avais la définition du produit et la décision de ce qu'on livre.

Ce qu'est une revue de salaires

Une fois par an, parfois deux, une entreprise décide qui est augmenté et de combien. Les managers proposent pour leur équipe dans une enveloppe, les RH et la finance consolident, vérifient les propositions contre le budget, la politique de rémunération et l'équité, une chaîne de validation clôture la campagne et la paie applique le résultat. Chaque entreprise la mène un peu différemment, par enveloppe ou par hiérarchie, par grade ou par site, en un tour ou plusieurs. Avant le module, la plupart le faisaient dans des tableurs échangés par mail.

Le vrai problème

Au moment où le design a commencé, vingt vues candidates s'étaient accumulées, dont aucune n'était fausse. Une vue par manager, une vue par enveloppe, une vue pour la réunion d'arbitrage, une vue pour la personne qui vérifie les totaux : chacune avait du sens pour le client qui l'avait demandée et aurait fait, construite seule, une fonctionnalité raisonnable. Toutes les demandes étaient légitimes, la question était plutôt ce qu'un manager peut apprendre en une seule campagne et ce qu'une RH doit pouvoir lire d'un coup quand les propositions arrivent.

Les options et ce que j'ai choisi

Ce que j'ai fait

• Cartographier la campagne telle qu'elle se mène. Pas telle que chaque client la décrivait, mais les moments où quelqu'un a besoin d'un écran pour agir.
• Trier les vingt demandes par le moment qu'elles servent. La popularité d'une demande dit qui a parlé le plus fort, alors que le moment dit ce dont la campagne a besoin. Rangées par moment, les vingt demandes tenaient presque toutes dans trois vues.
• Tenir le périmètre. Chaque vue conservée est une vue à apprendre, à maintenir et à multiplier par chaque évolution future, ce qui m'a fait porter ce refus devant le responsable de la suite à chaque nouvelle bonne raison d'élargir.

La campagne et la place des vues

Une vue par moment qui en a besoin, le reste en filtre ou en export.

Ce que ça a donné

Le module de campagnes de revue de salaires est sorti dans Pagga Rémunération le 16 septembre 2024, branché sur le dossier salarié, le modèle de permissions et la chaîne de validation de la suite, avec l'export vers la paie. L'Office international de l'eau écrit sur le site de Lucca que sa première campagne lui a fait gagner deux jours de réunions avec la ligne managériale et un jour de centralisation des données. Il est aussi devenu la démo des commerciaux sans que ce soit le but, parce qu'un modèle qui se comprend en une campagne se comprend aussi en un quart d'heure de rendez-vous. On construit un produit pour qu'il se vende, mais on ne conçoit pas son cœur pour la démo.

Ce que j'en ai retenu

Créer un produit sur une suite mature, c'est surtout de la soustraction, qui se défend plus difficilement qu'un ajout parce que chaque vue retirée a un client derrière elle. J'ai tenu parce que j'avais remplacé la question « qui l'a demandé » par « à quel moment de la campagne ça sert », ce qui ramène chaque demande au besoin qu'elle traduit.

Outils

Figma, le design system Lucca.

Expertise technique

Un module branché sur le dossier salarié partagé, le modèle de permissions et la chaîne de validation, sans objet local.

Management

Arbitrer les demandes clients avec le responsable de la suite, tenir un périmètre contre vingt bonnes raisons de l'élargir.

Écosystème

Les RH et les managers des clients, l'équipe design system, les douze autres modules et l'équipe commerciale qui a repris le module en démo.

Méthode et références

Concevoir pour le processus tel qu'il se mène plutôt que tel que chaque client le décrit, c'est la lecture Jobs to be done des demandes clients, où la demande décrit une solution et le job le moment où quelqu'un a besoin d'agir. Trois vues plutôt que vingt paramétrables, c'est aussi le parti pris que Lucca prend sur chacun de ses modules : le produit fixe le comment, c'est-à-dire la structure de la campagne, tandis que le client paramètre le quoi, ses enveloppes et ses règles. J'ai développé cet arbitrage dans Le parti pris du logiciel.

Lucca : impersonation

Pattern

Un mécanisme qui contraint le nommage, la navigation et les permissions

Directeur produit à temps partagé · depuis 2023 · Design system et patterns transverses

Une vue au lieu de deux Une règle dont héritent les équipes suivantes Article complet

Le mécanisme, en une minute

Impersonate, en anglais, c'est prendre l'identité de quelqu'un. Le mot a pris son sens technique dans les années 1990 avec Windows NT : un processus système qui devait agir avec les droits d'un utilisateur empruntait un moment son contexte de sécurité sans devenir cet utilisateur. L'idée en dessous est une délégation temporaire et traçable. Lucca l'a transposée de l'infrastructure à l'interface. Un sélecteur de salarié dans la vue principale : la manager choisit un membre de son équipe, l'écran devient celui du salarié, avec ses données et son contexte, tandis que chaque action est tracée au nom de la manager. Techniquement c'est une liste déroulante et un changement de contexte, pour une seule vue à maintenir.

Le vrai problème

Quand j'ai repris les patterns transverses du design system en 2023, les équipes utilisaient le mot sans ses conséquences. L'impersonation avait structuré la première génération de produits, ceux sur lesquels j'avais travaillé en 2011, mais personne n'en portait plus la règle. Le symptôme, c'était des écrans d'administration qui réapparaissaient module par module, chacun raisonnable pris seul. L'écran en plus ne coûte rien le premier jour, il coûte après, de deux façons. La première est la charge de maintenance : deux représentations du même objet ont des règles d'affichage, des formulaires et des cas limites qui sont corrigés deux fois, ou une seule sans que personne sache laquelle, si bien que chaque évolution du produit se paie sur chacune. La seconde, la plus chère, est la dette conceptuelle : multiplier les vues et les cas nominaux dispense de se poser la question de la cohérence, personne ne tranche ce qu'est l'objet, comment il se nomme et qui peut le voir puisque chaque écran a sa réponse locale, jusqu'à ce que la question revienne, plus tard, sur un logiciel qui a grandi dessus.

Ce que l'impersonation impose au reste du logiciel

Le mécanisme n'a rien de compliqué, ce que les équipes avaient perdu de vue, c'est tout ce qu'il impose au reste du logiciel. Si la vue principale d'un salarié peut être ouverte par quelqu'un d'autre, elle ne peut plus s'appeler « Mes congés » ou « Mon planning », le possessif cesse de fonctionner dès qu'une manager la regarde pour un membre de son équipe. Il faut des noms qui décrivent la ressource ou l'opération, « Demandes », « Planning », « Compte », ce dont la nomenclature sort plus claire pour tout le monde. Le menu ne peut plus être organisé en vue salarié, vue manager, vue admin, puisque l'impersonation efface cette frontière : il suit les étapes du processus métier, les permissions décidant de ce qui est visible. Enfin, l'auteur d'une action se distingue du propriétaire de la donnée : quand une assistante saisit un congé pour un dirigeant, l'absence appartient au dirigeant et la saisie est attribuée à l'assistante. Ça paraît évident une fois dit, pourtant les logiciels qui n'ont pas d'impersonation le modélisent rarement.

Les options et ce que j'ai choisi

Ce que j'ai fait

• Remonter à l'origine du mécanisme. Jusqu'à Windows NT et jusqu'aux premiers produits Lucca où il avait été la règle.
• Nommer ce qu'il impose. Les trois conséquences ci-dessus, avec les exemples concrets tirés des modules existants.
• L'écrire et le faire circuler. Le pattern dans le design system comme référence partagée des product managers, l'article pour l'extérieur.

Une vue, deux personnes

Aucun écran d'administration séparé à construire, à nommer ou à garder synchronisé.

Ce que ça a donné

Conçu et diffusé : le pattern est dans le design system, où les product managers des suites l'ont comme référence, l'article est sorti en mars 2025. Un pattern se juge sur des années, au nombre d'écrans d'administration qui ne sont pas construits.

Ce que j'en ai retenu

Chaque logiciel contient des choix de conception qui ne ressemblent pas à des fonctionnalités et qui déterminent la forme de toutes celles à venir. Les identifier et les écrire est probablement le travail de design le plus rentable sur un produit mature, mais aussi celui qu'on fait le moins, parce qu'il ne produit rien de visible et qu'il demande de comprendre le logiciel comme un tout. J'ai dû défendre ce temps comme du travail produit, ce que je referais.

Outils

L'écriture. Le document de pattern et l'article.

Expertise technique

Changement de contexte de sécurité, attribution dans la piste d'audit, modèle de permissions et leurs conséquences sur l'architecture de l'information.

Management

Transmettre un principe d'architecture à des équipes qui grandissent plus vite que la mémoire institutionnelle.

Écosystème

Les équipes produit et le design system de Lucca, puis tout logiciel B2B ou B2E où plusieurs rôles travaillent sur les mêmes données.

Méthode et références

La forme du pattern de Christopher Alexander, A Pattern Language (1977), utilisée pour ce à quoi elle sert : rendre explicites les forces derrière une solution récurrente, pour que des gens qui n'étaient pas là puissent l'appliquer. Le texte complet est dans L'impersonation : anatomie d'un pattern. L'impersonation est aussi un exemple de ce que j'appelle un parti pris du logiciel : une décision d'architecture prise une fois pour tous les modules, qui retire un choix aux équipes suivantes au lieu de le leur laisser.

Lucca : rôles admin

Conseil

Un modèle de permissions qui débordait sur l'expérience admin

Design produit, cadrage, modélisation fonctionnelle · 2025, usage cible 2026 · Avec le Produit, le Customer Success et la task force rôles

Moteur conservé, migration peu coûteuse Déployer une application ne crée plus de dette Permissions sensibles plus difficiles à accorder par erreur

Le contexte

Dans un logiciel RH, l'accès à une information n'est pas un booléen. La même opération peut être autorisée sur soi-même, sur les personnes qu'on supervise, sur un département, sur plusieurs entités légales ou sur toute l'entreprise, la permission effective étant la combinaison de ce qu'un utilisateur peut faire et de sur qui il peut le faire. Le modèle de Lucca couvrait tout ça, du cas simple, « un manager voit son équipe », aux configurations multi-applications, multi-entités, temporaires ou sensibles. Les administrateurs clients le configurent, les consultants Customer Success le déploient, les responsables sécurité en répondent. J'ai travaillé sur le sujet en 2025 avec le Produit, le Customer Success et une task force rôles. J'ai tenu le cadrage, la modélisation fonctionnelle et l'architecture d'usage cible. Le guide des rôles qui en est sorti a été écrit à trois.

Le vrai problème

Le mémo du Customer Success décrivait les irritants moment par moment, ce qui m'a fait chercher le problème dans le cycle de vie d'un client plutôt que dans l'écran. À la création d'une instance, il faut une doctrine et il n'y en avait pas. À l'ajout d'une application, il faudrait intégrer ses permissions dans les rôles existants, une opération assez fastidieuse pour qu'on crée à la place un rôle secondaire mono-application par utilisateur, si bien que chaque application vendue ajoutait de la dette de configuration : c'était le coût du cross-sell. Au remplacement d'un salarié ou à l'arrivée d'un membre du CSE, il faut un objet d'exception, or le seul disponible ressemblait à un rôle normal. À l'audit enfin, la question la plus fréquente, « pourquoi cette personne voit-elle cette donnée », coûtait plus cher à répondre que la configuration n'avait coûté à faire, parce que la réponse se reconstruisait à partir de plusieurs rôles et que les journaux ne se lisaient ni par utilisateur ni par rôle.

Deux choses ont cadré le travail. Le libellé d'une permission décrivait une action, pas tout ce à quoi elle ouvrait l'accès, si bien qu'une permission pouvait sembler juste pour un besoin métier et exposer des données personnelles. Un signal du Customer Success donnait la cible : dans à peu près neuf cas sur dix qu'ils observaient, un utilisateur aurait eu besoin d'un seul rôle multi-applications, ce qui suffisait pour concevoir le chemin nominal autour d'un seul rôle.

Les contraintes

Il fallait garder tout l'éventail fonctionnel, parce que les clients avancés couvrent de vrais cas complexes, toucher le moins possible au modèle de données pour que la migration reste abordable sur des milliers d'instances en production, ne pas confondre simplifier et supprimer les exceptions, qui existent dans la réalité des entreprises, prévenir les erreurs de sécurité sans rendre pénibles les opérations ordinaires, le tout dans une doctrine que des consultants et des administrateurs clients peuvent appliquer, pas seulement l'équipe produit.

Les options et ce que j'ai choisi

Ce que j'ai fait

• Recadrer le problème. De « simplifier l'écran des rôles » à « changer le modèle mental », en partant des cinq moments du cycle de vie où le modèle faisait mal.
• Modéliser les objets. Le rôle principal devient la fonction normale d'un salarié : les permissions ne définissent pas le rôle, c'est la fonction qui définit les permissions nécessaires. Les rôles secondaires deviennent des accès complémentaires, réservés aux situations temporaires, exceptionnelles ou à petite population. Tous les managers partagent un rôle Manager, ceux qui gèrent les notes de frais recevant un accès en plus plutôt qu'un rôle « Manager avec frais ».
• Introduire la criticité. Lire des données ordinaires de son équipe, lire des données personnelles, traiter des données de gestion et changer la configuration de l'instance ne portent pas le même risque, donc l'interface change de comportement avec lui au lieu d'espérer que l'administrateur s'en souvienne.
• Concevoir les garde-fous, sur tous les chemins. Les permissions de gestion n'entrent pas dans un rôle non critique, l'ajout en masse à un rôle critique est bloqué ou limité, un import CSV passe les mêmes validations que l'action équivalente dans l'interface, sinon l'écran est sûr et le système ne l'est pas.
• Séquencer le déploiement d'une application. Des accès temporaires pour l'installation et les tests, la validation client, la fusion dans les rôles principaux à la mise en production, le nettoyage.
• Retourner l'investigation. Une vue des habilitations qui part d'une personne et remonte aux sources de ses droits, des journaux lisibles par utilisateur, rôle, permission et modification, un diagnostic qui signale les utilisateurs sans accès, les grandes populations exposées et les rôles quasi redondants.

Installer une nouvelle application

Ce que ça a donné

Le résultat est une proposition : l'architecture d'usage cible, le guide des rôles écrit avec la task force comme doctrine partagée entre le Produit, le Customer Success et les clients, les wireframes des parcours de friction et de la vue des habilitations, la stratégie de migration. C'est une vision 2025 avec un usage cible en 2026. Les mesures qui suivront la direction sont définies : la part d'utilisateurs avec un seul rôle principal, le nombre d'accès complémentaires par utilisateur, le temps et les erreurs pour ouvrir les accès d'un nouvel arrivant, les accès temporaires encore présents quelques jours après une mise en production, le temps pour répondre à « pourquoi cet utilisateur a-t-il ce droit ». Deux points restaient ouverts à la fin de mon intervention : la discovery du module de diagnostic et le traitement exact des rôles dont la criticité ne peut pas être déduite.

Ce que j'en ai retenu

Quand un modèle historique porte de la valeur métier, la meilleure simplification n'est pas toujours d'avoir moins d'objets, ici c'était une asymétrie, un socle normal et une couche d'exceptions, avec des garde-fous qui suivent l'effet d'une action plutôt que l'écran par lequel on arrive. L'autre chose que je garde, c'est la classe « criticité inconnue » : moins confortable qu'une classification automatique, mais la seule qui ne fasse pas mentir le système sur des configurations historiques.

Outils

Wireframes des parcours de friction, le guide des rôles écrit avec la task force.

Expertise technique

Modèle d'autorisation : opérations, périmètres, permissions, rôles, habilitations, un attribut de criticité, validations à l'import, journaux lisibles par plusieurs axes.

Management

Une task force entre le Produit et le Customer Success, une doctrine écrite pour être appliquée par des consultants et des administrateurs clients.

Écosystème

Les administrateurs clients, le Customer Success, les responsables sécurité, treize modules et le poids réglementaire des données RH.

Méthode et références

La sécurité par l'interaction plutôt que par la documentation : au lieu d'espérer que l'administrateur se souvienne qu'une permission est dangereuse, l'interface change de comportement avec le risque. Le reste est de la modélisation de domaine, tenue près du moteur existant pour garder le coût de migration bas. Au fond, un modèle de permissions qui peut tout représenter est un logiciel sans opinion, la complexité du métier ne disparaît pas, elle est déplacée vers l'administrateur sous forme de configuration. Le rôle principal et les accès complémentaires sont une façon de la reprendre à notre compte, l'arbitrage que je décris dans Le parti pris du logiciel.

UBAQ

Conseil

Un audit qui a trouvé l'organisation derrière l'interface

Audit produit, puis accompagnement · Plateforme NTU, conformité santé

Équipe sortie du mode urgence Refonte de la navigation lancée Cinq entretiens, une revue de l'application

Le contexte

UBAQ vend des logiciels de conformité réglementaire aux industriels de la santé. NTU gère la transparence des liens d'intérêt entre laboratoires et professionnels de santé, dans le cadre de la loi d'encadrement des avantages. Un logiciel de conformité est acheté parce que la loi l'impose et gardé si les gens qui l'utilisent tous les jours y retrouvent leur travail, ce qui donnait son poids à l'interface. Les clients étaient en cours de migration depuis l'ancien produit, un risque de churn à la fois, vers une interface qui leur compliquait la vie. Il n'y avait pas de profil UX dans l'entreprise et l'équipe produit vivait en mode pompier. L'audit m'a été commandé via Grandwork. J'ai fait seul la méthode, les entretiens, le diagnostic et les recommandations, puis les maquettes de correction et la roadmap revue avec l'équipe.

Le choix de la preuve

La première décision d'un audit, c'est ce qu'on regarde. Le réflexe serait de proposer des tests utilisateurs et de demander les analytics, ce que je n'ai pas fait.

Premier niveau : ce que l'interface montrait

L'exemple le plus net est un objet que le système appelle « manifestation ». Pour le modèle, c'est une seule chose. Pour les commerciaux qui l'utilisent, c'en est trois, des événements, des dons et des contrats, derrière lesquels ils pensent en dépenses et en clients. Le modèle technique a été simplifié au détriment du modèle mental de ceux qui l'utilisent tous les jours, ce que Don Norman appelle le gouffre d'évaluation. Le reste de la liste est du même ordre : un kanban sans glisser-déposer et à étapes non linéaires, un tableau déguisé qui promet un flux qu'il ne montre pas, un menu dont les entrées changeaient avec l'état d'un objet métier, des formulaires qui mélangent quatre types d'information et deux flux métier sur un seul écran, denses par refus de choisir.

Deuxième niveau : pourquoi ça a tenu

Chacun de ces points aurait pu être corrigé seul. La question utile était pourquoi le kanban était dans cet état alors que l'équipe le savait défaillant. Les entretiens ont remonté aux mécanismes. Chaque demande client devenait une fonctionnalité sans question de valeur : l'équipe recevait des solutions à construire, jamais des problèmes à résoudre, ce qui est le test le plus simple pour distinguer une organisation informatique d'une organisation produit. La roadmap était pilotée par la migration des clients de l'ancienne solution, une gestion du churn au coup par coup qui sacrifie les clients de demain à la rétention d'aujourd'hui. Sans expertise UX ou produit dans la pièce, chaque fonctionnalité atterrissait là où elle était la moins chère à construire. Le mécanisme s'entretient tout seul, puisque chaque correctif rapide ajoute de la complexité, que la complexité augmente la pression et que la pression pousse vers des correctifs plus rapides.

Ce que j'ai recommandé

Un audit qui s'arrête à l'interface produit une liste de corrections, utile et fragile : si les conditions qui ont produit les problèmes persistent, ils reviennent sous d'autres formes en quelques mois. J'ai donc recommandé sur trois registres en rendant explicite qu'ils ne sont pas indépendants, pour que le commanditaire choisisse en connaissance de cause à quelle profondeur il intervient.

Ce que pensent les utilisateurs et ce que le système leur montrait

Ce que ça a donné

J'ai livré le diagnostic à deux niveaux, les recommandations sur trois registres, puis les maquettes de correction et une roadmap revue. La refonte de la navigation a démarré sur ces recommandations et l'accompagnement s'est prolongé sur l'exécution avec l'équipe produit. La suite a montré que le diagnostic organisationnel était le levier le plus utile : l'équipe a pu arbitrer autrement parce qu'elle avait des mots pour nommer ce qui coinçait au-delà de l'interface.

Ce que j'en ai retenu

Un problème d'interface qui a survécu à plusieurs correctifs est un problème d'organisation, ce qu'il est délicat de dire au commanditaire parce qu'il a commandé un diagnostic d'interface. Cinq entretiens suffisent quand on les mène comme une enquête sur les mécanismes plutôt que comme une collecte de souhaits.

Outils

Entretiens, revue de l'application en recette, maquettes.

Expertise technique

Modèle de domaine contre modèle mental, architecture de navigation, la lecture d'un kanban qui est un tableau déguisé.

Management

Sortir une équipe du mode réactif : un cadre de priorisation, du temps protégé pour la cohérence, le diagnostic organisationnel dit à voix haute.

Écosystème

La conformité santé, les laboratoires pharmaceutiques, la loi d'encadrement des avantages, l'équipe produit d'un éditeur B2B de niche.

Méthode et références

Le gouffre d'évaluation de Don Norman, The Design of Everyday Things, pour le premier niveau. Pour le second, chercher les causes des causes avant de décider quoi faire de l'interface. Le raisonnement complet est dans Anatomie d'un audit produit. Deux autres textes donnent le fond. La conformité n'est pas une fonctionnalité décrit ce qui fait qu'un logiciel réglementaire est acheté pour la loi et gardé pour l'usage. Vous n'avez pas besoin d'un Product Manager porte sur la différence entre une équipe qui reçoit des solutions et une équipe qui reçoit des problèmes.

Guinet-Derriaz 1912

Logiciel

Un système d'information pour un groupe qui n'en avait pas

Système d'information à partir de zéro · 2022, un an à deux jours par semaine · 100 k€ de budget

Un an, deux jours par semaine, 100 k€ Une douzaine de fichiers privés remplacés par un référentiel 14 carrières, un catalogue

Le contexte

Guinet-Derriaz extrait et transforme de la pierre depuis 1912. En 2022, le groupe a quatorze carrières, des clients à l'étranger et fonctionne sur des fichiers par équipe : les commerciaux chiffrent sur une version du catalogue, les opérations travaillent sur une autre, si bien qu'aucune question qui traverse deux équipes n'a une seule réponse. Je suis rattaché à la direction du groupe, seul profil produit, avec les commerciaux, les opérations et les carrières comme interlocuteurs. J'avais tout le système d'information, du catalogue aux outils, dans une enveloppe de cent mille euros et deux jours par semaine pendant un an.

Le vrai problème

On me demandait des outils, un pour les commerciaux, un pour les carrières, vite. Le problème que j'ai trouvé en dessous, c'est qu'un bloc de marbre change de nom entre le moment où un client le commande et le moment où la production le traite et que quatre versions du catalogue circulaient. Un outil construit sur ces quatre versions aurait échoué au premier désaccord entre deux équipes, qui aurait renvoyé tout le monde aux tableurs. Tant que le catalogue n'était pas réglé, ni le stock, ni les devis, ni les livraisons ne pouvaient être automatisés.

Les options et ce que j'ai choisi

Ce que j'ai fait, dans l'ordre

• Formaliser le catalogue produit. Une description de chaque produit sur laquelle les commerciaux, les opérations et les carrières sont d'accord, avec la correspondance entre le nom commercial et le nom de production.
• Construire la base de données partagée. La pièce la moins visible et celle dont tout dépend, livrée avant que quiconque voie un outil.
• Sélectionner les outils plutôt que les construire. Pour la vente et pour les opérations, posés sur la même donnée.
• Laisser l'irrégulier sur Excel et Airtable. Jusqu'à ce que les règles soient assez claires pour être encodées, en décidant ce qui ne serait pas construit, ce qui à ce budget était le principal levier.

L'ordre du travail

Les outils étaient demandés en premier, le catalogue a été construit en premier.

Ce que ça a donné

Au bout de l'année, le groupe chiffrait, suivait ses commandes et livrait depuis un référentiel partagé au lieu d'une douzaine de fichiers privés. Les commerciaux, les opérations et les carrières travaillaient sur la même donnée, ce qui donne une seule réponse à une question qui traverse deux équipes.

Ce que j'en ai retenu

À budget fixe, la séquence décide de ce qui existe à la fin. Un référentiel construit en premier est ce qui permet à chaque outil suivant d'être petit, donc achetable plutôt que développé. L'autre chose, c'est qu'un tableur reste la bonne réponse tant qu'un processus n'a pas de règle stable et que vouloir l'automatiser trop tôt coûte plus cher que de l'attendre.

Outils

Un référentiel produit et sa base de données, des éditeurs pour la vente et les opérations, Excel et Airtable pour ce qui n'était pas encore automatisable.

Expertise technique

Modélisation d'un catalogue pour un produit physique et variable, un système d'information à partir de rien, la sélection d'éditeurs.

Management

Un an à deux jours par semaine avec un budget fixe : discipline de périmètre et dire non aux outils demandés en premier.

Écosystème

Les carrières, des clients internationaux, les commerciaux, les opérations, un groupe familial qui découvre le logiciel.

Méthode et références

Le référentiel avant les outils, acheter avant de construire, laisser un processus sur tableur tant que sa règle n'est pas connue. Le premier point, je l'appelais unicité dans un rapport de stage de 2010 : la cohérence du système, l'interopérabilité de ses composantes et une représentation simple du tout pour l'utilisateur. Le dernier est le revers du parti pris du logiciel : encoder une règle est un pari sur la bonne façon de faire, qu'on ne prend pas tant qu'on ne connaît pas la règle.

Synaxe

Conseil

Un produit capteurs qui était un produit conformité

CPO à temps partagé · 2023–2024, six mois · Suite DUNE, carrières, centrales à béton et à enrobés

Des capteurs à la conformité en six mois Deux outils livrés avec deux développeurs De nouveaux contrats et des renouvellements

Le contexte

Synaxe édite DUNE, utilisée par des exploitants de carrières, de centrales à béton et de centrales à enrobés, avec Colas et Heidelberg Materials parmi ses clients. Le produit était présenté comme une couche logicielle au-dessus de capteurs installés sur les camions. J'y suis intervenu six mois comme CPO à temps partagé, avec les fondateurs et l'équipe d'ingénierie. J'ai mené les entretiens avec les exploitants, la définition du produit, les maquettes et les spécifications, puis la livraison de deux outils avec deux développeurs.

Le vrai problème

Le pitch parlait de mesure, de meilleurs chiffres sur les flux de matériaux, alors que les exploitants que j'ai interrogés parlaient d'autre chose. Ils déplacent des matériaux, dont des déchets, dans un cadre réglementaire qui n'a pas été écrit pour ce qui se passe sur un site, avec des obligations qui s'empilent, déclarations d'acceptation préalable, bordereaux de suivi, registres, Trackdéchets. Leur difficulté quotidienne était moins de savoir ce qu'ils avaient fait que de le prouver après coup à un inspecteur ou à un donneur d'ordre, sachant qu'un site qui ne peut pas déposer ses déclarations ne peut plus rien recevoir. La donnée existait dans la pratique et ne pouvait pas être transformée en preuve. Chez le client, la conformité a une ligne budgétaire, alors que de meilleurs chiffres n'en ont pas.

Les options et ce que j'ai choisi

Ce que j'ai fait

• Interroger les exploitants. Ce qu'ils font sur un site, ce qu'ils doivent prouver, à qui, ce qui se passe quand ils ne peuvent pas.
• Recadrer le problème, de technique à réglementaire. L'argument présenté aux fondateurs venait des entretiens plutôt que d'une conviction.
• Concevoir et spécifier. Les maquettes et les spécifications des deux outils, pour que l'équipe ait quelque chose à construire.
• Livrer avec deux développeurs. L'outil de facturation, du ticket de pesée à la facture, puis l'outil de conformité déchets, dans les six mois.

Avant et après

Ce que ça a donné

Les deux outils sont en production chez des clients et ont amené de nouveaux contrats et des renouvellements. Le repositionnement est un choix des fondateurs, que j'ai argumenté à partir des entretiens.

Ce que j'en ai retenu

Des entretiens menés comme une enquête plutôt que comme une liste de souhaits donnent le problème que le client paie. Un pivot, lui, n'existe que s'il produit quelque chose : ce qui a compté ici, c'est moins la présentation du repositionnement que les deux outils qui tournaient à la fin des six mois.

Outils

Entretiens, maquettes, spécifications.

Expertise technique

Du ticket de pesée à la facture, des données de site transformées en registres de conformité, les obligations déchets comme exigences produit.

Management

Mener un repositionnement avec des fondateurs en six mois et livrer avec deux développeurs.

Écosystème

Les exploitants de carrières et de centrales, les majors du BTP comme clients, le régulateur et ses inspecteurs.

Méthode et références

Des entretiens d'exploitants menés comme une enquête, puis un avant-après qui nomme ce qu'on a mis de côté. Ce que cette mission m'a appris sur ce qui se vend dans le logiciel B2B français est dans La conformité n'est pas une fonctionnalité, publié en novembre 2024 : on achète pour la conformité et on garde parce qu'on en retire quelque chose. C'est pour ça que l'outil de facturation, du ticket de pesée à la facture, est sorti en même temps que le registre de conformité plutôt qu'après.

monbanquet.fr

Logiciel

Un devis sur mesure en trente minutes

Directeur produit · 2017–2019 · Traiteur en ligne appuyé sur des artisans indépendants

Devis en 30 min contre des jours Tunnel d'acquisition +50 % Racheté par B2B Food Group (2020)

Le contexte

Monbanquet, créé en 2016, vendait des buffets d'entreprise préparés par plus de soixante-dix artisans sélectionnés. En janvier 2020, quand B2B Food Group l'a racheté, la société avait servi 500 000 convives sur 10 000 événements. J'y ai dirigé le produit de 2017 à 2019, rattaché au CEO, avec l'équipe commerciale, les opérations et les ingénieurs. L'outil commercial était à moi, de la formulation du problème à la version livrée.

Le vrai problème

Un traiteur qui ne cuisine pas lui-même vit sur des promesses. Chaque commande est un devis sur mesure qui doit tenir la marge en respectant des contraintes que personne ne voit d'un coup : ce que chaque artisan peut produire ce jour-là, le picking, les tournées de livraison, la charge de chaque cuisine à cette date. Un commercial qui rédige un devis n'a aucun moyen de savoir lequel est impossible. Les devis sortaient donc en plusieurs jours, vérifiés par les opérations après coup, retravaillés ou refusés, pendant que les clients attendaient un menu que la concurrence, elle, envoyait.

Les options et ce que j'ai choisi

Ce que j'ai fait

• M'asseoir avec les commerciaux et les opérations. La liste de ce qui rendait un devis impossible une fois envoyé est sortie de là : la marge, le picking, les livraisons, la charge des cuisines.
• Mettre ces contraintes dans la génération. Le générateur ne propose que des menus que l'opération peut livrer ce jour-là, à une marge qui tient.
• Livrer et mesurer sur le tunnel. Un devis en trente minutes, l'effet lu sur le tunnel d'acquisition.

Un devis, avant et après

Ce que ça a donné

Les commerciaux l'utilisent tous les jours et les opérations ont cessé de retravailler des devis déjà envoyés. Un menu personnalisé en trente minutes là où la concurrence mettait plusieurs jours. Le tunnel d'acquisition en hausse de cinquante pour cent, le chiffre que nous suivions à l'époque. « C'est ce qui a sauvé l'entreprise », selon le CEO. B2B Food Group a racheté Monbanquet en janvier 2020.

Ce que j'en ai retenu

Mettre les contraintes dans la génération plutôt que dans une validation après coup, c'est la méthode, qui vaut au-delà des buffets parce qu'un outil de vente qui ignore ce que l'opération sait produit des promesses. Le plus difficile n'a pas été l'interface mais de faire dire aux cuisines ce qu'elles savaient sans l'avoir jamais écrit.

Expertise technique

Génération sous contraintes, calcul de marge, capacité par cuisine et par date.

Management

Directeur produit dans une petite équipe, autant sur le plateau commercial et en cuisine que sur le produit.

Écosystème

Des artisans indépendants, des cuisines, des clients entreprises, une équipe commerciale payée sur ce qu'elle signe.

Méthode et références

Aller chercher les contraintes là où elles sont, chez ceux qui les subissent, pour les mettre dans l'outil plutôt que dans une étape de contrôle. Un générateur qui refuse un menu est un logiciel qui prend position à la place du commercial, ce qui le rend rapide puisque chaque décision prise par l'outil est une décision de moins pour l'utilisateur. J'ai développé l'argument dans Le parti pris du logiciel.

Luko by Allianz Direct

Prototype

Un redesign non sollicité, avec les écrans

Projet perso · mars 2026 · Espace client d'assurance · Construit avec Claude en quelques heures

Prototype en ligne Sinistre : cinq étapes depuis l'accueil Attestation : de cinq interactions à trois Vente croisée gardée, bannières retirées

Pourquoi celui-ci est ici

Les redesigns non sollicités ont été une mode Dribbble il y a dix ans et ont été critiqués à juste titre : concevoir sur un coin de table sans les contraintes réelles du produit, c'est trop facile. J'inclus celui-ci quand même, d'abord parce que c'est le seul travail de cette page dont les écrans m'appartiennent, tout le reste étant sous confidentialité, ensuite parce qu'il montre ce que je fais quand personne ne me paie. J'en ai parlé avec un ancien de l'équipe Luko, qui a confirmé le diagnostic : après le rachat par Allianz Direct, l'équipe avait beaucoup changé et les décisions produit étaient devenues difficiles à faire construire.

Le vrai problème

J'ai fait trois constats. Sur le positionnement, l'espace client mélangeait un outil de gestion et un canal d'acquisition sans hiérarchie, la vente passant avant le service pour des gens venus se faire servir. Sur la confiance, le chat passait en anglais quand il plantait, des pages presque vides se chargeaient lentement et un rafraîchissement pouvait renvoyer une erreur 503 avec la page en texte brut, bandeau cookies compris. Sur la hiérarchie, les documents vivaient à trois endroits, les blocs de l'accueil se lisaient comme des pages marketing, l'invitation à la newsletter était plus visible que les contrats et une bannière Allianz Travel suivait l'utilisateur jusque dans le formulaire d'attestation. Le modèle de l'utilisateur, « je gère mon assurance », ne correspondait pas à l'architecture, « voici nos offres ».

La règle et son coût

Ce que j'ai fait

• Auditer en trois constats. Positionnement, confiance, hiérarchie, ci-dessus.
• Itérer trois fois, un principe à chaque fois. La divulgation progressive : le sinistre démarre sur l'accueil par le choix du bien, les actions apparaissent dans le contexte de chaque contrat. Le wording comme interface : « ajouter un contrat » devient « s'assurer », la vente croisée devenant une section de l'accueil, Voyage et Auto avec ce que chaque offre couvre, à la place des bannières et d'un bouton générique qui ne promettait rien. La proximité : l'onglet Documents disparaît, les documents appartiennent à leur contrat, le profil se range sous l'avatar et la navigation passe de trois onglets à aucun.
• Reconstruire les deux parcours de bout en bout et mettre le prototype en ligne. L'accueil, l'assistant de déclaration de sinistre et le parcours d'attestation sont cliquables sur dist-neon-delta-32.vercel.app.

La vente croisée, gardée comme une fonctionnalité

L'objectif business n'a pas bougé : un assuré habitation est un client pour le voyage et l'auto. Ce qui a changé, c'est la forme. Les bannières, qui suivaient l'utilisateur jusque dans le formulaire d'attestation, sont remplacées par une section « S'assurer » sur l'accueil, au même niveau que les contrats, avec deux entrées, Voyage et Auto, et pour chacune ce qu'elle couvre. Une carte vide « Assurer un autre logement » ferme la liste des contrats. Vue du business, la contrainte semble s'opposer à l'expérience. Vue avec un peu de métier, elle s'y incorpore, parce qu'exposer l'offre, c'est exposer le service, et qu'un assuré qui découvre qu'il peut couvrir son voyage au même endroit y gagne autant que l'assureur. C'est toute la différence entre une publicité et une fonctionnalité.

Déclarer un sinistre : du contrat au problème

Aujourd'hui, déclarer un sinistre suppose de trouver d'abord le bon contrat, puis un lien enfoui dans ses sous-menus, ce qui présume que l'utilisateur pense en numéros de contrat plutôt qu'au problème qu'il a. Le redesign part du problème, sur l'accueil, avec un assistant en cinq étapes, bien, type, détails, photos, confirmation, qui ne renvoie jamais l'utilisateur vers un contrat.

Obtenir une attestation : de cinq interactions à trois

Depuis l'accueil, l'utilisateur clique, choisit le contrat et voit d'un coup les quatre types d'attestation, responsabilité civile, scolaire, location de salle, location de vacances, avec leur cas d'usage en sous-titre. Un clic télécharge le PDF. Le parcours actuel prend cinq interactions, un scroll et un accordéon.

La vue contrat : tout au même endroit

Chaque contrat a sa page : adresse, statut, dates et prix annuel en haut, puis le sinistre pour ce bien, puis les attestations de ce contrat, puis ses documents avec leurs dates, puis les garanties, les personnes assurées et le paiement en accordéons. L'original disperse tout ça entre l'accueil, un onglet Documents et les sous-pages du contrat. Le redesign met chaque information dans le contexte qui lui donne son sens.

Ce que ça montre

Un prototype en ligne, avec deux parcours reconstruits de bout en bout. L'argument métier est celui de n'importe quel espace client : moins d'appels au support, moins d'assurés qui abandonnent et une offre qui se vend parce qu'elle est présentée comme un service, à la place des bannières. Le raisonnement et les écrans sont là, le cas complet est dans Étude de cas : redesign de Luko avec Claude.

Ce que j'en ai retenu

L'audit, les itérations et les écrans ont été produits avec Claude en une courte session. C'est la règle posée avant d'ouvrir l'outil qui fait le cas, sans elle le même outil aurait produit un habillage. Le raisonnement reste le travail, l'outil le rend seulement peu coûteux à montrer. En mars 2025, j'écrivais dans Paradoxe de Solow et IA qu'on utilise surtout les LLM pour faire plus vite ce qui existe déjà. Ce cas n'y fait pas exception : la vitesse a rendu l'exercice possible en quelques heures, elle n'a rien changé au raisonnement. L'autre chose que je garde, c'est le sort de la vente croisée : une contrainte business qui ressemble à un ennemi de l'expérience devient une fonctionnalité dès qu'on la traite comme un service à exposer plutôt que comme une publicité à placer.

Outils

Claude, pour l'audit, les itérations et les écrans.

Expertise technique

Architecture de l'information d'un espace client d'assurance, un prototype qui fonctionne.

Management

Aucun. Un projet perso.

Écosystème

Un ancien de Luko et les assurés d'un assureur après un rachat.

Méthode et références

Le principe qui a guidé la suppression est celui de Gmail a deux choses à nous apprendre : la qualité d'une interface se mesure à ce qu'on ne peut plus lui enlever, chaque élément affiché devant porter une intention. Le point de départ est un billet publié sur LinkedIn, le cas complet, avec les écrans, est dans Étude de cas : redesign de Luko avec Claude.