8 erreurs coûteuses de développement d'applications que les PME répètent sans cesse

Voici la vérité inconfortable sur les projets d'application qui dérapent : au moment où le code semble fautif, le projet était déjà perdu depuis des semaines. Les erreurs coûteuses dans le développement d'applications de petite entreprise ne surviennent presque jamais au clavier. Elles surviennent dans des conversations anodines — le brief jamais couché sur le papier, la fonctionnalité que quelqu'un a ajoutée « tant qu'on y est », le développeur choisi parce qu'un ami l'a recommandé. Sur le moment, rien de tout cela ne ressemble à une décision. Tout cela vous coûte plus tard.

J'ai vu beaucoup de petites entreprises commander leur première application, et on m'a appelé pour en sauver bon nombre après coup. Les dirigeants sont rarement des gens négligents. Ils sont fins, soigneux, doués pour gérer une entreprise. Mais le logiciel a son propre lot de pièges qui n'existent nulle part ailleurs dans leur vie professionnelle, et personne ne les a prévenus. Alors ils foncent droit dans les mêmes huit écueils, à peu près dans le même ordre, à chaque fois.

Voici la liste que j'aurais aimé que chaque dirigeant ait avant de dépenser le moindre centime. Pas de la théorie — les véritables erreurs, récurrentes, et les petits ajustements de cap qui auraient sauvé chaque projet. Si vous êtes sur le point de construire une application, ou que vous êtes déjà en plein développement et que quelque chose vous semble de travers, lisez ceci d'abord. La plupart de ces erreurs restent corrigeables si vous les repérez tôt.

Erreur 1 : Construire avant d'avoir prouvé que quelqu'un la veut

L'erreur la plus coûteuse est aussi la plus courante : s'engager dans un développement complet avant d'avoir la moindre preuve réelle que l'application résout un problème pour lequel les gens paieront ou qu'ils utiliseront. L'idée paraît évidente au dirigeant — bien sûr que les clients la voudront — et c'est précisément cette certitude qui est dangereuse. La certitude a l'allure d'une validation. Elle n'en est pas une.

Valider ne signifie pas demander à dix amis si l'idée leur plaît ; tout le monde dit oui par gentillesse. Cela signifie mettre la plus petite version possible devant de vrais utilisateurs dans une vraie situation et observer ce qu'ils font réellement. Un prototype cliquable, une page d'atterrissage qui mesure les inscriptions, une version « concierge » manuelle où vous simulez l'automatisation à la main — chacune vous en dit plus qu'une application finie bâtie sur une intuition. L'ordre compte : prouvez la demande à bas coût, puis construisez à grands frais. Inversez cela et vous pouvez dépenser tout votre budget à peaufiner quelque chose que personne n'ouvre deux fois.

Erreur 2 : La dérive du périmètre déguisée en ambition

Toute application commence légère et nette. Puis le « tant qu'on y est » commence. Tant qu'on construit l'écran de réservation, pourrait-il aussi gérer les bons cadeaux ? Et les points de fidélité ? Et un système de parrainage ? Chaque ajout paraît raisonnable pris isolément. Ensemble, ils triplent silencieusement le délai et la facture — et repoussent le lancement si loin que l'élan d'origine s'éteint.

La solution n'est pas de dire non aux bonnes idées. C'est de les mettre de côté. Tenez une liste « version deux » visible où chaque idée brillante attend son tour. Cela produit un effet à la fois psychologique et pratique : les gens cessent de se battre pour caser des fonctionnalités dans la première version dès qu'ils ont la confiance qu'il existe une vraie place pour leur idée plus tard. Votre première version doit faire une chose vraiment bien, et non dix choses correctement. Une application qui maîtrise un seul flux de travail est utilisée. Une application qui fait tout à moitié est abandonnée.

Erreur 3 : Pas de brief écrit — juste une image mentale partagée

Celle-ci est invisible jusqu'à ce qu'elle morde. Le dirigeant a une application claire en tête. Le développeur a une application claire en tête. Tout le monde acquiesce lors de la réunion de lancement. Personne ne le couche correctement sur le papier — et les deux images, il s'avère, n'ont jamais été la même image. Vous le découvrez à mi-parcours, quand ce qui est construit n'est pas ce que vous aviez imaginé, et voilà qu'une dispute éclate sur qui a dit quoi.

Vous n'avez pas besoin d'une spécification de cent pages. Vous avez besoin de quelques pages que tout nouveau venu pourrait lire et comprendre : qui utilise cette application, quelles sont les trois ou quatre choses qu'il doit y faire, à quoi ressemble un résultat réussi. Ajoutez une esquisse sommaire des écrans clés. C'est tout. Le but du brief n'est pas la bureaucratie — c'est une référence partagée que vous pouvez tous deux désigner quand la mémoire et la réalité commencent à s'écarter, ce qu'elles font toujours.

Erreur 4 : Choisir le développeur de la mauvaise manière

La plupart des dirigeants choisissent leur premier développeur sur l'un de deux signaux fragiles : le devis le plus bas, ou une recommandation personnelle de quelqu'un d'un autre secteur. Les deux peuvent fonctionner par chance. Aucun n'est une manière fiable de choisir quelqu'un à qui vous confierez une part considérable d'argent et plusieurs mois de l'avenir de votre entreprise.

Le devis le plus bas est particulièrement traître dans le logiciel, car l'écart entre un devis et le coût final est énorme et invisible. Un développeur bon marché qui a besoin de trois tours de reprise, disparaît deux semaines et vous laisse un code que personne d'autre ne peut maintenir revient bien plus cher qu'un développeur un peu plus onéreux qui fait les choses correctement. Le prix est ce que vous voyez ; le coût total est ce que vous payez.

Ce qu'il faut vraiment vérifier

Demandez à voir des réalisations qu'ils ont livrées et qui tournent encore, et si vous le pouvez, parlez à ces clients sans le développeur dans la pièce. Demandez comment ils gèrent les changements en cours de projet, car il y aura des changements. Demandez à qui appartiennent le code et les comptes une fois terminé — la réponse devrait toujours être à vous. Et soyez attentif à savoir s'ils vous posent de bonnes questions en retour. Un développeur qui se contente d'exécuter les ordres construira exactement la mauvaise chose, très efficacement. Les bons vous contredisent, pointent les angles morts de votre raisonnement et traitent le brief comme un point de départ pour une conversation, non comme une liste de courses figée.

Erreur 5 : Budgéter le développement, oublier le reste

Une application n'est pas un achat ponctuel comme une brochure imprimée. C'est un être vivant qu'il faut nourrir. Les dirigeants budgétisent régulièrement le développement et rien d'autre, puis se font surprendre par les coûts qui arrivent ensuite : l'hébergement, les frais des magasins d'applications, la maintenance pour suivre les mises à jour des systèmes d'exploitation mobiles, et l'inévitable série de correctifs et de petites améliorations une fois que de vraies personnes commencent à l'utiliser.

Une règle empirique raisonnable : quel que soit le coût du développement, réservez à nouveau une part conséquente de celui-ci pour la première année de fonctionnement. Le chiffre exact varie, mais l'erreur est universelle — traiter le jour du lancement comme la ligne d'arrivée alors que c'est en réalité la ligne de départ. L'application qui se lance puis se fait abandonner en silence faute de budget pour la maintenir est l'un des dénouements les plus tristes et les plus courants de tout ce domaine, et il est entièrement évitable avec une planification honnête en amont.

Erreur 6 : Concevoir pour vous-même plutôt que pour votre utilisateur

Vous connaissez votre entreprise sur le bout des doigts, ce qui fait de vous le pire juge possible de la facilité d'utilisation de votre application. Les choses qui vous paraissent évidentes — le jargon, l'ordre dans lequel vous accomplissez les tâches, les raccourcis que vous prenez sans réfléchir — déconcertent un utilisateur novice. Une application qui a parfaitement du sens pour le dirigeant et déroute tout le monde a échoué, aussi astucieuse soit-elle.

Le remède est bon marché et un brin humble : observez de vraies personnes l'utiliser avant de lancer. Pas votre équipe, qui sait déjà comment c'est censé fonctionner — de vrais clients ou employés qui ne l'ont jamais vue. Confiez-leur l'application, donnez-leur une tâche et ne dites rien. Là où ils hésitent, touchent le mauvais élément ou soupirent, voilà votre retour de conception. Cinq personnes suffisent à faire remonter les pires problèmes. Sauter cette étape, c'est ainsi que des applications sortent avec un bouton « envoyer » que personne ne trouve et un parcours d'inscription qui perd la moitié de ceux qui s'y essaient.

• Donnez au testeur une vraie tâche, pas une visite guidée — « réservez un rendez-vous pour mardi prochain », puis restez silencieux.
• Observez ses mains et son visage, pas seulement s'il finit par réussir.
• Notez chaque hésitation ; une pause est un problème de conception que vous ne pouvez pas voir de l'intérieur.
• Résistez à l'envie d'expliquer — si vous devez l'expliquer, l'application aurait dû le faire.
• Testez avec cinq personnes, corrigez les échecs évidents, puis testez à nouveau.

Erreur 7 : Construire du natif iOS et Android sans en avoir besoin

Il existe un réflexe : construire une « vraie » application pour iPhone et Android dès le premier jour, entièrement native, comme le font les grandes marques. Pour la plupart des petites entreprises, c'est deux à trois fois le coût et la complexité pour un bénéfice que vos utilisateurs ne remarqueront jamais. Pire, vous maintenez désormais deux bases de code distinctes pour toujours, doublant chaque correctif futur.

Souvent, le bon premier pas n'est pas du tout une application native. Une application web bien construite qui fonctionne dans le navigateur de n'importe quel téléphone, ou une approche multiplateforme qui produit les deux versions pour les magasins à partir d'une seule base de code, vous met sur le marché plus vite et à moindre coût — et vous pourrez toujours passer entièrement au natif plus tard si l'usage réel prouve que cela en vaut la peine. La question n'est jamais « natif ou web » dans l'abstrait. Elle est : quelle est la plus petite chose, la moins chère, qui permette à de vrais utilisateurs d'accomplir la tâche essentielle ? Construisez cela, apprenez-en, puis dépensez le gros budget avec des preuves plutôt qu'avec des suppositions.

Erreur 8 : Traiter le lancement comme la fin du travail

La huitième erreur consiste à croire que le projet est terminé une fois l'application mise en ligne. Il ne l'est pas — c'est là que le vrai projet commence. Une application sans plan pour la mettre entre les mains des utilisateurs, sans moyen d'entendre ce qu'ils en pensent et sans intention de l'améliorer à partir de ce que vous apprenez est une application qui s'efface en quelques mois. Le développement était la partie facile. L'adoption est la partie difficile, et presque personne ne la prévoit.

Avant de lancer, sachez trois choses : comment les gens apprendront que l'application existe, comment vous mesurerez s'ils l'utilisent réellement, et comment vous recueillerez ce qu'ils vous diront pour que la prochaine série de travaux soit guidée par la réalité plutôt que par des conjectures. Rien de tout cela n'est coûteux. C'est simplement un état d'esprit différent — l'application n'est pas une chose que l'on finit et que l'on quitte, c'est une relation que l'on entretient. Les dirigeants qui le comprennent obtiennent des applications qui deviennent plus utiles avec le temps. Ceux qui ne le comprennent pas obtiennent un pic le jour du lancement et un long déclin silencieux.

Comment échapper aux huit à la fois

Lues ensemble, ces erreurs partagent une racine unique : avancer vite sur des suppositions au lieu d'avancer lentement sur des preuves. Chacune d'elles est un endroit où il a semblé moins cher de sauter l'étape soigneuse. Et chacune d'elles est bien moins coûteuse à traiter avant le développement qu'après. Voici la séquence qui esquive silencieusement les huit.

1. 1
   Prouvez la demande avant de construire

   Un prototype, une page d'atterrissage ou une version manuelle. Obtenez de vraies preuves que quelqu'un la veut avant d'engager le budget.
2. 2
   Rédigez le brief et la liste version deux

   Quelques pages claires que tout le monde peut comprendre, plus un parking pour chaque idée « tant qu'on y est » afin qu'elle ne fasse pas dérailler la v1.
3. 3
   Choisissez le développeur sur son historique, pas sur le prix

   Réalisations livrées, appels de références, propriété claire du code et des comptes, et quelqu'un qui pose de bonnes questions en retour.
4. 4
   Budgétez toute la première année, pas seulement le développement

   Hébergement, maintenance, correctifs et support. Le jour du lancement est la ligne de départ, alors financez le fonctionnement de la chose.
5. 5
   Choisissez la plus petite plateforme qui fait le travail

   Web ou multiplateforme d'abord dans la plupart des cas. Passez entièrement au natif plus tard, avec des preuves, seulement si l'usage l'exige.
6. 6
   Testez avec de vrais utilisateurs, puis planifiez le lancement

   Observez cinq inconnus l'utiliser, corrigez les échecs évidents et décidez en amont comment les gens la trouveront et comment vous mesurerez l'usage.

Questions fréquentes