Ce que 6 apps en 3 semaines m'ont appris sur la gestion de produit

En mars 2026, j'ai décidé de construire une application de préparation à l'examen du permis de conduire.

Trois semaines plus tard, j'avais six applications en production, couvrant six certifications françaises différentes : civique, habilitation électrique, AIPR, HACCP, SST/PSC1, et TCF.

Ce n'était pas prévu. Et c'est exactement pour ça que c'est instructif.

Ce qui s'est passé

Le premier produit était simple : des flashcards pour réviser les questions officielles du Code civique. L'examen de naturalisation. Un marché de 135 000 candidats par an, aucune app sérieuse disponible en français.

Deux heures après le lancement, j'avais les premières données d'usage. Ce que j'ai vu m'a surpris : les utilisateurs ne lisaient pas les explications. Ils voulaient la réponse, l'essai, la correction. Le flux de révision était cassé à l'endroit où j'avais passé le plus de temps.

Première leçon : les données réelles rendent obsolète tout ce que vous avez supposé pendant la conception.

J'ai itéré. Puis j'ai appliqué le même modèle à un deuxième marché — l'habilitation électrique. J'avais le template. Le contenu était public. L'infrastructure existait. La deuxième app a pris six heures. Puis quatre. Puis deux.

En trois semaines, six applications. Chacune avec son propre domaine, son propre public, son propre Stripe.

Ce que cette expérience m'a appris

1. Le scope initial est toujours trop grand.

Pour chaque app, j'avais une liste de fonctionnalités : révision adaptative, suivi de progression, mode examen, notifications, mode hors-ligne. J'ai lancé avec les flashcards et un score. C'était suffisant pour valider l'utilité. Tout le reste est venu après les données, pas avant.

Le problème avec les équipes produit que j'observe, c'est qu'elles cherchent souvent à définir le produit complet avant de lancer le produit minimal. Le résultat : des cycles de développement de six mois pour valider quelque chose qu'on aurait pu tester en deux semaines.

2. La vitesse de décision est une compétence produit.

Quand je m'apprêtais à lancer la quatrième application, j'ai hésité sur un détail de design — la couleur des badges de progression. J'ai passé quarante minutes sur cette décision.

C'est quarante minutes sur une variable que l'utilisateur voit pendant deux secondes. Pendant ce temps, je n'avais pas encore défini le prix.

La plupart des réunions produit que j'ai observées dans des entreprises fonctionnent ainsi : beaucoup de temps sur les décisions visibles, peu de temps sur les décisions structurelles. Les deux ont des coûts très différents.

3. Les agents IA ne remplacent pas le jugement produit. Ils l'exposent.

Pour construire six apps en trois semaines, j'ai utilisé des agents autonomes pour générer le code, adapter le contenu, créer les interfaces. Ce n'est pas de la magie — c'est de la délégation structurée.

Mais déléguer à un agent IA, c'est devoir être précis sur ce qu'on veut. Vous ne pouvez pas dire "fais quelque chose de bien" — vous devez spécifier le comportement attendu, les contraintes, les critères de succès. C'est exactement ce qu'on appelle une spec produit.

Ce que j'ai découvert : la qualité de mon output IA était directement proportionnelle à la clarté de ma pensée produit. Là où je savais ce que je voulais, les agents livraient vite. Là où je n'avais pas encore décidé, ils produisaient du bruit que je devais trier.

L'IA n'a pas résolu mon ambiguïté. Elle l'a rendue visible immédiatement.

Ce que ça change pour la gestion de produit

Dans un monde où le temps de construction s'effondre, le goulot d'étranglement se déplace. Ce n'est plus "peut-on construire ça ?" mais "sommes-nous assez clairs pour décider ce qu'on construit ?".

Les Product Managers qui travaillaient essentiellement sur la coordination entre business et engineering vont devoir évoluer. Le vrai rôle devient : décider vite, avec peu d'information, et être suffisamment précis pour que l'exécution — humaine ou IA — puisse suivre sans friction constante.

C'est une compétence qui se forme dans la contrainte. Six apps en trois semaines, c'est six fois l'occasion de rater vite, corriger vite, et décider si la prochaine itération vaut le temps qu'elle coûte.

Je continue à développer ces applications. Et je continue à construire les systèmes d'agents qui me permettent de le faire.

Si ce sujet vous intéresse, suivez-moi sur LinkedIn — j'y publie régulièrement sur l'intersection entre systèmes opérationnels, produit, et IA.

→ linkedin.com/in/felipediazmarin