Applications web et mobiles pour entreprises — un guide de construction, décision par décision

Cette rubrique s’adresse aux personnes qui commandent une application, pas à celles qui la programment. Le dirigeant d’une entreprise, un responsable de service, la personne à qui l’on a confié la tâche de « s’occuper du système » parce qu’un processus ne tient plus dans un tableur et une boîte mail. Nous n’y expliquons ni les langages de programmation ni l’architecture. Nous y expliquons les décisions que vous devez prendre pour qu’une application soit construite, tienne dans le budget et soit réellement utilisée.

Il y a cinq décisions de ce type, et elles se prennent dans un ordre précis. Chacune restreint la suivante : le périmètre de la première version dépend de ce qui doit être construit, le prix dépend du périmètre, le calendrier dépend du prix et de qui fait quoi, et le chemin vers l’utilisateur dépend de tout ce qui précède. C’est pourquoi cette rubrique est organisée selon cet ordre, et non par thème.

Si votre question est plutôt « est-ce que ça vaut le coup », « un outil prêt à l’emploi ou le nôtre » ou « quel système pour le CRM, la réservation ou le stock », commencez par notre rubrique sur les logiciels d’entreprise — c’est là que se trouvent les questions d’affaires. Ici, il est question de la construction elle-même.

Cinq décisions, dans l’ordre

Le schéma ci-dessous rassemble toute la rubrique en une seule image : pour chaque décision, la question que les entreprises nous posent, ce que cette décision détermine, et l’article qui y répond. Il n’est pas nécessaire de tout lire dans l’ordre — mais si vous partez de zéro, cet ordre vous évitera des allers-retours.

« Nous ne savons pas si ça doit être une application, ou si un site suffit »

C’est la première question, et celle qu’on saute le plus souvent. Un site web décrit une entreprise et son activité : qui vous êtes, ce que vous proposez, comment vous contacter. Une application prend en charge cette activité : elle enregistre une commande, affiche le statut d’un dossier, consigne une demande, relie des données provenant de plusieurs endroits. Si ce dont vous avez besoin peut se faire avec un formulaire de contact et une présentation claire de votre offre, une application sera une dépense inutile. Si les clients ou les collaborateurs doivent y faire quelque chose — se connecter, modifier, vérifier, valider — un site ne suffit plus.

La limite n’est pas toujours évidente, car les sites d’aujourd’hui font plus qu’avant, et les applications simples sont parfois moins chères qu’elles n’en ont l’air. Ce qu’est exactement une application web, ses principaux types — portail client, back-office interne, application de vente — et comment reconnaître que votre entreprise en a déjà besoin, nous le détaillons avec des exemples d’applications que nous avons construites pour nous-mêmes.

Cette décision détermine si vous construisez un système ou non. Elle mérite d’être prise en connaissance de cause, avant que quiconque ne commence à chiffrer des fonctionnalités.

« Nous avons plus d’idées que de budget »

Une fois qu’il est clair que l’application doit être construite, une liste de fonctionnalités apparaît — en général plus longue que ne le permet le budget. La réaction la plus fréquente est « commençons par un MVP », ce qui, en pratique, signifie les mêmes fonctionnalités, faites moins cher. C’est le chemin vers un produit qui n’a rien testé.

Le MVP, ou minimum viable product, est autre chose : la plus petite version qui répond à une seule question d’affaires — par exemple, si les clients passeront commande eux-mêmes au lieu de téléphoner. C’est cette question qui détermine le périmètre, pas le budget, et la partie la plus difficile du travail consiste à écrire ce que vous ne construisez pas. Comment réduire le périmètre avec la méthode MoSCoW, en quoi un MVP diffère d’un proof of concept et d’un prototype, et à quel indicateur mesurer le résultat, nous le montrons à partir du périmètre de notre propre CRM et de l’histoire de notre module de réservation.

Cette décision détermine le budget et le calendrier de la première version — et si, une fois qu’elle sera en ligne, vous en saurez plus qu’avant.

« Nous avons reçu trois devis, et ils sont tous différents »

Trois devis pour la même application, dont l’un coûte plusieurs fois l’autre : c’est la situation normale, pas l’exception. La différence vient rarement du taux horaire. Elle vient en général de ce que chaque prestataire a compris comme périmètre, du nombre d’heures qu’il y a prévu, et de ce qu’il a inclus dans le prix — tests, design, mise en ligne, maintenance.

Il n’existe pas de chiffre de marché unique pour le coût de développement d’une application, car nous n’avons trouvé aucune grille tarifaire publiée pour le développement de logiciels en Suisse. Il existe en revanche un calcul que vous pouvez reconstruire vous-même : d’où vient le taux, comment lire le périmètre dans un devis, et ce que coûte une application après sa mise en ligne. Nous le détaillons étape par étape, en disant clairement où se situent nos propres prix.

Cette décision détermine le choix du prestataire — et si vous comparez des offres, ou seulement le chiffre en bas de chacune.

« Nous voulons savoir comment se déroule le projet et quel est notre rôle »

Un projet d’application dure des mois, mais le client n’a pas besoin d’assister à chaque réunion. Il doit être présent à trois moments : le brief, quand se décide ce qui va être construit ; le prototype, le moment du projet où changer d’avis coûte le moins cher ; et la recette, c’est-à-dire les tests d’acceptation, qui ne peuvent pas être délégués au prestataire.

Comment créer une application pour votre entreprise avec un prestataire — du brief d’une page, en passant par six étapes de projet, jusqu’au choix d’une société de développement — nous le décrivons en précisant la durée que cela prend selon les règles que nous utilisons pour planifier nos projets, et ce à quoi ce temps est consacré. Dans nos estimations, la programmation représente moins de la moitié du projet.

Cette décision détermine le calendrier et votre rôle dans celui-ci — et si vous découvrez un malentendu après deux semaines, ou après deux mois.

« L’application doit-elle être dans un store ? »

Beaucoup d’entreprises supposent qu’une « application pour téléphone » signifie l’App Store et Google Play. En réalité, une partie de ces besoins peut être couverte par une PWA — un site que l’on peut installer sur un téléphone, qui fonctionne hors ligne et envoie des notifications, sans store, sans examen à chaque version et sans frais de compte.

Les limites d’une PWA sont toutefois fixées par le navigateur du téléphone, pas par le prestataire, et sur iPhone elles sont plus restreintes que sur Android : l’installation est manuelle, les notifications ne fonctionnent qu’une fois l’application ajoutée à l’écran d’accueil, et certaines fonctionnalités matérielles sont totalement absentes. Ce qu’est une PWA, ce qu’elle sait faire sur chaque système, et quand elle remplace une application de store, nous le montrons avec une matrice de capacités vérifiée auprès des sources.

Cette décision détermine le chemin vers l’utilisateur — et si Apple et Google finissent par fixer la seconde moitié du projet.

« Nous avons besoin d’une application dans l’App Store et Google Play »

Si un store est nécessaire — parce que les clients vous y cherchent, parce que vous avez besoin de fonctionnalités du téléphone ou de paiements intégrés — construire l’application n’est que la moitié du travail. L’autre moitié est fixée par les stores : un compte d’entreprise avec un numéro DUNS, un test avant la mise en ligne, un examen à chaque version, et des exigences qui changent chaque année.

Comment créer une application mobile pour une entreprise — du choix de la plateforme, en passant par les applications natives et multiplateformes, jusqu’au chemin vers le store avec les délais publiés par Apple et Google — nous le décrivons, en expliquant pourquoi vos propres utilisateurs comptent davantage que la moyenne du marché.

Cette décision détermine par quelle plateforme vous commencez, et combien de temps ajouter à votre calendrier avant que l’application n’atteigne ses utilisateurs.

Les questions d’affaires ont leur propre rubrique

Cette rubrique part du principe que vous savez ce que vous voulez construire, et que vous vous demandez comment. S’il faut d’abord déterminer si un logiciel sur mesure est rentable, consultez notre rubrique sur les logiciels d’entreprise. Vous y trouverez des articles sur les cas où un logiciel prêt à l’emploi suffit, et où le sur mesure se rentabilise, sur les plateformes low-code et no-code, et sur les systèmes par lesquels les entreprises commencent le plus souvent : CRM pour une petite entreprise, systèmes ERP et systèmes de réservation en ligne.

Outils et données

Les prix figurent dans nos rapports, pas dans les articles, pour pouvoir les mettre à jour à un seul endroit. Notre rapport sur le coût des applications web et notre rapport sur le coût des applications mobiles — nos études du marché polonais — rassemblent des médianes tirées d’offres et de grilles tarifaires, avec leur méthodologie et ses limites. Notre calculateur de coût d’application web montre la différence entre une première version et un produit complet pour votre propre périmètre, et notre quiz : site, application web ou mobile vous guide dans la première décision de cette carte en quelques questions.

Quand l'application doit dialoguer avec d'autres systèmes — une banque, une boutique, un transporteur ou un registre public —, la première notion à comprendre est l'API : ce que c'est, en quoi elle diffère d'un webhook, et comment sécuriser une intégration.

Quand vous cherchez un prestataire

Si les décisions sont prises et que vous cherchez une entreprise pour construire l’application, nous décrivons comment nous travaillons sur les applications web, les applications mobiles et les MVP pour startups.