Une application que vos équipes utilisent,
pas un projet qui n’en finit pas.

On écrit avec vous la question que votre produit doit trancher. On coupe tout ce qui n’y répond pas. On conçoit les parcours, on construit en sur mesure, on met entre les mains de vrais utilisateurs. On regarde ce qu’ils font, pas ce qu’ils disent. Puis on vous transmet le tout.

Ce que vous obtenez : Un produit en ligne en quatre mois, utilisé par de vraies personnes avec de vraies données, et une réponse à la question qui compte : est-ce que ça mérite d’aller plus loin.

Ce que vous n’avez pas à faire : Rédiger un cahier des charges, choisir la plateforme, recruter avant d’avoir validé, ou engager un budget de développement sur une intuition.

Une première version n’est pas une version au rabais du produit final. C’est l’outil qui vous dit si le produit final mérite d’exister.

Nous construisons en sur mesure, sur Bubble ou FlutterFlow selon que votre produit vit dans un navigateur ou sur les stores. En quatre mois, vous avez une application que de vrais utilisateurs peuvent utiliser, avec de vraies données, et les indicateurs pour décider de la suite.

Ce que nous ne faisons pas : générer un prototype impressionnant qui ne tiendra pas trois mois. Notre approche que nous livrons a un modèle de données pensé, des droits gérés, et peut évoluer sans être refait.

La conséquence pratique est qu’une première version se juge sur ce qu’il vous apprend, pas sur ce qu’il contient. Une application qui fait tout ce que vous aviez imaginé et que personne n’utilise a coûté quatre mois pour ne rien démontrer. Une application qui fait une seule chose, utilisée trois fois par semaine par dix personnes, a déjà tranché la question qui comptait.

Le choix de l’outil se calcule plutôt qu’il ne se plaide. Nous avons détaillé cet arbitrage dans nos comparatifs, notamment Bolt ou Lovable pour les générateurs assistés par IA, et Framer ou Webflow quand le besoin est en réalité un site et non une application.

La plupart des projets qui échouent n’échouent pas à la construction. Ils échouent parce que personne n’avait écrit, avant de commencer, ce que le produit devait démontrer. On construit alors une version réduite de tout, au lieu d’une version complète de la seule chose qui compte.

La question à écrire avant la première maquette

Une première version répond à une question et une seule. Elle se formule toujours de la même façon : « des gens comme X vont-ils faire Y assez souvent pour que Z devienne viable ? » Tant que cette phrase n’est pas écrite avec de vrais noms, un vrai comportement et un vrai seuil, il n’y a pas de projet, il y a une intuition.

Nous consacrons la première étape à cela, et c’est presque toujours la partie la plus inconfortable du cadrage. Elle oblige à admettre que certaines fonctionnalités auxquelles on tient ne servent pas la démonstration, et donc qu’elles attendront.

Trois choses qu’une première version démontre réellement

• Que le problème existe assez fort pour que quelqu’un change son habitude actuelle. C’est le point le plus dur, et le plus souvent négligé : votre concurrent n’est pas un autre logiciel, c’est le tableur qui fonctionne déjà.
• Que le parcours tient debout sans vous. Si un utilisateur a besoin d’une démonstration pour comprendre, le produit n’est pas prêt, quel que soit son taux de satisfaction en réunion.
• Que l’usage se répète. Un produit essayé une fois par cent personnes vaut moins qu’un produit utilisé chaque semaine par dix.

Trois choses qu’il ne démontrera pas

Il ne dira rien de votre capacité à tenir la charge, puisqu’il n’y aura pas de charge. Il ne dira rien de votre coût d’acquisition à grande échelle, puisque les premiers utilisateurs viennent presque toujours de votre réseau. Et il ne validera pas un modèle de prix : accepter de payer et accepter de payer ce prix-là sont deux questions distinctes, et la seconde se teste plus tard, sur un volume plus large.

Nous le disons au cadrage plutôt qu’à la livraison, parce que c’est à ce moment que la connaissance change une décision. Une première version présenté à des investisseurs comme une preuve de scalabilité se retourne contre celui qui le présente.

Le périmètre écrit, et ce qu’il évite

À la fin du cadrage, vous avez une liste de ce qui sera construit et, surtout, une liste de ce qui ne le sera pas. La seconde est celle qui protège le projet. Sans elle, chaque semaine apporte une idée nouvelle, chacune raisonnable prise isolément, et le produit dérive jusqu’à ce que le budget s’épuise avant la mise en ligne.

Cette liste n’est pas un refus définitif. Elle est datée : ce qui n’entre pas dans la première version entre dans le lot suivant, et ce lot suivant se décide avec les données du premier, pas avec les hypothèses de départ.

La question arrive toujours trop tôt. Elle se tranche en dix minutes une fois que le périmètre est écrit, et elle prend des semaines quand on la pose avant.

Le critère qui décide vraiment

Votre produit vit-il dans un navigateur ou sur un téléphone ? Ce n’est pas une question de goût mais d’usage réel. Un outil manipulé assis devant un écran, avec des tableaux, des filtres et de la saisie longue, vit dans un navigateur. Un outil sorti de la poche sur un chantier, dans un couloir ou dans un camion, avec de la photo, de la géolocalisation et des notifications, vit sur un téléphone.

Beaucoup de projets veulent les deux. À l’étape de la première version, vouloir les deux est presque toujours la bonne façon de rater les deux : le budget se divise, et chaque version arrive à moitié aboutie. Nous demandons de choisir, en sachant que le second support n’est pas condamné, il est reporté.

Ce que chaque famille d’outils rend facile

• Le navigateur rend faciles les données reliées entre elles, les droits par rôle, les vues filtrées et l’export. C’est le terrain des outils métier internes et des places de marché.
• Le mobile natif rend faciles l’appareil photo, la position, le fonctionnement hors connexion et les notifications. C’est le terrain des applications de terrain et des usages grand public répétés.

Les générateurs assistés par IA, et leur place réelle

Ils produisent en quelques heures une interface crédible, et c’est un vrai gain pour montrer une direction. Leur limite apparaît dès qu’il faut faire évoluer ce qui a été généré : le modèle de données est souvent implicite, la logique dispersée, et la reprise coûte plus cher que la construction initiale n’a fait gagner.

Nous nous en servons donc là où ils sont bons, c’est-à-dire pour explorer vite avant de construire, et rarement comme socle de ce qui restera. Nous détaillons ce que chacun sait faire dans notre comparatif Bolt ou Lovable.

Ce que « sur mesure » veut dire chez nous

Notre approche n’a pas de qualité intrinsèque : il permet de bien construire aussi facilement que de mal construire, simplement plus vite dans les deux cas. Ce qui distingue un produit qui tiendra d’un produit qui sera à refaire tient à trois choses, et aucune n’est visible à l’écran.

Un modèle de données pensé avant la première page, parce que c’est lui qu’on ne peut plus corriger sans tout reprendre. Des droits gérés au niveau de la donnée et non de l’affichage, parce qu’un bouton caché n’est pas une protection. Et une nomenclature tenue, pour que la personne qui reprendra le produit dans un an comprenne ce qu’elle regarde.

Notre approche a un plafond. Le passer sous silence serait commode à la vente et coûteux à l’usage, donc nous le posons dès le cadrage.

Les quatre signaux qui annoncent le plafond

• Les temps d’affichage se dégradent sur les écrans qui manipulent beaucoup de lignes, et l’optimisation ne suffit plus.
• Une exigence de conformité impose une maîtrise de l’hébergement ou du chiffrement que la plateforme ne permet pas.
• Le coût de la plateforme, indexé sur l’usage, devient comparable au coût d’une équipe technique.
• La logique métier devient assez spécifique pour qu’on passe plus de temps à contourner l’outil qu’à s’en servir.

Aucun de ces signaux n’arrive pendant une première version. Ils arrivent au succès, ce qui est une bonne nouvelle : le plafond de nos socles de développement est un problème de croissance, pas un problème de démarrage.

La migration, quand elle se pose

Un produit ne se convertit pas automatiquement en produit développé. Ce qui se transfère, en revanche, est ce qui coûte le plus cher à produire : le modèle de données validé, les parcours éprouvés par de vrais utilisateurs, les règles métier écrites, et la connaissance de ce qui ne sert à rien. Une équipe technique qui démarre avec cela ne construit pas la même chose qu’une équipe qui démarre avec un cahier des charges.

C’est là que la première version prend sa valeur économique réelle : il ne remplace pas le développement, il en réduit fortement le risque. Refaire un produit dont on connaît l’usage est un projet cadré ; construire un produit dont on suppose l’usage est un pari.

Comment nous limitons la dépendance dès le départ

Les données doivent être exportables dans un format lisible, et nous le vérifions en début de projet et non le jour où la question se pose. La logique métier est documentée en français, en dehors de l’outil, pour qu’elle survive à la plateforme. Et les connexions avec vos autres logiciels passent par des mécanismes standards, ce qui les rend reproductibles ailleurs. Quand ces connexions deviennent nombreuses, elles relèvent d’ailleurs de l’automatisation des processus plus que du produit lui-même.

Une première version n’est pas un projet qu’on confie. C’est un projet qu’on mène à deux, et la charge côté client est la variable que personne n’annonce à la signature. Nous préférons l’écrire.

Ce que nous attendons de vous, concrètement

• Une personne qui décide, disponible une à deux heures par semaine, et qui a le mandat de trancher sans remonter la question ailleurs. C’est la condition la plus déterminante du respect du délai.
• L’accès à de vrais utilisateurs, ou à défaut à des personnes qui leur ressemblent vraiment. Sans eux, le produit se valide entre nous, ce qui ne valide rien.
• La connaissance du métier, que nous n’avons pas et n’aurons jamais aussi bien que vous. Les règles implicites, les exceptions, les cas particuliers qui ne sont écrits nulle part.
• Les contenus réels quand il y en a : un produit rempli de faux textes se teste mal, parce que les utilisateurs réagissent au fond autant qu’à la forme.

Ce que nous portons

La conception des parcours, la construction, le modèle de données, les droits, la mise en ligne, et la préparation des sessions de test. Nous portons aussi la fonction la plus ingrate du projet, qui consiste à défendre le périmètre écrit : rappeler, chaque fois qu’une idée nouvelle apparaît, qu’elle est peut-être bonne mais qu’elle n’est pas dans le lot en cours.

Le rythme, et pourquoi il est court

Nous travaillons par cycles de quinze jours, avec quelque chose de manipulable à la fin de chacun. Ce n’est pas une préférence de méthode, c’est une protection : un projet qui ne montre rien pendant deux mois n’a aucun moyen de savoir qu’il dérive, et découvre l’écart au moment où il coûte le plus cher à corriger.

Le corollaire est que vous verrez tôt des versions imparfaites. Une première version qui n’a pas l’air finie n’est pas un signal d’alarme, c’est le fonctionnement normal. Le signal d’alarme serait l’inverse.

Ce qui fait déraper les projets, dans notre expérience

Trois causes reviennent, et aucune n’est technique. Une décision qui attend une réunion qui n’est jamais planifiée. Un périmètre rouvert sans que le délai soit rouvert avec lui. Et des utilisateurs de test qu’on n’arrive jamais à mobiliser, si bien que le produit se juge sur des avis internes. Nous signalons ces trois situations dès qu’elles apparaissent, plutôt que de les absorber en silence jusqu’à la livraison.

Comparer deux devis de première version n’a aucun sens tant qu’on ne sait pas ce que chacun inclut. Voici notre découpage, pour que la comparaison soit possible.

Ce qui est toujours compris

• Le cadrage, c’est-à-dire l’écriture de la question à démontrer et du périmètre qui l’accompagne.
• La conception des parcours et des écrans, qui est le vrai poste de travail.
• La construction, le modèle de données et la gestion des droits.
• La mise en ligne, puis la prise en main par votre équipe et la documentation qui va avec.

Ce qui se chiffre à part, et pourquoi

Les abonnements aux plateformes, parce qu’ils sont à votre nom et dépendent de votre volume d’usage. L’acquisition des premiers utilisateurs, parce que c’est un métier distinct et souvent le vrai chemin critique. Les connexions à vos outils de gestion, parce qu’une intégration au CRM est un projet en soi et non une case à cocher.

Nous les sortons du forfait volontairement. Les y inclure permettrait d’afficher un prix plus rond, au prix d’un arbitrage que vous ne verriez pas passer.

Le lot suivant, qui n’est pas une rente

Après la mise en ligne, la suite se décide sur les données d’usage, pas sur la liste d’envies du départ. Nous préférons un lot court, chiffré sur un périmètre écrit, à un forfait mensuel qui installe une dépendance sans engager sur un résultat.