Une application n'est pas un projet, c'est un investissement. Elle sera encore là dans quatre ans, et quelqu'un devra la maintenir (peut-être pas moi). Cette seule contrainte élimine la moitié des choix techniques qu'on me propose.

Une bibliothèque sortie il y a six mois n'a pas encore rencontré ses cas limites. Sa communauté est petite, sa documentation partielle, et le jour où elle est abandonnée, vous découvrez le coût réel de la nouveauté : une réécriture non budgétée.

Je choisis donc des technologies éprouvées, largement adoptées, avec un éditeur solide derrière et un vivier de développeurs capables de reprendre le travail. Ce n'est pas de la frilosité : c'est la logique d'un architecte qui préfère un matériau dont on connaît le comportement à trente ans. L'innovation, je la mets dans le produit et dans la façon de le construire, pas dans le socle.

An application is not a project, it is an investment. It will still be running in four years, and someone will have to maintain it (possibly not me). That single constraint rules out half the technical choices put in front of me.

A library released six months ago has not yet met its edge cases. Its community is small, its documentation partial, and the day it is abandoned you discover the real cost of novelty: an unbudgeted rewrite.

So I choose proven, widely adopted technologies, with a solid organisation behind them and a pool of developers able to take over. This is not timidity: it is the reasoning of an architect who prefers a material whose thirty-year behaviour is known. I put the innovation into the product and into how it is built, not into the foundations.

J'édite mes propres applications depuis cinq ans. C'est un privilège rare pour un prestataire : je vois ce que devient un produit après la livraison, quand les tableaux de bord parlent à ma place.

Le premier enseignement est brutal : la quasi-totalité des utilisateurs que vous perdez, vous les perdez dans les soixante premières secondes. Pas au bout d'une semaine. Avant même d'avoir compris ce que fait l'application. Tout l'effort d'acquisition se joue donc sur un écran d'accueil que la plupart des projets traitent en fin de développement, quand le budget est épuisé.

Le second est plus contre-intuitif : ajouter des fonctionnalités fait souvent baisser la rétention. Chaque option supplémentaire est une décision de plus à prendre pour l'utilisateur, et une décision de plus est une occasion de fermer l'application. Les meilleures versions que j'ai publiées sont celles où j'ai retiré quelque chose.

C'est pour cela que, dans un cadrage, je passe autant de temps à défendre ce qu'on n'inclura pas qu'à décrire ce qu'on va construire.

I have published my own applications for five years. That is a rare privilege for a service provider: I get to see what becomes of a product after delivery, when the dashboards speak for me.

The first lesson is blunt: almost every user you lose, you lose in the first sixty seconds. Not after a week. Before they have even understood what the app does. All that acquisition effort therefore rests on a first screen most projects handle at the very end of development, when the budget is gone.

The second is more counter-intuitive: adding features often lowers retention. Every extra option is one more decision for the user, and one more decision is one more chance to close the app. The best releases I have shipped are the ones where I removed something.

This is why, during scoping, I spend as much time defending what we leave out as describing what we will build.

Qui doit revenir demain ? Pas « qui pourrait être intéressé », mais qui, précisément, ouvrira l'application une deuxième fois. Si la réponse tient en une phrase et désigne une personne réelle, le projet est cadrable. Sinon, il faut d'abord chercher cette personne, une page d'attente et une petite campagne coûtent quelques centaines d'euros et vous épargnent parfois un développement entier.

Qu'est-ce qui doit fonctionner le premier jour ? Un MVP n'est pas une version réduite du produit final. C'est le plus petit ensemble de fonctions qui rende un service complet à une personne. Tout le reste est un jalon, pas une exigence de lancement.

Combien coûte l'application quand elle ne rapporte rien ? Hébergement, comptes développeur, services tiers, maintenance. Un chiffre mensuel, connu avant de commencer. C'est la question qu'on pose le moins et celle qui tue le plus de projets à douze mois.

Une heure de discussion sur ces trois points a, presque toujours, plus d'effet sur le résultat final que trois semaines de développement.

Who has to come back tomorrow? Not “who might be interested”, but who exactly will open the app a second time. If the answer fits in one sentence and describes a real person, the project can be scoped. If not, find that person first, a waiting-list page and a small campaign cost a few hundred euros and sometimes save an entire build.

What has to work on day one? An MVP is not a reduced version of the final product. It is the smallest set of functions that delivers a complete service to one person. Everything else is a milestone, not a launch requirement.

What does the app cost when it earns nothing? Hosting, developer accounts, third-party services, maintenance. A monthly figure, known before starting. It is the least-asked question and the one that kills the most projects at the twelve-month mark.

One hour spent on these three points almost always changes the outcome more than three weeks of development.