7 erreurs des petites entreprises qui achètent un logiciel sur mesure

La plupart des petites entreprises qui se brûlent les doigts sur un projet de logiciel sur mesure ne se brûlent pas à cause de mauvais programmeurs. Elles se brûlent des semaines avant le moindre développement, lors d'une réunion de lancement, d'un échange d'e-mails, d'une poignée de main, à cause d'une décision qui semblait alors anodine. Quand le code arrive, l'erreur est déjà cuite à l'intérieur. La bonne nouvelle, c'est que ces erreurs se répètent de façon ennuyeusement prévisible, ce qui veut dire qu'elles sont évitables si vous savez à quoi elles ressemblent.

J'ai observé beaucoup de ces projets de l'intérieur, des deux côtés de la table. Certains sont devenus des outils dont une entreprise n'imaginait plus pouvoir se passer. D'autres ont fini en page de connexion à moitié terminée, en querelle tendue sur une facture et en dirigeant jurant de ne plus jamais se lancer dans du sur-mesure. Le plus frustrant, c'est le peu qui séparait les deux issues. La technologie était rarement le problème. Les décisions autour de la technologie l'étaient presque toujours.

Voici donc les sept erreurs que je vois encore et encore lorsqu'une petite entreprise commande un logiciel sur mesure. Aucune ne demande de bagage technique pour être évitée. Il suffit de savoir qu'elles existent avant de signer quoi que ce soit.

Erreur 1 : acheter une solution avant d'avoir compris le problème

L'erreur la plus coûteuse survient en premier, et elle paraît inoffensive : « Il nous faut une application qui fait X. » Quand quelqu'un dit cela à voix haute, il a déjà presque toujours arrêté la forme de la solution — un tableau de bord, un portail, une application mobile — sans que personne n'ait écrit le vrai problème en langage clair. Le développement livre alors fidèlement la mauvaise chose, et avec soin.

Un bon logiciel part d'un énoncé du problème, pas d'une liste de fonctionnalités. « Notre équipe de bureau ressaisit chaque commande des e-mails dans le logiciel de comptabilité, et cela occupe deux personnes une demi-journée », voilà un problème. « Il nous faut un CRM sur mesure » est une supposition de solution à un problème que personne n'a pris la peine de nommer. Le premier peut se résoudre à moindre coût et se mesurer. Le second est une invitation ouverte à dépenser.

Erreur 2 : vouloir tout construire d'un coup

Un logiciel sur mesure ressemble à un achat qu'on ne fait qu'une fois par décennie, alors on essaie de caser une décennie de souhaits dans la version un. Chaque service ajoute une demande. Chaque « tant qu'on y est » reçoit un oui. Le périmètre enfle, le calendrier triple, et le projet s'effondre sous sa propre ambition bien avant que personne ne puisse l'utiliser.

Les entreprises qui réussissent font l'inverse. Elles choisissent la tranche la plus douloureuse du problème et construisent celle-là d'abord : une chose réelle, fonctionnelle, en production en quelques mois. Puis elles laissent l'usage réel leur dire la suite. Ce n'est pas seulement moins cher ; c'est plus sûr. Vous apprenez si l'idée fonctionne tant que la mise est encore petite, au lieu de découvrir après six mois et une grosse facture que vous avez conçu la mauvaise chose.

Une vérité dure se cache là-dessous : vous ne savez pas encore vraiment ce dont vous avez besoin. Personne ne le sait au départ. Votre compréhension du problème changera dès que de vraies personnes toucheront un vrai outil. Tout construire d'emblée fige vos suppositions les plus précoces et les moins éclairées. Construire par tranches vous garde flexible, et garde le budget sous contrôle pendant que vous apprenez encore.

Erreur 3 : choisir au seul critère du prix

Vous obtenez trois devis. L'un est nettement moins cher que les autres. Soulagement : ce sera celui-là. C'est l'un des moyens les plus fiables de transformer un petit projet en projet coûteux, car le devis bon marché ne veut presque jamais dire que le travail est moins cher. Il veut généralement dire que les deux parties ont compris la mission différemment.

Un chiffre bas signale souvent l'une de plusieurs choses : le prestataire a sous-estimé le périmètre faute d'avoir assez questionné, il prévoit de faire sa marge plus tard sur les demandes de modification, ou il est inexpérimenté et ignore encore ce qu'il ignore. Aucune de ces situations ne finit bien pour vous. Le prix affiché est le chiffre le moins utile de la proposition. Ce qui compte, c'est de savoir si le prestataire comprend clairement votre problème, pose des questions inconfortables et reste honnête sur ce qui n'est pas inclus.

Erreur 4 : oublier qu'un logiciel n'est pas un achat unique

Un logiciel sur mesure est souvent présenté, et acheté, comme un meuble : on paie une fois, on le possède pour toujours. Ce n'est pas le cas. Un logiciel vit dans un monde en mouvement : les systèmes d'exploitation se mettent à jour, les navigateurs évoluent, les correctifs de sécurité arrivent, votre activité change, les outils auxquels vous vous connectez changent leurs règles. Un outil que personne n'entretient cesse peu à peu de fonctionner, puis casse au pire moment possible.

Cela frappe durement les petites entreprises parce que le coût de maintenance est invisible à la signature. Vous comparez deux devis sur le prix de construction et ne posez jamais la question qui compte le plus : combien cela coûte-t-il de garder cela vivant et en bonne santé chaque année ? Hébergement, mises à jour, petits correctifs, l'ajustement occasionnel à mesure que votre activité évolue : prévoyez-le comme une ligne normale et continue, comme vous le faites pour l'assurance ou la comptabilité. C'est généralement modeste, mais seulement si vous l'anticipez.

Erreur 5 : laisser le besoin flou et sans responsable

« Vous êtes les experts, construisez quelque chose de bien » sonne généreux. En réalité, c'est ainsi que les projets dérivent. Les personnes qui comprennent le mieux votre activité, c'est vous et votre équipe, pas les développeurs. Si vous remettez un brief flou et disparaissez, le prestataire comble les vides avec ses meilleures suppositions, et vous découvrirez ces suppositions au pire moment : à la livraison, quand les changer coûte le plus cher.

Deux rôles doivent être tenus de votre côté, et les petites entreprises n'en tiennent souvent aucun. Le premier est un décideur unique : une personne qui peut dire oui, trancher les désaccords entre services et n'est pas trop occupée pour répondre aux questions pendant des semaines. Le second est la volonté d'être précis sur ce qui compte : les cas limites, l'exception bizarre que votre activité a toujours gérée à la main, la règle que tout le monde connaît mais que personne n'a écrite. C'est exactement ce que le logiciel doit réussir.

Erreur 6 : ne pas demander à qui appartiennent le code et les données

C'est l'erreur silencieuse, et c'est celle qui fait le plus mal des années plus tard. Vous payez pour un logiciel sur mesure, vous supposez qu'il est à vous. Puis la relation avec le prestataire se dégrade, ou il augmente ses prix, ou il disparaît tout simplement, et vous découvrez que vous ne pouvez pas bouger. Vous n'avez pas le code source. Les données vivent dans un système auquel lui seul accède. Toute votre activité dépend désormais d'une entreprise à laquelle vous ne faites plus confiance, et vous n'avez aucun levier.

Rien de tout cela ne nécessite un avocat pour être évité. Cela nécessite trois questions simples posées avant de commencer, tant que vous avez encore tout le pouvoir de négociation : À qui appartient le code source une fois terminé ? Puis-je exporter toutes mes données, dans un format exploitable, quand je veux ? Et si nous nous séparons, qu'est-ce que j'emporte exactement ? Un partenaire sérieux répond à cela sans broncher. L'hésitation ici est le plus grand signal d'alerte de tout le processus.

• Obtenez par écrit que le code source vous appartient, ou que vous en détenez une licence claire et équitable.
• Confirmez que vous pouvez exporter vos propres données dans un format standard, à la demande, sans autorisation.
• Assurez-vous que le travail est assez documenté pour qu'un autre développeur puisse le reprendre.
• Évitez l'enfermement propriétaire là où une technologie simple et connue ferait le même travail.
• Convenez d'avance de ce qu'il advient de l'hébergement et des comptes si vous changez un jour de prestataire.

Erreur 7 : traiter le lancement comme la ligne d'arrivée

Le logiciel est livré, il fonctionne, tout le monde est soulagé. Le projet est déclaré terminé. Six mois plus tard, la moitié de l'équipe est discrètement revenue à l'ancien tableur, et le coûteux nouvel outil est utilisé par deux personnes pour une seule chose. La construction a réussi. L'adoption a échoué, et ce sont deux problèmes totalement différents.

Les gens ne résistent pas aux nouveaux outils par bêtise ou par entêtement. Ils résistent parce que le nouveau est inconnu et que l'ancien fonctionne encore, à peu près. Surmonter cela demande un effort délibéré que personne n'avait budgété : un peu de formation, une raison claire de savoir pourquoi le changement les aide eux en particulier, quelqu'un pour répondre aux questions bêtes sans jugement les premières semaines, et une décision ferme de retirer l'ancien pour qu'il n'y ait pas de repli où se glisser.

1. 1
   Lancez d'abord auprès d'un petit groupe

   Déployez l'outil auprès de quelques volontaires avant toute l'équipe. Ils trouveront les aspérités et deviendront vos ambassadeurs internes.
2. 2
   Montrez le gain personnel, pas le gain pour l'entreprise

   « Ça fait économiser de l'argent à l'entreprise » ne motive personne. « Ça veut dire que vous ne saisissez plus les adresses deux fois » rallie les gens.
3. 3
   Désignez une personne-ressource pour les questions

   Le premier mois, quelqu'un prend en charge les questions bêtes. La friction de la première semaine, c'est ce qui tue l'adoption pour toujours.
4. 4
   Coupez vraiment l'ancien

   Tant que l'ancien tableur existe, les gens continueront de l'utiliser. Une fois le nouveau fonctionnel, retirez le repli, avec douceur mais clarté.

Tout assembler : l'état d'esprit de l'acheteur

Relisez ces sept points et un fil unique les traverse. Presque aucun n'est technique. Ils parlent de clarté, de propriété et de retenue : connaître son problème avant d'acheter, construire par petits pas, juger les prestataires sur leur compréhension plutôt que sur le prix, planifier pour la vie de l'outil et pas seulement pour sa naissance, rester impliqué, protéger sa sortie et traiter le lancement comme le début du vrai travail.

Le logiciel sur mesure est vraiment l'un des meilleurs investissements qu'une petite entreprise puisse faire une fois qu'elle a dépassé les outils standards que tout le monde partage. Un système façonné exactement autour de la façon dont vous travaillez, plutôt que de forcer votre activité à se contorsionner autour du produit d'un autre, est un avantage réel et durable. Les entreprises qui y parviennent ne sont pas celles aux plus gros budgets. Ce sont celles qui ont évité les sept erreurs ci-dessus, et c'est une affaire de jugement, pas d'argent.

Questions fréquentes