1 Il fallait le lancer
La peur du lancement
Au départ, je voulais le lancer tout cru. Je n'ai pas pu : à ce moment-là, mon actualité professionnelle m'est tombée dessus, plein d'autres choses en même temps. J'ai dû décaler la date. C'est assez classique — et sans Jamespot à côté, je l'aurais sans doute fait plus tôt. Quoique…
Quoique, parce qu'il y a toujours cette peur du lancement. Même moi — qui suis « guéri », qui ai lancé trois boîtes et une vingtaine de produits — même sur Deep, j'ai eu le petit pincement. Et je crois que c'est normal.
C'est comme le trac avant de monter sur scène, même quand on a déjà fait cent spectacles. Le trac ne dit pas que tu n'es pas prêt : il dit qu'il y a de l'enjeu.
2 Le pilote
Le premier bug
J'en ai parlé à mon codir chez Jamespot : « vous voulez être mes bêta-testeurs ? » Ils ont dit OK. Tout fier, je lance la semaine d'après.
Et évidemment… le premier bug. Les gens n'ont rien reçu. Un réglage d'envoi qui n'avait pas été branché — alors même que j'avais testé. C'est toujours pareil : au dernier moment, il y a le petit truc qui fait que ça ne marche pas.
Et ce petit truc prouve exactement ce que je répète : rien ne remplace un vrai test. On peut simuler avec des IA autant qu'on veut — à un moment, la seule question qui compte, c'est : est-ce qu'un vrai humain reçoit vraiment son mail ?
Je l'ai corrigé tout de suite. Ils ont été invités pour de bon. (Le détail technique — deux routes d'invitation dont une restée un stub jamais branché — est un cas d'école de la parité dev/prod.)
3 Julie
La boucle extérieure
Au sein du codir, tout de suite, Julie — la plus réceptive. Elle m'a trouvé des choses qu'elle ne comprenait pas, des écrans pas clairs. Elle m'a même envoyé un mail avec trois captures et trois retours : « je ne comprends pas le jargon là », « il me dit ça, mais ce n'est pas cohérent avec ça ».
Et là, ce qui a été vraiment super, c'est la boucle. J'ai créé une issue simplement en vocal — un copier-coller de son retour : « Julie a vu ça, elle ne comprend pas cet écran, propose. » J'ai passé ça à mon cycle IA complet — la méthode que je vous propose dans ce livre — et j'ai laissé tourner.
En un après-midi — calendaire, donc pas tant de temps que ça — mais surtout en totale autonomie, il m'a fait des propositions, corrigé, et c'est parti en prod tout seul.
C'est le moment où j'ai vu la boucle extérieure se fermer. Pas juste moi qui tourne en rond dans ma tête : un regard extérieur qui entre, et qui ressort en correction déployée.
4 Les Ops
La solitude quand ça tombe
Il y a eu ce moment où un service est tombé — et pendant quatorze heures, ça n'a pas marché. Sans que je le sache.
Parce que c'est ça, la vérité d'après-lancement : tant qu'on n'a pas de vrais utilisateurs, on ne sait pas si la prod tourne. Quand tu testes, tu vois. Mais une fois que tu as le dos tourné, la prod vit — ou meurt — à ton insu. C'est un autre moment, un autre métier.
Honnêtement, je n'ai pas trop paniqué : s'il s'était vraiment passé quelque chose, quelqu'un l'aurait remonté. Mais l'épisode prouve une chose — il faut durcir l'Ops. C'est ce qu'on a fait : rajouter du monitoring, pour être sûr que ça tourne, plutôt que de l'espérer.
5 Le paiement
Cassé, forcément
Le premier paiement, évidemment, était cassé lui aussi. La cause est bête et très parlante : on avait retouché les offres côté marketing, et le premier paiement ne passait plus parce qu'on avait supprimé l'offre rattachée à un bouton qu'on n'avait pas, lui, bougé. Comme d'habitude : il faut tout refaire, de bout en bout, pour que ça remarche.
Et c'est là qu'il faut être lucide : au bout d'un moment, un produit devient très, très gros. Il ne faut pas avoir peur qu'il y ait des choses qui ne tiennent pas de bout en bout — c'est mécanique. D'ailleurs, aujourd'hui, en post-lancement, je pense qu'il faudrait que je reprenne l'intégralité pour traquer les incohérences. Ça fait partie de ce que je veux encore faire sur DWG : des tests de cohérence long terme, pour éviter que l'édifice dérive.
6 Le recul
Ce que je referais autrement
Deux choses.
Des boucles encore plus courtes avec les utilisateurs. Comme toujours. Le vrai signal ne vient que d'eux, et je le sais depuis toujours — ça reste le réflexe le plus dur à tenir.
Ne pas trop complexifier le produit. Et là, attention, il y a un effet pervers de l'IA qu'il faut nommer : elle propose toujours quelque chose à la fin. « On pourrait aussi faire ça », « tu as pensé à… ? ». La moindre idée, on peut l'implémenter dans la seconde. Alors on la met dans le backlog, et encore une autre… et le backlog enfle, énorme — pendant qu'on n'a toujours pas mis le produit dans les mains des utilisateurs. Or c'est eux qui priorisent. Grand classique, aggravé par la puissance de l'IA.
Moi qui suis plutôt prolifique — je génère beaucoup de features, j'ai plein d'idées — je m'y suis heurté de plein fouet. Ma parade a été simple :
Se donner un temps. Un temps maximal, et ne pas le dépasser. Et si je devais recommencer, je me donnerais un temps encore plus court — ça aurait été bien mieux. La contrainte de temps n'est pas une punition : c'est ce qui force à sortir, donc à confronter au réel.
Après le lancement, il n'y a pas de ligne d'arrivée — il y a un point de départ. Le premier bug, le premier retour, la première panne, le premier paiement raté : ce ne sont pas des accidents, ce sont les rites de passage d'un produit qui rencontre enfin le réel. Le tout, c'est de les accueillir vite, en boucle courte, sans avoir peur.