Comment lancer une application : le guide du fondateur non technique

Un guide, du point de vue du fondateur, pour mettre un logiciel sur mesure en production : comment savoir quand une application est vraiment prête, les quatre décisions de lancement que vous seul pouvez prendre et ce qu’il faut surveiller pendant les 48 premières heures.

Une fondatrice avec qui nous avons travaillé a reçu le message que tout fondateur non technique attend : « C’est fini. Tout marche. » Elle a annoncé l’application sur LinkedIn cet après-midi-là, collé le lien de téléchargement et est partie dîner. Au moment du dessert, l’écran d’inscription renvoyait déjà une erreur à la moitié des gens qui le touchaient, et les e-mails de bienvenue avaient cessé de partir en silence. Le code était terminé. L’application n’était pas lancée.

Cet écart, c’est tout l’enjeu. Comment lancer une application, pour un fondateur non technique, c’est le travail de faire passer le produit de « l’équipe de développement dit que c’est fini » à « de vraies personnes l’utilisent en production et rien ne tombe ». Lancer est un événement d’ingénierie, pas une annonce marketing. L’annonce, c’est la partie facile. Presque tous les conseils que vous trouvez en ligne sautent directement à elle.

Terminé n’est pas lancé

Cherchez « comment lancer une application » et vous trouverez deux types d’articles. L’un est une checklist marketing : optimisez votre fiche sur le store, calez la presse, configurez vos tags d’attribution. L’autre est une plateforme no-code qui vous dit d’appuyer sur son bouton publier. Les deux traitent le lancement comme les derniers 5 % du marketing. Aucun ne parle de la partie qui casse vraiment.

Voici le recadrage à garder en tête : lancer une application est un événement d’ingénierie avant d’être un événement marketing. Le risque qui fait tomber les fondateurs le premier jour n’est presque jamais « pas assez de presse ». C’est la base de données jamais testée avec du trafic réel, le webhook de paiement qui échoue en silence, le parcours de réinitialisation du mot de passe que personne n’a cliqué parce que tous les testeurs avaient déjà un compte. Terminé veut dire que les fonctionnalités existent. Lancé veut dire qu’elles survivent au contact de gens qui ne les ont pas construites.

Pour un fondateur non technique, c’est inconfortable, parce que l’événement d’ingénierie est justement la partie pour laquelle vous vous sentez le moins armé. Alors vous déléguez tout et vous croisez les doigts. C’est l’erreur. Vous ne pouvez pas écrire le script de déploiement, mais vous pouvez être maître des décisions autour de lui, et ce sont ces décisions qui déterminent si votre lancement est une fête ou un incendie.

Avant de lancer : le test de préparation

Avoir toutes les fonctionnalités ne revient pas à être prêt. Un fondateur a besoin d’une façon de voir la différence sans lire de code. Le test que nous donnons aux fondateurs avec qui nous travaillons est simple : un inconnu pourrait-il utiliser le parcours principal, sur son propre téléphone, avec ses propres données, pendant que vous regardez sans rien dire ?

Cette dernière partie compte. Si vous devez vous pencher et expliquer, ce n’est pas prêt. Si la démo ne marche que sur le portable du développeur avec un compte de test préparé, ce n’est pas prêt. La confiance de l’équipe de développement n’est pas une preuve ; leur confiance est calibrée pour un environnement qu’ils maîtrisent.

Faites une répétition générale avant de lancer. Choisissez trois ou quatre personnes proches de vos vrais utilisateurs et qui n’ont jamais vu l’application. Donnez-leur un téléphone, une tâche réelle et le silence. Observez où elles bloquent. C’est différent de la validation que vous avez faite lors de la recette utilisateur, où vous vérifiez le build par rapport à la spécification. La répétition générale vérifie le build par rapport à un humain qui ignore que la spécification existe.

Certaines choses doivent être vraies avant de passer en production, et vous pouvez confirmer chacune sans être technique :

• Quelqu’un peut s’inscrire, faire la seule chose pour laquelle l’application existe et revenir demain pour retrouver ses données toujours là.
• Les paiements, si vous en prenez, ont été testés avec une vraie carte, pas une carte de test, et l’argent a vraiment bougé.
• Les critères d’acceptation que vous avez convenus pour les fonctionnalités du lancement passent tous, vérifiés par vous, pas décrits à vous.
• Vous savez ce qui se passe quand quelque chose échoue : l’utilisateur voit-il un message clair ou un écran blanc ?
• Si votre application va sur le store d’Apple ou de Google, elle a passé la revue. Lisez les directives de revue de l’App Store d’Apple avant de soumettre, car un rejet peut coûter une semaine que vous n’aviez pas prévue.

Si vous n’obtenez pas un passage propre sur ces points, vous n’avez pas encore de date de lancement. Vous avez un objectif.

Les quatre décisions de lancement que vous seul pouvez prendre

Vous n’allez pas déployer l’application. Mais quatre décisions sont les vôtres, et aucun développeur ne peut les prendre à votre place, parce que chacune porte sur l’entreprise, pas sur le code.

La décision « on y va ou pas ». À un moment, quelqu’un doit dire « on lance » ou « on attend ». Si vous la laissez à l’équipe de développement, la décision se prend par défaut à l’instant où le code est intégré, ce qui est exactement comment notre fondatrice a fini par annoncer une application cassée pendant le dîner. Mettez une conversation « on y va ou pas » à l’agenda, avec le test de préparation comme ordre du jour. Vous prenez la décision, à voix haute, un jour précis.

La décision de revenir en arrière, le rollback. Avant de lancer, posez une question : si ça tourne mal dans la première heure, comment on éteint ? Parfois la réponse est « on revient à la version précédente en deux minutes ». Parfois c’est « impossible, la nouvelle structure de la base de données est à sens unique ». Vous devez savoir dans quel monde vous êtes avant le lancement, pas pendant l’incendie. Un partenaire qui ne répond pas clairement à cela vous dit quelque chose.

Qui est d’astreinte, le on-call. Les vrais lancements cassent à des heures peu pratiques. Décidez, par écrit, qui surveille le système pendant les 48 premières heures et comment vous le joignez à 23h. « Tout le monde est dans le coin » n’est pas un plan. Une personne nommée, un numéro de téléphone, une plage convenue. C’est la partie « nuit blanche à déboguer », et c’est justement la partie que les arrangements bon marché laissent de côté en silence.

Le plan des premiers utilisateurs. Qui utilise l’application en premier, et combien ? La réponse ne devrait presque jamais être « tout le monde, d’un coup ». Ce qui nous amène à la partie que la plupart des fondateurs sautent.

Soft launch avant hard launch

Un hard launch, c’est la grande annonce : le post LinkedIn, la presse, l’e-mail à toute votre liste. Un soft launch, c’est laisser entrer d’abord un filet contrôlé de vrais utilisateurs, observer, corriger et seulement ensuite ouvrir les portes.

La raison de faire un soft launch n’est pas la prudence pour la prudence. C’est que vos premiers vrais utilisateurs trouveront des problèmes que vos testeurs n’ont jamais pu trouver, et vous voulez les trouver à un volume que vous pouvez réellement corriger. Vingt vrais utilisateurs qui sortent cinq bugs, c’est un mardi ordinaire. Deux mille utilisateurs qui sortent les mêmes cinq bugs, c’est un problème de réputation et une file de support que vous ne pouvez pas vider.

Une séquence qui marche : ouvrez à une poignée d’utilisateurs bienveillants qui pardonneront les aspérités et vous diront la vérité. Puis à un groupe un peu plus large qui ne vous connaît pas. Observez chaque groupe pendant deux jours. Si le parcours principal tient et que les chiffres sont cohérents, élargissez encore. Votre hard launch arrive quand vous avez déjà vu de vrais inconnus utiliser la chose sans qu’elle tombe. À ce stade, l’annonce est une formalité, et c’est exactement ce que ça doit être. Le lancement a déjà eu lieu, en silence, et il a tenu.

C’est aussi la réponse honnête aux fondateurs qui pensent que lancer, c’est un seul jour dramatique. Les bons lancements auxquels nous avons participé étaient ennuyeux vus de l’extérieur. Le drame, quand il y en avait, s’était produit deux semaines plus tôt avec douze utilisateurs et avait été réglé avant que quiconque ne regarde.

Les 48 premières heures : ce qu’il faut surveiller

Avec de vrais utilisateurs à l’intérieur, votre travail passe de décider à observer. Vous n’avez pas besoin d’un tableau de bord plein de métriques de vanité. Vous avez besoin de savoir, presque en temps réel, si la chose fonctionne. Trois questions couvrent l’essentiel.

Les gens entrent-ils ? Les inscriptions qui commencent et ne finissent pas sont le signal précoce le plus bruyant qu’un élément du tunnel a cassé. Font-ils la seule chose ? Si les utilisateurs arrivent et n’atteignent jamais l’action principale, soit elle est cachée, soit elle est cassée. Et quelque chose brûle-t-il en coulisses ? Erreurs, paiements échoués, e-mails non partis. Votre équipe de développement peut poser une alerte simple pour qu’un humain apprenne les pannes avant qu’un utilisateur ne râle sur Twitter.

Convenez avant le lancement de ce qui est surveillé et de qui surveille. Le fondateur n’a pas besoin de lire les logs. Le fondateur a besoin de savoir que quelqu’un les lit, et que ce quelqu’un appellera.

Qui appuie vraiment sur le bouton

Si vous n’êtes pas technique, la question honnête sous tout cela est : qui déploie mon application, et à quel point dois-je faire confiance à cette personne ? Vous n’allez pas lancer la mise en production vous-même. C’est très bien. Beaucoup de fondateurs sérieux ne touchent jamais au déploiement. Ce que vous ne pouvez pas faire, c’est tout traiter comme une boîte noire et découvrir qui était responsable seulement après la casse.

Les partenaires technologiques ne devraient pas être des boîtes noires. Le studio ou le développeur qui met votre application en production devrait pouvoir vous dire, en langage clair, ce qu’implique le lancement, comment ils sauront que ça a marché, comment ils feraient marche arrière et qui est éveillé si ça casse. Si ces réponses reviennent floues, le flou est l’avertissement. L’équipe qui accueille bien une conversation « on y va ou pas » et qui a déjà un plan de retour arrière prêt est l’équipe qui vaut la peine d’être gardée. Le travail du jour du lancement est réel, concret, et parfois il a lieu à 2h du matin. Le bon partenaire le sait déjà et l’a déjà prévu.

Ce que vous lancez, au fond, c’est la plus petite version du produit que vous seriez fier de mettre devant un client qui paie. Lancez-le comme si ça comptait, parce que la première impression est celle que vous ne récupérez pas. Ensuite observez, corrigez ce que le monde réel trouve et laissez l’annonce être le tour d’honneur discret qu’elle doit être.

Foire aux questions

Combien coûte le lancement d’une application ?
Les frais des stores sont faibles : Apple facture un abonnement développeur annuel et Google des frais uniques. Le vrai coût du lancement n’est pas la fiche sur le store, c’est la préparation et l’astreinte : la répétition générale, la correction de bugs dans la fenêtre du soft launch et quelqu’un qui surveille le système les premiers jours. Prévoyez du budget pour le travail autour du go-live, pas seulement pour le build. Notre décryptage de combien coûte le développement d’une application montre où va cet argent.

Puis-je lancer une application gratuitement ?
Vous pouvez publier sur le web pour presque rien, et les frais des stores sont modestes. Mais « gratuit » signifie en général que personne n’est d’astreinte quand ça casse et que personne n’a fait une vraie répétition générale. Ce n’est pas un lancement, c’est un pari. Le coût qui compte, c’est l’attention pendant les 48 premières heures, et l’attention n’est pas gratuite.

Quelle est la différence entre un soft launch et un hard launch ?
Un soft launch laisse entrer d’abord un groupe contrôlé de vrais utilisateurs pour que vous trouviez et corrigiez les problèmes en silence. Un hard launch est l’annonce publique à tout le monde. Soft launch d’abord, toujours. Le hard launch devrait sembler anticlimatique, parce que le vrai lancement a déjà eu lieu et a tenu.

Qui déploie mon application si je ne suis pas technique ?
Votre développeur ou votre studio le fait. Vous n’avez pas besoin de lancer la mise en production, mais vous devez savoir qui est responsable, comment ils confirmeront que ça a marché et comment ils feraient marche arrière. Si votre partenaire ne peut pas expliquer le lancement en langage clair, c’est un problème à régler avant le go-live, pas après.

Comment savoir si mon application est vraiment prête à être lancée ?
Faites le test de préparation : un inconnu proche de vos vrais utilisateurs complète le parcours principal sur son propre téléphone, avec ses propres données, pendant que vous regardez sans rien dire. S’il y arrive sans votre aide et que ses données sont toujours là le lendemain, vous êtes proche. Il est aussi utile de confirmer que le lancement est le bon produit minimum viable et que vos critères d’acceptation et la recette utilisateur ont tous passé avant de fixer une date.