Le mois où louer devient plus cher que construire

Les deux formules précédentes louent : elles louent de l’attention à des plateformes, mois après mois, et le jour où la facture s’arrête, l’attention s’arrête avec elle. C’est un arrangement parfaitement rationnel pendant un certain temps, et il cesse de l’être à un moment identifiable.

Ce moment n’est pas une taille d’entreprise ni un chiffre d’affaires. C’est le point où la même somme, dépensée une fois dans quelque chose que vous possédez, produit plus que dépensée tous les mois dans quelque chose que vous louez. Une boutique qui encaisse, un tunnel de commande qui ne perd plus personne, un paiement par carte qui fonctionne : ces choses se paient une fois et travaillent ensuite gratuitement.

Le piège est de croire que ce moment arrive tôt. Il arrive après que l’offre a été prouvée, pas avant — et une entreprise qui construit avant d’avoir prouvé fabrique très proprement quelque chose dont personne ne veut. C’est l’erreur la plus chère de tout le catalogue, parce qu’elle immobilise à la fois de l’argent et six mois.

Cet article décrit comment reconnaître le point de bascule, ce qu’un mois de développement coûte réellement, ce que le paiement par carte est devenu en Algérie, pourquoi le dossier bancaire est un délai plutôt qu’une fonctionnalité, et ce que vous devez posséder à la fin.

La bonne unité pour juger un projet n’est pas le dinar, c’est le mois de publicité que le même dinar aurait acheté. Ce cadrage change la plupart des arbitrages, et il les change dans les deux sens.

Il rend certaines fonctionnalités évidemment absurdes. Une option de personnalisation qui coûte l’équivalent de trois mois de campagne, sur une boutique qui reçoit deux cents visiteurs par jour, ne se rentabilisera pas avant des années — et sera probablement refaite avant.

Il en rend d’autres évidemment obligatoires. Un tunnel de commande qui perd la moitié des acheteurs à l’étape du paiement coûte, chaque mois, plus que sa correction ne coûterait une fois. Ce calcul se fait avec vos chiffres à vous et prend une demi-heure ; il n’exige aucune expertise technique.

C’est aussi le cadrage qui permet de dire non à ce que nous vendons. Quand un client demande une application mobile alors que son site n’a pas de page produit correcte, l’équivalent en mois de campagne rend la conversation courte et impersonnelle — ce qui est exactement ce qu’il faut pour une décision de cette taille.

Accepter la carte sur un site suppose deux choses très différentes : une intégration technique, qui est du travail ordinaire et prévisible, et un dossier auprès des institutions, qui n’est ni l’un ni l’autre.

Nous ne publions pas de délai moyen pour ce dossier, et c’est un refus délibéré. Chaque dossier avance à sa vitesse, aucune institution ne publie de statistique d’instruction, et les seuls chiffres en circulation sont des affirmations d’agences sur leurs propres dossiers passés. Citer les nôtres reviendrait à présenter une expérience non vérifiable comme une donnée ; citer ceux d’un concurrent serait pire.

Ce qui se dit honnêtement est la forme du délai plutôt que sa durée. Il ne dépend pas de la complexité de votre site, il ne s’accélère pas en payant davantage, et il commence lorsque le dossier est complet — pas lorsqu’il est déposé. La seule variable que vous contrôlez est donc la complétude au premier envoi.

La conséquence pratique gouverne tout le planning : le dossier se lance en premier, avant le développement, parce qu’il est le seul élément du projet dont la durée ne dépend pas de nous. Un site terminé qui attend son dossier est un site qui ne vend pas, et c’est une attente entièrement évitable.

La demande d’application mobile arrive presque toujours à ce niveau, et elle mérite une question avant un devis : qu’est-ce que l’application fera que le site ne peut pas faire ?

Il existe de vraies réponses. Une notification que le client accepte de recevoir, un usage hors connexion, un accès matériel — appareil photo, position, lecteur de code. Ces trois cas justifient une application, et rien d’autre ne la justifie aussi clairement.

Il existe aussi une fausse réponse très répandue : « pour être sur le téléphone du client ». Vous y êtes déjà, dans son navigateur, sans qu’il ait à installer quoi que ce soit, à accorder des permissions, ni à trouver de la place. Chacune de ces trois étapes écarte une partie des gens, et pour une première visite elles les écartent presque tous.

La règle que nous appliquons : une application se construit pour les clients qui reviennent, jamais pour ceux qu’on cherche à acquérir. Si le problème est d’être trouvé, l’application est la réponse la plus chère à une question qu’elle ne traite pas.

À ce niveau nous construisons — site, boutique, application, intégration du paiement — pendant que l’acquisition continue de tourner, et nous coordonnons les deux calendriers pour qu’ils ne se détruisent pas l’un l’autre. Le dossier bancaire part en premier, le catalogue démarre en parallèle, et la bascule se fait en une fois.

Ce que nous refusons est net : nous ne commençons pas un chantier tant que les chiffres d’acquisition disent que l’offre n’est pas prouvée. Si une campagne correctement menée n’a pas produit de demandes à un coût soutenable, une boutique ne réglera rien — elle rendra simplement le même problème plus cher et plus lent à corriger.

Nous refusons aussi d’annoncer une date de mise en service qui dépend d’un dossier bancaire. Nous donnons deux dates : celle où le site sera prêt, qui nous engage, et celle où le paiement fonctionnera, qui ne dépend pas de nous et que nous ne promettons donc pas.

Enfin, nous ne construisons pas d’application mobile pour un besoin qu’un site remplit. Cela nous coûte le devis le plus élevé du catalogue et c’est le seul conseil défendable : une application développée pour acquérir des clients qu’on n’a pas encore est un projet payé deux fois, une fois pour être construit et une fois pour être abandonné.