Product Owner — Agent IA Legal-Tech

400 études notariales, 20 000 transactions par mois, plus de 2 M€ d'ARR, six ingénieurs, et zéro personne au produit. Le cofondateur fait les specs entre deux réunions. Vous venez faire du produit une vraie discipline.

Notre client construit le collègue IA des notaires français. Le produit vit à l'intérieur d'Outlook et de Word, là où les notaires travaillent déjà : il lit les mails d'un dossier, rédige les réponses, va chercher les pièces manquantes dans une douzaine de registres publics et partenaires, extrait les faits juridiquement pertinents et signale ce qui demande un humain.

Plus de 400 études notariales l'utilisent. Plus de 20 000 transactions passent par le produit chaque mois. L'ARR a dépassé les 2 M€. Six ingénieurs, et pas encore une seule personne au produit.

Le produit couvre toute la chaîne de la transmission d'actifs : collecte et interprétation des pièces administratives, rédaction des actes, publication au service des hypothèques.

L'objectif est de 4 M€ d'ARR à fin d'année et de 20 M€ à horizon deux ans. L'équipe engineering est passée de trois à six ingénieurs en deux mois. Les utilisateurs sont des professionnels exigeants, sur des actes juridiques où l'erreur n'est pas une option : la fiabilité est un sujet produit autant que technique.

Pourquoi ce poste existe

Aujourd'hui, le cofondateur EST la fonction produit. Il écrit les specs, classe le backlog, décide ce qui part, parle aux notaires et court après ce qui s'est passé une fois la release sortie. Il fait les cinq, et il fait les cinq à peu près deux fois moins bien qu'ils ne le méritent.

Le résultat est prévisible : des specs trop minces, des ingénieurs qui construisent la mauvaise chose ou qui s'arrêtent pour poser une question, des priorités qui bougent parce que lui les a bougées, et des fonctionnalités qui sortent sans que personne ne vérifie qu'elles font ce qui était demandé. La boucle ne se ferme presque jamais : ça sort, et personne ne mesure si ça a changé quelque chose.

Vous êtes là pour faire du produit une discipline à part entière, au lieu d'une chose qu'un fondateur fait entre deux autres.

Ce que vous portez

• Des specs sur lesquelles les ingénieurs peuvent construire sans avoir à retrouver le fondateur. Problème, comportement attendu, cas limites, définition du fini. Écrit. C'est le point de levier le plus fort de la liste, et ça commence la première semaine.
• Le backlog et la mécanique autour. L'équipe tourne sur Linear, avec 80 % de la capacité allouée aux cycles et 20 % à une voie d'interruption. L'outillage est bon, la discipline est irrégulière. Vous portez le classement, le grooming, et le fait de dire non au fondateur quand il rebat les cartes.
• L'acceptance. Rien n'arrive chez un notaire parce qu'un ticket a été glissé dans « Done ». Vous vérifiez dans le produit que ça fait bien la chose, avant que ça compte.
• La fermeture de boucle. Ce qui est sorti, pour qui, et si ça a bougé. PostHog pour le comportement, Productlane pour ce que disent les clients. S'en servir pour répondre à « est-ce que ça a marché ? », c'est à vous.
• La discovery. Vous parlez aux notaires directement, pas via le fondateur, pas via un résumé. Vous revenez avec des problèmes qu'il n'avait pas vus et un avis sur ceux qui comptent.

Ce que le fondateur garde, et ce qui vient ensuite

Il garde aujourd'hui la roadmap et la direction stratégique. Il cherche aussi à construire une société qui tourne sans lui, et préfère faire grandir quelqu'un d'ambitieux que gérer quelqu'un de confortable. Le périmètre grandit donc avec la confiance : plus vous lui retirez d'opérationnel en le faisant mieux que lui, plus il vous passe de la moitié stratégique.

Pour qui c'est

• Vous avez fait du produit dans une petite société B2B SaaS où le process n'existait pas encore. Pas hérité d'un dispositif de rituels et de cérémonies : construit un, à partir de rien, et gardé assez léger pour que les gens s'en servent.
• Vous écrivez des specs que les gens lisent vraiment. Vous savez prendre un problème flou dans un domaine compliqué et en faire quelque chose qu'un ingénieur attrape sans réunion. L'ambiguïté, vous la retirez, vous ne la transmettez pas.
• Vous allez à la source. Vous serez en visio avec des notaires, dans les tickets de support, à regarder quelqu'un mal utiliser le produit sans lui expliquer comment il devrait s'en servir.
• Vous avez du jugement sur ce qu'il ne faut pas construire. La contrainte ici n'est pas le manque d'idées : vous passerez plus de temps à tuer et à séquencer qu'à générer.
• Vous êtes à l'aise près de la matière. Aujourd'hui le fondateur spécifie et l'ingénieur frontend produit une maquette v0 ; cette boucle fonctionne et peut continuer avec vous à sa place. Savoir mettre les mains dedans et itérer sur ces maquettes est un bonus, pas un filtre : ce n'est pas un poste de design,