Qui doit réussir à s'en servir sans vous ? La réponse décide de tout
Quand un dirigeant nous appelle pour parler d'un logiciel, notre première question n'est jamais technique : nous demandons qui devra réussir à s'en servir sans que personne ne soit là pour l'aider. La réponse coupe le sujet en deux. Un outil interne s'adresse à un public captif, quinze ou trente personnes que vous pouvez réunir dans une salle un mardi matin, former en quarante-cinq minutes, et qui reviendront de toute façon le lendemain parce que c'est leur métier. Un produit vendu par abonnement s'adresse à un inconnu qui ne vous rencontrera jamais, qui vous a trouvé par une recherche, et qui referme l'onglet sans prévenir dès qu'il ne comprend pas ce qu'il a devant les yeux.
Posons le vocabulaire tout de suite, parce que dans ce métier les mots servent trop souvent à impressionner plutôt qu'à expliquer. Un produit SaaS est un logiciel que d'autres entreprises paient par abonnement, mois après mois, et qu'elles utilisent depuis leur navigateur sans rien installer. Un outil interne est un logiciel que seuls vos propres salariés ouvrent, que vous payez une fois et que vous entretenez ensuite. Quant au multi-locataire, ce terme qui apparaît dans les devis sans jamais être traduit, il désigne simplement la capacité d'un même système à héberger côte à côte plusieurs entreprises clientes, chacune enfermée chez elle, sans qu'aucune ne puisse apercevoir les données d'une autre.
Cette différence de public redessine ensuite chaque écran. Un outil interne a le droit de supposer beaucoup de choses : il peut afficher un tableau dense de vingt colonnes, employer vos abréviations maison, et compter sur le collègue d'à côté pour expliquer la case étrange en bas de page. Un produit doit s'expliquer tout seul dès le premier écran, parce qu'il n'y a ni collègue, ni formation, ni deuxième chance, et parce qu'un essai gratuit mal compris ne se plaint pas : il s'éteint sans bruit et vous n'en connaîtrez jamais la raison.
Ce qui suit n'est donc pas une comparaison de fonctionnalités, c'est l'arithmétique que nous posons réellement avec nos clients avant de signer quoi que ce soit. À la fin de cette page, vous pourrez chiffrer les deux chemins sur une feuille de papier et dire honnêtement lequel des deux vous êtes en train de financer.
Les mêmes écrans, deux chantiers très différents
Posez côte à côte le besoin d'un outil interne et celui d'un produit vendable : la partie visible se ressemble beaucoup, ce qui explique pourquoi tant de gens croient qu'il s'agit du même travail. Dans les deux cas, il faut construire la même fondation.
- Les écrans de travail eux-mêmes, c'est-à-dire la saisie, les listes, les fiches et la recherche.
- La base de données qui range l'information proprement et sait encore la retrouver dans trois ans.
- Les rapports, les exports et les quelques chiffres que la direction regarde le lundi matin.
- Les droits par rôle, pour qu'un stagiaire ne voie pas ce que voit la comptable.
La différence se situe ailleurs, dans tout ce qui doit exister avant qu'un seul client puisse payer une seule fois.
- L'inscription en autonomie, sans que personne chez vous n'ouvre le compte à la main.
- Les formules, les essais gratuits et le passage d'une formule à l'autre en cours de mois.
- Le paiement par carte, les factures, la TVA, et les relances quand une carte expire.
- Les réglages propres à chaque entreprise cliente, de son logo à ses propres règles de gestion.
- Une console d'administration pour votre équipe, afin de prolonger un essai ou de dépanner un compte sans toucher à la base.
- Une page d'état du service, pour dire publiquement ce qui se passe le jour où quelque chose tombe.
- Une documentation d'aide, des remboursements et des résiliations propres.
- Des e-mails automatiques qui arrivent vraiment, et non dans le dossier des indésirables.
Sur nos propres livraisons chez Linkysoft, pour dix heures passées sur les écrans métier, il en faut quatre à six de plus pour cette couche vendable, c'est-à-dire des semaines entières de travail dont aucun outil interne n'a jamais besoin. C'est toute l'explication du mystère qui revient sans cesse en réunion : deux prestataires lisent la même liste de fonctionnalités et annoncent deux prix qui n'ont rien à voir, parce que l'un chiffre une application métier construite sur mesure pendant que l'autre chiffre un produit que des inconnus pourront acheter tout seuls.
Le graphique ci-dessous montre où part concrètement ce supplément.
Le multi-locataire, expliqué sans jargon
Imaginez un immeuble. Un seul bâtiment, une entrée commune, des compteurs communs, mais des lots fermés à clé et un jeu de clés différent pour chaque locataire. Personne n'entre chez le voisin, chacun décore chez soi, et le gardien, lui, peut ouvrir toutes les portes, ce qui explique qu'on ne confie ce trousseau qu'à quelqu'un en qui on a une confiance totale. Un logiciel multi-locataire fonctionne exactement ainsi : un seul programme, une seule mise à jour pour tout le monde le mardi soir, et chaque entreprise cliente qui vit dans son lot sans jamais voir le couloir des autres.
Techniquement, il existe deux façons de bâtir cet immeuble. Soit une base de données partagée où chaque ligne porte une étiquette indiquant à quel client elle appartient, ce qui coûte moins cher à faire tourner et convient très bien quand vous visez beaucoup de petits clients. Soit une base de données séparée par client, plus lourde à exploiter et à mettre à jour, mais qui rassure les grands comptes et simplifie les demandes de restitution ou d'effacement, donc plutôt adaptée quand vous visez peu de clients mais des clients importants.
Pourquoi un dirigeant sans bagage technique devrait-il s'intéresser à ce détail ? Parce qu'il change la nature de vos mauvaises journées. Un défaut dans un outil interne dérange une seule entreprise, la vôtre, et vous pouvez téléphoner aux dix personnes concernées pour leur demander de patienter jusqu'à demain. Le même défaut dans un produit atteint tous vos clients à la même minute, sans que vous ayez le temps de prévenir qui que ce soit, et une erreur sur ces fameuses étiquettes ne produit pas un bug ordinaire : elle montre les données d'une entreprise à une autre, ce qui n'est plus un incident technique mais un courrier à écrire à des avocats.
Retenez surtout ceci, car nous y reviendrons à la fin : la séparation des clients est la chose la plus difficile à ajouter après coup. Presque tout le reste se rattrape en cours de route, celle-là se paie très cher quand elle a été oubliée au départ.
Deux budgets côte à côte, avec l'arithmétique posée
Commençons par l'outil interne, sans arrondir vers le bas pour faire plaisir. Une première version réellement utilisable, qui couvre un processus de bout en bout pour une équipe de dix à quarante personnes, demande en général six à dix semaines et se situe entre 12 000 et 45 000 dollars. Cette fourchette comprend le cadrage, les écrans, la base de données, les droits, la reprise des données qui dorment aujourd'hui dans vos fichiers, la formation de l'équipe et les corrections des premières semaines d'usage réel, c'est-à-dire tout ce qu'il faut pour que l'ancien tableur cesse d'être ouvert.
Reconstruisez très exactement le même périmètre pour que des inconnus puissent l'acheter et la couche vendable ajoute 40 à 60 % par-dessus le noyau : le même processus ressort donc entre 17 000 et 72 000 dollars environ. L'écart ne vient pas d'une soudaine gourmandise du prestataire, il vient du fait que l'inscription, les formules, la facturation, la séparation des clients, la prise en main, la documentation et la disponibilité doivent exister avant le premier paiement, et non après.
Presque personne ne s'arrête là, parce qu'un inconnu achète un métier entier et non une étape isolée. La première version que nous chiffrons comme un produit vendable couvre donc bien plus de terrain que l'outil interne, demande cinq à neuf mois et se situe entre 60 000 et 140 000 dollars. L'opération, elle, reste la même quel que soit votre point de départ : prenez le coût des écrans métier, ajoutez 40 à 60 % pour la couche vendable, et un noyau facturé 45 000 dollars se retrouve entre 63 000 et 72 000 dollars dès lors qu'il doit se vendre tout seul. Si un devis ne fait apparaître cet écart nulle part, c'est qu'il n'a pas été chiffré comme un produit.
Méfiez-vous enfin des devis trop aimables. Quand un produit destiné à la vente est annoncé à 15 000 dollars, ce n'est presque jamais une bonne affaire : cela signifie que la facturation, l'inscription en autonomie et la séparation des données ne sont tout simplement pas dans le périmètre, si bien que la deuxième facture arrivera au moment précis où vous aurez enfin un client à servir. Nos autres articles consacrés aux tarifs détaillent poste par poste ce qui se cache derrière chaque ligne d'un devis logiciel.
Combien de temps avant que de vraies personnes s'en servent
Le mot « terminé » ne veut pas dire la même chose des deux côtés, et c'est souvent là que naissent les malentendus. Un outil interne est terminé le jour où l'équipe cesse d'ouvrir l'ancien tableur, point final. Un produit est terminé le jour où un inconnu vous trouve, s'inscrit, paie et obtient un résultat utile sans que personne de votre côté n'ait eu à intervenir, ce qui est une barre nettement plus haute que d'avoir un joli tableau de bord.
La forme du calendrier reste assez stable d'un projet à l'autre : six à dix semaines pour atteindre un premier usage interne réel, puis trois à six mois de plus pour la couche vendable, puis une véritable phase d'essai avec cinq à quinze clients bienveillants avant d'afficher publiquement un tarif. Ces clients d'essai ne sont pas une formalité, ils sont la seule source honnête d'information sur ce qui manque, et ils coûtent infiniment moins cher qu'une reconstruction après un lancement raté.
Même quand l'objectif final est de vendre, nous recommandons presque toujours de commencer par une version étroite mise entre les mains d'une seule équipe réelle, la vôtre ou celle d'un client complice. Deux semaines d'usage sincère réécrivent le plan plus honnêtement que n'importe quel atelier de trois jours, parce que les gens y montrent ce qu'ils font vraiment au lieu de raconter ce qu'ils croient faire.
Quant aux retards, ils tombent rarement là où on les attend. Ce ne sont presque jamais les écrans principaux qui débordent, ce sont la reprise des anciennes données, toujours plus sales que promis, les cas particuliers de droits d'accès, et la première tentative de facturation, qui découvre en chemin les remboursements partiels, les changements de formule en milieu de mois et les cartes refusées.
Les factures qui commencent le lendemain de la mise en ligne
Un logiciel n'est pas un achat, c'est un abonnement que vous vous payez à vous-même. Un outil interne utilisé par trente personnes coûte le plus souvent 40 à 150 dollars par mois d'hébergement, ce qui surprend agréablement les dirigeants habitués aux licences. Un produit qui sert environ 500 clients payants se situe plutôt entre 400 et 1 500 dollars par mois une fois comptés les sauvegardes, la supervision qui vous réveille avant vos clients, et les e-mails automatiques envoyés par un service spécialisé pour qu'ils arrivent à destination.
À cela s'ajoute la règle que nous appliquons dans tous nos budgets : 15 à 25 % du coût de construction chaque année, uniquement pour que le logiciel continue de fonctionner pendant que les navigateurs évoluent, que les bibliothèques, c'est-à-dire les briques de code toutes faites sur lesquelles votre logiciel s'appuie, publient leurs correctifs de sécurité, et que les prestataires de paiement changent leurs règles sous lui. Un produit construit pour 90 000 dollars porte donc 13 500 à 22 500 dollars de maintenance annuelle avant la moindre nouveauté, et une ligne budgétaire absente ne fait pas disparaître la dépense, elle la transforme simplement en panne.
Les frais de paiement méritent eux aussi leur calcul, parce qu'ils passent souvent à la trappe. À environ 2,9 % plus 0,30 dollar par encaissement, un abonnement à 29 dollars vous laisse à peu près 27,86 dollars. Multipliez par mille abonnements actifs et vous abandonnez de l'ordre de 1 140 dollars par mois au prestataire de paiement, avant même d'avoir réglé l'hébergement, et cette somme grandit exactement au rythme de votre succès.
Parlons enfin de disponibilité en minutes plutôt qu'en décimales, c'est bien plus parlant. Une garantie de 99,9 % autorise environ 43 minutes d'interruption par mois. Pour un outil interne, une coupure à deux heures du matin ne coûte rien puisque tout le monde dort. Pour un produit, la même coupure tombe en pleine journée de travail chez un client situé à cinq fuseaux horaires de chez vous, et elle se paie en résiliations.
Support, prise en main et documentation : le service que personne ne budgète
La première année, nous observons entre 0,3 et 0,8 message de support par client payant et par mois. Faites l'opération avec 300 clients : cela donne 90 à 240 messages par mois, soit 15 à 40 heures du temps de quelqu'un, chaque mois, sans interruption. Ce n'est plus une tâche que l'on glisse entre deux réunions, c'est un poste de travail, et il faut décider dès maintenant qui répond à neuf heures du matin quand un client n'arrive pas à se connecter.
La prise en main obéit à la même asymétrie. Un outil interne se transmet en une session de quarante-cinq minutes, avec un collègue disponible pour la question qui viendra le lendemain. Un produit dispose d'une dizaine de minutes pour s'enseigner lui-même, et nous constatons régulièrement qu'un premier parcours clair rapporte plus d'abonnements qu'une fonctionnalité supplémentaire, puisque la fonctionnalité ne sert que ceux qui sont restés. C'est pourquoi l'accompagnement des premiers jours mérite autant de soin que le reste du produit.
La documentation se chiffre également : un petit produit demande en général 20 à 40 pages d'aide tenues à jour, plus des notes de version à chaque changement visible. Une aide périmée génère davantage de tickets qu'une absence d'aide, parce que le client suit vos instructions à la lettre, obtient autre chose que ce qui est écrit, et vous écrit alors deux fois plutôt qu'une.
C'est précisément l'endroit où un assistant capable de répondre aux questions répétitives fait gagner du temps, à condition qu'il s'appuie sur votre documentation réelle et qu'il passe la main dès qu'il ne sait pas, ce que nous mettons en place dans nos projets d'assistants et systèmes intelligents. Gardez aussi en tête que le site public qui vend le produit est un projet à part entière, avec ses pages de tarifs, ses démonstrations et ses preuves, et qu'il relève de la conception et du développement de sites web plus que du logiciel lui-même.
Est-ce que cela se rembourse ? Le seuil de rentabilité au crayon
Prenons le produit et avançons lentement. Vous avez investi 90 000 dollars de construction et vous vendez 45 dollars par mois. Après les frais de paiement, l'hébergement et le support, il vous reste environ 70 % de chaque abonnement, soit 31,50 dollars par client et par mois. Divisez 90 000 par 31,50 : il vous faut à peu près 2 860 mois-clients pour rentrer dans vos frais, ce qui se lit soit comme 240 clients conservés pendant un an, soit comme 120 clients conservés pendant deux ans.
Ajoutez maintenant les départs, parce qu'ils sont la variable que les prévisions oublient toujours. Sur les logiciels destinés aux petites entreprises, les résiliations tournent couramment entre 3 et 6 % par mois. À 5 %, vous renouvelez l'intégralité de votre portefeuille en une vingtaine de mois, ce qui signifie que vendre ne s'arrête jamais : il faut recruter des clients simplement pour rester au même niveau. Le budget d'acquisition n'est donc pas une variable d'ajustement mais un second budget à part entière, et le marketing digital décide du sort d'un produit au moins autant que la qualité du code, puisque nous voyons beaucoup plus de produits mourir faute de distribution que faute de logiciel.
L'outil interne se juge avec la même honnêteté, seule l'unité de compte change. Douze salariés qui gagnent trois heures par semaine, cela fait trente-six heures par semaine, et sur les quarante-six semaines réellement travaillées une fois les congés retirés, cela représente environ 1 650 heures par an, soit à peu près 33 000 dollars à 20 dollars de l'heure. Un outil construit pour 30 000 dollars se rembourse donc en un peu moins d'un an, à une condition que personne n'aime formuler à voix haute : que ces heures soient réellement réaffectées à un autre travail utile. Si elles se traduisent seulement par une sensation de soulagement, le gain reste vrai pour vos équipes mais il n'apparaîtra jamais dans vos comptes.
Détenir les données d'autres entreprises relève le niveau d'exigence
Le jour où les données appartiennent à d'autres sociétés, une série d'obligations facultatives deviennent contractuelles : des sauvegardes testées, un journal des accès, la suppression sur demande, une personne nommément responsable, et des engagements écrits que vous devez être capable de tenir un mardi de crise, pas seulement de signer un jour de commercial.
Dans la pratique, cela ressemble à des choses très concrètes : une sauvegarde quotidienne dont la restauration est répétée pour de vrai deux fois par an, un objectif de remise en service de l'ordre de deux heures, une connexion à deux étapes pour tous les administrateurs, et des identifiants distincts entre l'environnement de test et la production. Rien de spectaculaire, mais chacun de ces points est une question qu'un client sérieux vous posera avant de signer, et que vous ne pourrez pas improviser.
La comparaison des risques est brutale et il vaut mieux la regarder en face. Une fuite dans un outil interne concerne vos propres données et reste votre propre problème, désagréable mais circonscrit. La même fuite dans un produit concerne les données de 300 entreprises, chacune avec son avocat, ses propres obligations de notification et son propre calendrier de questions. C'est la raison pour laquelle les travaux de sécurisation figurent chez nous dans le budget initial et non dans une phase ultérieure, et nos articles sur la sécurité détaillent les vérifications à exiger d'un prestataire avant la mise en ligne.
Quand la réponse la plus modeste est la bonne
Avant de construire quoi que ce soit, posez l'opération acheter ou développer. Un logiciel du commerce facturé 12 à 30 dollars par utilisateur et par mois coûte 2 880 à 7 200 dollars par an pour vingt personnes. Face à un développement sur mesure à 30 000 dollars, le retour sur investissement se situe donc entre quatre et dix ans à cette taille d'équipe, ce qui dépasse largement la durée de vie de la plupart des décisions d'entreprise.
Trois questions suffisent en général à trancher, et vous pouvez y répondre aujourd'hui, sans réunion. Votre processus est-il stable, c'est-à-dire toujours le même dans six mois ? Est-il suffisamment inhabituel pour qu'aucun logiciel existant ne s'en approche sans vous forcer à changer votre façon de travailler ? Et sera-t-il utilisé chaque jour par plus de vingt-cinq personnes ? Deux réponses négatives et l'abonnement du commerce l'emporte, presque toujours.
Nous le disons sans détour, parce que défendre votre budget fait partie du travail : Linkysoft a déjà conseillé à des clients d'acheter la solution toute faite et de revenir nous voir un an plus tard, une fois le processus stabilisé et les limites du produit du commerce réellement atteintes. Le projet le plus coûteux reste celui qui n'aurait jamais dû commencer.
La question mobile se règle de la même manière. Une application mobile se justifie quand vos utilisateurs travaillent loin d'un bureau, sur le terrain, dans un entrepôt ou en tournée, avec parfois une connexion capricieuse. Dans tous les autres cas, une page web bien conçue sur un téléphone coûte moins cher, se met à jour instantanément et évite la validation des magasins d'applications.
Construire l'outil d'abord et le vendre plus tard, sans tout repeindre
Il existe un chemin intermédiaire honnête : construire l'outil pour vous, mais laisser la porte ouverte. Quatre décisions suffisent, et elles se prennent au tout début.
- Faire porter à chaque table de la base de données une étiquette client dès le premier jour, même s'il n'existe qu'un seul client, le vôtre.
- Placer les réglages dans un écran de configuration plutôt que dans le code, pour qu'une deuxième entreprise puisse fonctionner autrement sans appeler un développeur.
- Ne jamais inscrire en dur une règle propre à votre entreprise, mais en faire un paramètre modifiable.
- Garder votre identité visuelle séparée du cœur du logiciel, pour qu'une autre marque puisse s'y afficher un jour sans tout démonter.
La comparaison de coûts rend le choix évident. Ces quatre décisions ajoutent environ 10 à 15 % au budget initial. Les ajouter après dix-huit mois d'usage interne coûte plutôt 30 à 50 % du coût de construction d'origine, plus une migration de données délicate, avec une interruption de service et des lignes à vérifier une par une. Payer 10 % maintenant ou 40 % plus tard : l'arbitrage se fait tout seul quand on le pose en ces termes.
La mise en garde est tout aussi importante : la plupart des outils internes ne devraient jamais devenir des produits. La partie difficile n'est pas d'écrire le logiciel, elle consiste à trouver deux cents entreprises qui ont exactement le même problème, la même façon de travailler et le même budget, puis à les convaincre une par une. Si vous n'avez pas déjà rencontré cinq de ces entreprises, gardez l'outil pour vous et faites-le très bien. Nos études de cas montrent les deux chemins, y compris ceux qui se sont arrêtés volontairement au premier.
Une liste de contrôle à passer cette semaine
Avant de dépenser un dollar, mettez cinq réponses par écrit, sur une seule page.
- Qui paie, et pourquoi paierait-il plutôt que d'ouvrir un tableur ?
- Qui répond au support à neuf heures du matin, nommément ?
- Que se passe-t-il au centième client, en support comme en hébergement ?
- Combien coûtent réellement les quatre-vingt-dix premiers jours, construction et fonctionnement compris ?
- Combien vous coûte aujourd'hui la méthode actuelle, en heures perdues, en erreurs de saisie et en clients agacés ?
Cette dernière réponse est celle qui décide de tout, et c'est presque toujours la seule que personne n'a chiffrée.
Prenez ensuite le plus petit premier pas honnête. Pour un outil interne : un seul processus, une seule équipe, six semaines, puis on regarde ce qui a changé dans la vraie journée de travail. Pour un produit : un pilote payant avec trois entreprises, facturé même symboliquement, avant de construire la couche vendable, parce qu'une entreprise qui accepte de payer vous apprend en un mois ce que dix entretiens gratuits ne vous diront jamais.
Si vous hésitez encore entre les deux chemins, nous pouvons chiffrer les deux sur la même liste de fonctionnalités, avec le coût de fonctionnement de la première année et le nombre de clients nécessaire pour rentrer dans vos frais. Écrivez-nous deux paragraphes sur votre situation et vous repartirez avec deux chiffres comparables, même si la conclusion honnête est qu'il ne faut rien construire pour l'instant.
