Outils internes vs applis clients : laquelle créer, et pourquoi ça change tout

Le même créateur d’applis avec IA peut générer une appli de réservation léchée pour vos clients photo, ou un remplaçant de tableur bancal mais adoré pour votre équipe des opérations. Vu de l’extérieur, ce sont tous les deux des « applis ». Vu de l’intérieur, ce sont des métiers complètement différents, et les traiter de la même façon est l’erreur la plus courante que je vois faire aux nouveaux créateurs.

La décision entre outils internes et applis clients ne porte pas sur l’apparence de l’appli. Elle porte sur qui tolère quoi, et sur ce qui se passe quand quelque chose casse. Trompez-vous là-dessus et vous passerez trois semaines à fignoler un bouton dont personne dans votre équipe n’avait rien à faire, pendant que vos vrais utilisateurs butent sur un bug qui les pousse à ne plus vous faire confiance.

Voici comment déterminer ce que vous êtes réellement en train de créer, et ce qui change une fois que vous le savez.

Le public décide presque tout

Un client, c’est quelqu’un qui vous a choisi. Il aurait pu prendre un concurrent. Il vous a payé, ou il s’est inscrit. Il vous jugera à l’aune de la chose la plus léchée qu’il ait jamais utilisée, même si votre appli coûte 9 $ par mois et la sienne 90 $. Il n’a aucune patience pour un libellé confus, un parcours de connexion bizarre ou un écran vide qui ne lui dit pas quoi faire.

Un collègue, c’est quelqu’un qui doit utiliser ce truc parce que son patron le lui a demandé. C’est aussi quelqu’un qui vous dira, dans un message Slack à 23 h, que le menu déroulant est dans le mauvais ordre. Il tolérera le moche. Il ne tolérera pas le lent, parce qu’il l’utilise quarante fois par jour.

Même créateur. Même ensemble de fonctionnalités, peut-être. Exigences radicalement différentes.

Quand vous vous asseyez devant un créateur d’applis avec IA pour décrire ce que vous voulez, la toute première question à vous poser est : qui est l’utilisateur, et a-t-il choisi d’être là ?

Outils internes : la rapidité l’emporte sur le fini

Les outils internes vivent et meurent par une seule chose : combien de temps font-ils gagner aux gens qui les utilisent ?

Une gestionnaire immobilière que je connais a passé deux soirées à construire un suivi de demandes de maintenance pour son équipe de trois personnes. C’est, selon tout critère objectif, moche. Les boutons sont incohérents. Il y a une faute de frappe dans la barre latérale que personne n’a pris la peine de corriger. Pas de logo.

Son équipe l’utilise plus que n’importe quel autre logiciel qu’elle possède. Ça leur a fait gagner à peu près cinq heures par semaine de messages Slack du type « est-ce que quelqu’un a déjà appelé le plombier pour le logement 4 ? » Le fini n’aurait ajouté zéro heure de valeur.

Trois traits que je vois dans les outils internes bien conçus :

  • Le plus court chemin entre « je veux faire X » et « X est fait » gagne. Sautez l’écran d’accueil. Sautez l’assistant. Ouvrez directement sur la chose.
  • Les cas limites peuvent être moches. Si un collègue tombe sur une erreur, il vous écrira sur Slack. Un client, lui, partirait tout simplement.
  • Les mises à jour arrivent quotidiennement, pas par versions. Vous ne livrez pas un produit. Vous bidouillez votre propre atelier.

Si vous construisez pour votre équipe, assumez à fond le « moche et utile ». Résistez à l’envie d’ajouter une page marketing, un écran de paramètres ou un bel écran vide. Rien de tout ça ne mérite sa place.

Applis clients : les bords ennuyeux, c’est ça le produit

Les applis clients sont essentiellement faites de bords. Le parcours de connexion. L’onboarding. Ce qui se passe quand une carte bancaire est refusée. L’e-mail envoyé lors d’une réinitialisation de mot de passe. L’écran que voit quelqu’un la première fois qu’il ouvre l’appli et qu’elle est encore vide.

Aucune de ces choses n’est la fonctionnalité qui vous a enthousiasmé. Toutes sont ce sur quoi votre client vous juge.

Un ami a lancé une petite appli de facturation l’an dernier. Il a passé son premier mois à construire l’éditeur de factures — la chose qui l’emballait. C’était magnifique. Puis il a tout activé, regardé un client tenter de s’inscrire, et découvert que :

  • L’e-mail de vérification atterrissait dans les spams.
  • Après la vérification, l’appli larguait l’utilisateur dans un tableau de bord vide, sans aucune indication.
  • Le bouton « créer votre première facture » était sous la ligne de flottaison sur un portable de 13 pouces.

Trois clients se sont inscrits cette semaine-là. Zéro a créé une facture. Le produit fonctionnait. L’emballage autour, non.

Pour les applis destinées aux clients, la règle grossière est : consacrez la moitié de vos efforts à la surface qui n’est pas la fonctionnalité principale. Onboarding, états d’erreur, parcours de paiement, paramètres de compte, e-mail de support. C’est ça, le produit, même si ça n’en a pas l’air.

Comment savoir laquelle vous êtes en train de créer

La décision entre outils internes et applis clients est plus simple qu’il n’y paraît dès qu’on se pose quelques questions de diagnostic :

Qui paie pour ça ? Si la réponse est « l’entreprise pour laquelle je travaille, au titre des frais généraux », c’est un outil interne. Si la réponse est « l’utilisateur, individuellement, avec sa carte bancaire », c’est une appli client. Le cas intermédiaire — votre patron paie, mais votre patron est un client — tire généralement vers les attentes d’une appli client.

Que se passe-t-il si elle tombe en panne pendant une heure ? Outil interne : quelqu’un est agacé. Appli client : quelqu’un part. Le rayon d’impact d’un bug est radicalement différent.

Combien d’utilisateurs aura-t-elle, au total ? De cinq à cinquante, c’est franchement interne. De cent à mille, ça commence à ressembler à un vrai produit. Cinq mille et au-delà, vous êtes une entreprise de logiciel, que vous l’ayez voulu ou non.

Les utilisateurs auront-ils le choix ? Les outils internes sont obligatoires. Les applis clients sont volontaires. Les utilisateurs volontaires partent dès que quelque chose les agace.

Si vous ne pouvez pas répondre clairement à ces questions, vous ne savez pas ce que vous construisez, et le créateur d’applis avec IA ne peut pas vous aider à converger.

Le piège caché : les outils qui deviennent des produits

C’est là que ça devient intéressant. Les produits indé les plus réussis que je connaisse ont commencé leur vie comme des outils internes. Quelqu’un a construit un truc pour son équipe, l’équipe l’a montré à un ami, l’ami en a voulu un, et voilà un client.

C’est une belle histoire. C’est aussi un moment de danger maximal, car dès l’instant où vous faites payer quelqu’un, la barre monte du jour au lendemain. La barre latérale moche que votre équipe tolérait devient un risque de désabonnement. La gestion d’erreurs « envoie un message Slack au développeur » devient un cauchemar de support.

Si vous franchissez ce pont avec un créateur d’applis avec IA, traitez-le comme une vraie transition. Passez une semaine — au moins une semaine — sur les bords ennuyeux. L’onboarding. Les états vides. Les cinq premières minutes après l’inscription. Des messages d’erreur qui s’expliquent d’eux-mêmes. Ne faites pas la promotion de l’outil avant que ce travail soit terminé.

La bonne nouvelle, c’est que les créateurs d’applis avec IA ont rendu cette transition moins coûteuse qu’autrefois. Le travail de fini qui prenait un mois avec un freelance, c’est désormais quelques bonnes sessions de prompts et un peu de patience.

La question à laisser mûrir

Toute la question des outils internes vs applis clients se résume à une seule consigne à vous donner avant de décrire une idée à un créateur d’applis avec IA : est-ce un outil que j’utilise, ou un produit que je propose ?

La réponse change le prompt. Elle change ce sur quoi vous passez du temps. Elle change ce que vous ignorez. Et c’est la clarté la plus utile que vous puissiez apporter à la construction.

Si vous hésitez encore sur le camp où vous vous trouvez, notre article sur ce que devrait être votre première appli créée avec l’IA est une bonne lecture complémentaire. La plupart des premières applis devraient être des outils. La plupart des deuxièmes aussi. Les clients viennent plus tard, et ils viennent plus facilement une fois que vous avez acquis le métier en construisant des choses que seule votre équipe devait endurer.