L’IA a rendu le logiciel moins cher à construire. Pas à posséder.

J’ai envie de me construire une application pour perdre du poids

Je dois perdre du poids. Je connais la partie ennuyeuse : manger un peu moins, bouger davantage, rester honnête assez longtemps pour que les chiffres bougent.

Je pourrais payer dix euros par mois pour une application qui suit cela. À la place, je pense régulièrement à m’en construire une petite.

Pas pour économiser dix euros. Ce ne serait pas le cas. Je la construirais parce que j’aime fabriquer des choses. Parce que je pourrais faire un écran qui me convient vraiment : un endroit pour le poids, un journal alimentaire simple, une vue hebdomadaire qui ne cherche pas à transformer le petit-déjeuner en test de personnalité. Je pourrais avoir quelque chose qui fonctionne en un week-end.

Surtout, le risque d’échec est presque nul. Si elle casse, j’écris mes repas dans Notes pendant une semaine. Si j’arrête de la maintenir, rien d’important ne s’arrête. Aucun client n’attend. Personne ne manque sa paie. Il n’y a ni revue de sécurité, ni onboarding, ni reporting de fin de trimestre qui en dépendent.

C’est une bonne raison de construire quelque chose.

Ce n’est pas une raison suffisante pour qu’une entreprise construise son propre logiciel d’exploitation.

« On ne pourrait pas simplement faire un petit CRM ? »

Un client m’a posé cette question récemment. Il ne voulait pas Salesforce. Il n’avait pas besoin de toutes les fonctions de HubSpot. Il lui fallait des contacts, des affaires, des rappels, quelques rapports et de l’automatisation. « On ne pourrait pas simplement faire un petit CRM nous-mêmes ? »

La réponse honnête est : si, probablement. Une personne compétente, avec de bons outils, peut construire rapidement une première version respectable. L’IA a changé ce calcul. Un écran qui demandait des jours peut demander des heures. Un workflow qui exigeait un développeur peut commencer par un prompt, une base de données et quelques intégrations.

C’est un vrai progrès. Je l’utilise tous les jours.

Mais la question n’est pas de savoir si vous pouvez construire la version un. La question est de savoir ce que vous acceptez de posséder dès que cette version devient assez utile pour que des gens s’y fient.

Ce sont deux questions différentes. La seconde est généralement la plus chère.

L’IA a changé le coût du départ, pas celui de la possession

L’IA a fait baisser le prix de fabrication du logiciel. Elle n’a pas supprimé le travail qui commence quand le logiciel entre dans l’entreprise.

Un outil que vous êtes seul à utiliser peut rester un croquis utile. Dès que cinq personnes s’en servent pour faire tourner une partie de l’activité, il devient un système. Il faut donner les bons accès. Il faut comprendre ce qui se passe quand une automatisation se trompe. Il faut expliquer pourquoi un chiffre a changé. Il faut décider quoi faire quand le réel refuse de rentrer dans le scénario prévu.

Puis les demandes arrivent. Peut-on ajouter ce champ ? Peut-il aussi marcher pour l’Espagne ? Pourquoi cette fiche a-t-elle été dupliquée ? La finance peut-elle voir cela sans pouvoir le modifier ? Pourquoi le client n’a-t-il pas reçu l’email ? Peut-on le connecter au nouvel outil de devis ? Le nouveau commercial peut-il être formé avant lundi ?

Aucune de ces questions ne prouve que l’outil a été mal construit. Ce sont les questions qui apparaissent quand un outil utile rencontre une vraie entreprise.

Les éditeurs emploient des chefs de produit, des équipes support, des spécialistes sécurité, des équipes d’implémentation et des ingénieurs parce que ces questions ne cessent pas d’arriver. Vous ne les évitez pas en possédant l’outil. Vous les faites simplement entrer chez vous.

La facture n’est presque jamais le plus gros coût

Un logiciel interne a des coûts visibles : maintenance, bugs, sécurité, droits d’accès, documentation, intégrations, migrations, onboarding, évolution produit, support et continuité quand la personne qui l’a construit part.

La plupart des équipes les connaissent en théorie. Elles les sous-estiment quand même parce que la première version paraît si propre. La personne qui l’a faite connaît les raccourcis. Les données sont encore simples. Personne n’a demandé d’exception.

Puis un commercial change de territoire. Un client a deux entités juridiques. Quelqu’un veut un rapport qui compare ce trimestre au précédent. Une nouvelle source de données arrive. Une demande liée à la confidentialité tombe. La personne qui a construit l’outil est en vacances, occupée ou partie.

La facture n’est pas toujours spectaculaire. Elle arrive par morceaux : dix minutes ici, un vendredi après-midi là, une réunion qui devait porter sur les clients et devient une discussion sur les droits d’accès. C’est pour cela qu’on la voit mal.

Le plus gros coût n’est souvent pas le développement. C’est l’attention du management et de l’équipe.

Quand le système commercial devient le projet

C’est particulièrement vrai dans les équipes commerciales, parce que les outils de vente donnent très facilement l’impression d’avancer.

Une entreprise peut passer des semaines à améliorer la structure du CRM, les automatisations, les dashboards, le scoring des leads, le nettoyage des données et les workflows internes. Chaque tâche est concrète. Chaque tâche produit quelque chose de visible. Un pipeline plus propre procure la même satisfaction qu’un bureau rangé.

Pendant ce temps, le travail difficile reste là où il était. Les clients ne sont pas appelés. Les affaires bloquées ne sont pas regardées. La qualification reste floue. Les managers ne coachent pas. Les réunions de forecast parlent du chiffre plutôt que de l’affaire. Personne ne comprend pourquoi les opportunités n’avancent pas.

Le dashboard peut devenir plus précis sur un processus qui reste faible.

J’ai vu des équipes accuser le CRM pour des problèmes qui étaient en réalité des décisions commerciales que personne n’avait prises. Les étapes étaient floues parce que personne ne s’était accordé sur ce qu’est une affaire qualifiée. Le forecast était faux parce que les commerciaux n’avaient aucune raison de dire qu’une affaire glissait. Les relances étaient irrégulières parce que personne ne possédait la prochaine étape, pas parce qu’il manquait un champ.

Parfois, le CRM est vraiment mauvais. Le remplacer ou le personnaliser est alors exactement la bonne décision. Un outil peut rendre le bon travail plus facile et le mauvais travail plus difficile à cacher.

Mais les outils doivent résoudre un problème commercial clairement identifié. Ils ne doivent pas devenir le projet parce que les refaire paraît plus abordable que d’affronter le problème.

Le plus gros coût de vos outils commerciaux maison est souvent ce que l’équipe cesse de faire pendant qu’elle les construit.

Construisez pour un avantage précis, pas parce que le standard vous agace

Il existe de bonnes raisons de construire un logiciel interne. Votre processus peut être réellement singulier. L’outil peut être au cœur d’un service propriétaire. Il peut vous permettre de livrer quelque chose que les concurrents ne savent pas copier. Un produit mature peut ne résoudre que la moitié du besoin et forcer l’autre moitié à rester manuelle chaque jour.

Dans ces cas, construire peut être la décision la moins chère, précisément parce que cela enlève une contrainte opérationnelle réelle.

Mais l’agacement n’est pas une différence stratégique. Tous les logiciels SaaS matures ont des parties maladroites, surchargées ou conçues pour quelqu’un d’autre. C’est le prix d’un produit qui a survécu à des milliers d’entreprises aux habitudes différentes.

Si un produit couvre 80 % du besoin, les 20 % restants relèvent peut-être de la formation, du paramétrage ou d’un processus à simplifier. Ils sont peut-être aussi la partie qui compte le plus. L’enjeu est de savoir laquelle avant de commencer à construire.

Cinq questions avant d’ouvrir l’éditeur

Vous n’avez pas besoin d’une matrice pour cela. Posez cinq questions simples.

Est-ce stratégiquement différenciant ? Posséder cette capacité changera-t-il ce que les clients achètent chez nous, ou reconstruisons-nous une fonction standard parce que l’outil actuel nous agace ?

Que se passe-t-il si cela tombe en panne ? Si l’outil se trompe pendant une journée, l’équipe peut-elle contourner le problème ? Ou cela interrompt-il les ventes, la facturation, les accès, la conformité ou le service client ?

Existe-t-il déjà un produit mature qui couvre 80 % du besoin ? Pas un produit qui fait une belle démo. Un produit que vos équipes peuvent réellement utiliser, avec du support et des intégrations déjà disponibles.

Qui en est responsable dans six mois ? Nommez la personne, le budget et le temps. « La personne qui l’a construit » n’est pas un modèle de responsabilité.

Quel travail important ne faisons-nous pas pendant qu’on le construit ? Soyez précis. Quels clients ne seront pas appelés ? Quelles affaires ne seront pas revues ? Quels managers ne seront pas coachés ? Quelle décision attendra ?

La dernière question est celle que je poserais en premier. Construire peut donner l’impression d’être en mouvement tout en éloignant discrètement l’entreprise du travail qui fait rentrer l’argent.

Remettre l’outil à sa place

Je construirai probablement cette application pour perdre du poids. C’est un petit pari, proche de moi, agréable. Si cela devient un bazar, je peux la supprimer sans appeler personne.

Un CRM d’entreprise n’est pas cela. Ni le workflow de devis, la base clients, la stack finance ou l’outil qui décide qui relancer ensuite.

L’IA les rend tous plus faciles à construire. Elle ne fait pas disparaître leur coût de possession. Ce qui est amusant à construire n’est pas forcément intelligent à posséder pour toujours.

Si votre équipe arrêtait d’améliorer ses outils internes pendant un mois, quel problème client aurait-elle enfin le temps de résoudre ?