Créer une application pour votre entreprise : les six étapes et ce que vous décidez à chacune

Deux personnes très différentes tapent « comment créer une application » dans un moteur de recherche. La première veut la construire elle-même — souvent gratuitement, avec un outil no-code, en un week-end. La seconde dirige une entreprise, a un processus qui ne tient plus dans un tableur et compte confier la construction à un prestataire. Toutes deux obtiennent les mêmes résultats de recherche, alors qu'elles ont besoin de réponses complètement différentes.

Si vous faites partie du premier groupe, la réponse honnête est courte. Un outil interne simple — un formulaire, une liste de demandes, un tableau de bord simple — se construit aujourd'hui sur une plateforme low-code ou no-code, sans écrire de code. Cela fonctionne bien tant que vous restez dans les règles de la plateforme : sa base de données, ses écrans et sa tarification par utilisateur. Nous montrons où passe cette limite dans notre article sur le low code et le no code.

La suite de cet article s'adresse au second groupe. Elle montre comment se déroule un projet d'application avec un prestataire, ainsi qu'une chose que l'on dit rarement ouvertement : une application ne se « fabrique » pas, elle se décide dans un ordre précis — d'abord ce qui doit se passer, ensuite à quoi cela doit ressembler, et seulement à la fin le code. Chaque étape rend plus coûteux le retour sur une décision prise à l'étape précédente. Vous décidez à trois moments : au brief, au prototype et à la recette. C'est à ces moments-là qu'il faut être présent, pas à chaque réunion.

Créer une application : commencez par un brief d'une page

Le blocage le plus fréquent au démarrage consiste à croire qu'il faut préparer une documentation avant de parler à un prestataire — un cahier des charges de plusieurs dizaines de pages, des wireframes, un choix de technologie. Ce n'est pas nécessaire : cinq rubriques suffisent. Voici, dans son intégralité, un exemple de brief pour une application de gestion des demandes d'intervention :

C'est tout. Ce brief tient sur une page et suffit pour obtenir un devis sérieux, parce qu'il dit ce qui doit se passer, pas comment le construire. Trancher l'architecture avant d'avoir parlé à un prestataire, c'est souvent la trancher deux fois.

User story — comment écrire les fonctions pour que le prestataire vous comprenne

Le plus simple pour remplir la rubrique « fonctions » est d'utiliser le format de la plupart des équipes de développement : la user story, une phrase en trois parties — qui, ce qu'il veut faire, et pourquoi. « En tant que client, je veux signaler une panne avec une photo, pour que le technicien sache quoi apporter. » « En tant que responsable, je veux voir les demandes sans technicien assigné, pour que rien n'attende plus d'un jour. »

Ce format a deux avantages que vous apprécierez au moment du devis. D'abord, il oblige à nommer l'utilisateur — or des rôles différents impliquent des écrans, des droits d'accès et donc un coût différents. Ensuite, la partie « pourquoi » permet au prestataire de proposer une solution plus simple au même problème. Trois à cinq phrases par rôle suffisent pour une première conversation.

Pour vérifier si vous êtes prêt pour cette conversation, la checklist ci-dessous reprend tout ce qu'un prestataire vous demandera de toute façon.

Ce dont vous n'avez pas besoin avant de commencer

Vous n'avez pas besoin d'une charte graphique terminée : un logo et des couleurs suffisent si vous les avez, et sinon, une première version peut se construire sans. Vous n'avez pas besoin de connaissances techniques : choisir le langage, la base de données et l'hébergement est le travail du prestataire ; le vôtre est de vérifier qu'il sait justifier ce choix. Vous n'avez pas non plus besoin d'un cahier des charges détaillé — il s'élabore à la première étape du projet, avec le prestataire. Nous détaillons ce que contient un bon brief, et ce qu'il ne contient pas, dans notre article sur le brief d'un site web — les règles sont les mêmes pour une application.

Étape 1 — analyse et atelier

La première étape est une conversation sur votre entreprise, pas sur les fonctions. Le prestataire veut comprendre comment le travail se fait aujourd'hui, qui utilisera l'application, où l'information se perd et quelles tâches sont manuelles et répétitives. Cela prend le plus souvent la forme d'un atelier : une ou plusieurs séances au cours desquelles on met à plat les processus, les rôles des utilisateurs et la carte des fonctions.

Une analyse bien menée produit des choses vérifiables :

• une description des fonctions — les user stories du brief, développées, avec les critères qui vous permettront de constater qu'une fonction marche ;
• une liste des rôles et de ce que chacun peut voir et modifier ;
• un plan de l'écran principal et des parcours les plus importants ;
• le périmètre de la première version — ce qui entre au lancement, ce qui est délibérément reporté. Nous expliquons comment le réduire dans notre article sur le MVP ;
• une estimation du temps et du coût de ce périmètre.

C'est le premier des trois moments où vous décidez. Si la description des fonctions ne correspond pas à la façon dont travaille votre entreprise, c'est le dernier moment où une correction coûte une conversation plutôt qu'une refonte.

Étape 2 — concevoir l'application : wireframe et prototype

Beaucoup de clients entendent « conception » et pensent aux couleurs. Or la conception d'une application commence par la logique : quels sont les écrans, ce qu'ils contiennent et comment l'utilisateur passe de l'un à l'autre. L'apparence vient en dernier.

Trois termes reviennent à cette étape, et il vaut la peine de les distinguer, car chacun correspond à un coût différent :

• wireframe — le squelette d'un écran : rectangles au lieu d'images, sans couleur. Il sert à fixer ce qui se trouve où ;
• prototype — une version cliquable des wireframes : vous pouvez parcourir les principaux parcours avant que la moindre ligne de code soit écrite ;
• maquette (UI) — l'apparence finale : couleurs, typographie, boutons, appliquée à une structure déjà validée.

Nous revenons sur ces trois notions dans notre article sur les wireframes, maquettes et prototypes, et sur la différence entre UX et UI dans l'article UX et UI.

Le prototype est le deuxième moment où vous décidez, et le moins cher de tout le projet pour changer d'avis. Montrez-le à ceux qui utiliseront réellement l'application, pas seulement à la direction. Cherchez-y trois choses, car ce sont elles qui gâchent le plus souvent une application techniquement correcte :

• des formulaires qui demandent trop d'un coup. Chaque champ dont vous n'avez pas besoin au départ est une raison pour l'utilisateur d'abandonner ; le reste des données peut être recueilli plus tard ;
• des messages d'erreur qui ne disent rien. « Une erreur s'est produite » n'aide pas ; « saisissez votre e-mail au format [email protected] » — si ;
• une navigation calquée sur votre structure interne, pas sur les tâches de l'utilisateur. Si la fonction la plus utilisée est cachée dans un menu de troisième niveau, seul son concepteur la trouvera.

Ce que vous recevez après l'étape de conception

La conception d'une application web ne se résume pas à un fichier d'images. À l'issue de cette étape, vous devez recevoir trois choses vérifiables : une carte des écrans, c'est-à-dire la liste de toutes les vues et des transitions entre elles ; un prototype cliquable des parcours principaux ; et un ensemble de composants — boutons, champs, tableaux, messages — à partir desquels tous les écrans sont construits. Ce dernier point paraît technique, mais son effet est simple : une fonction ajoutée dans six mois sera assemblée à partir de composants existants, pas conçue depuis zéro. Si vous ne recevez que quelques beaux écrans principaux, demandez le reste avant que le développement commence.

Étape 3 — développement en sprints

Une fois la conception validée, le développement commence. C'est l'occasion de dissiper un premier mythe : pendant des mois « il se passerait quelque chose », et vous ne verriez le produit fini qu'à la fin. Dans un projet bien mené, le travail se fait en sprints — blocs d'une à deux semaines — et à l'issue de chacun, vous voyez une partie de l'application qui fonctionne.

Sans jargon, le développement comporte trois couches. Le frontend, c'est ce que voit l'utilisateur : les écrans et les interactions du prototype. Le backend, c'est la logique et les données : qui peut faire quoi, où sont enregistrées les demandes, ce qui se passe après un clic. Les intégrations relient l'application aux systèmes que vous utilisez déjà — et chacune constitue une ligne à part dans le calendrier, comme nous le verrons plus bas.

Ces parties fonctionnelles se consultent dans un environnement de test (staging), c'est-à-dire une copie de l'application qui ne touche pas aux données réelles. Demandez-y un accès dès le premier sprint : c'est le seul moyen de repérer un malentendu au bout de deux semaines, et non de deux mois.

À la fin de chaque sprint, l'équipe montre ce qu'elle a construit. Pour vous, cette courte réunion compte davantage que des rapports hebdomadaires, car elle montre du code qui fonctionne et non une description de l'avancement. Venez-y avec une seule question : ce que nous voyons correspond-il aux user stories de la première étape ? Si ce n'est pas le cas, c'est maintenant qu'une correction ne coûte qu'un sprint. C'est aussi là qu'il faut signaler les changements de périmètre, plutôt que par e-mail en plein sprint : une équipe bien organisée les inscrit au sprint suivant et vous dit ce qu'elle repousse en échange.

Étape 4 — la recette (tests d'acceptation utilisateur, UAT)

Les tests fonctionnels — vérifier que chaque fonction marche comme décrit — sont le travail du prestataire. La recette (UAT, de l'anglais user acceptance testing) est le vôtre. Le glossaire ISTQB, qui fait référence pour la terminologie des tests, la définit ainsi : « un niveau de test qui vise à déterminer s’il faut accepter le système » (glossaire ISTQB, test d’acceptation). La question n’est pas « y a-t-il des bugs », mais « est-ce bien ce que nous avons commandé ».

La recette est le troisième moment où vous décidez, et le seul que vous ne pouvez pas déléguer au prestataire. Quelques règles la facilitent :

• rédigez les critères d'acceptation à l'avance, idéalement avec les user stories, dès l'analyse. « Le client voit le statut de sa demande mis à jour dans la minute qui suit le changement » se vérifie ; « ça doit bien marcher », non ;
• ce sont les futurs utilisateurs qui testent. Inutile d'être nombreux : trois ou quatre personnes par rôle suffisent, si elles déroulent de vrais scénarios de leur travail ;
• testez sur les appareils sur lesquels l'application tournera, dans les conditions où elle sera utilisée — sur le terrain, à l'entrepôt, avec un réseau faible ;
• séparez bugs et souhaits. Un écart par rapport à la description est un bug à corriger dans le cadre du projet ; une nouvelle idée est un point pour une deuxième version.

Étape 5 — mise en ligne

La mise en ligne, c'est faire passer l'application de l'environnement de test à l'environnement de production, celui où de vrais utilisateurs travaillent sur de vraies données. Techniquement, cela comprend la configuration du serveur, du domaine et du certificat, les sauvegardes et la surveillance — c'est le travail du prestataire. Trois choses exigent en revanche une décision de votre part :

• un plan pour revenir en arrière. Demandez ce qui se passe si quelque chose tourne mal après le lancement, et en combien de temps on peut revenir à l'état précédent. Une bonne réponse est concrète ;
• les documents légaux. Si l'application traite des données personnelles, la politique de confidentialité et les conditions d'utilisation doivent être prêtes le jour du lancement ;
• un message aux utilisateurs. Une application dont personne n'a entendu parler ne sera pas utilisée. Une courte information — pourquoi elle existe, ce qu'elle change et à partir de quand — ainsi qu'une personne à contacter pendant les premiers jours valent souvent plus que n'importe quelle fonction.

Si l'application doit être publiée sur l'App Store ou Google Play, s'ajoutent les comptes développeur, les tests et l'examen de chaque version — un sujet à part, traité dans notre article sur comment créer une application mobile.

Étape 6 — développement continu et maintenance

Le lancement ne termine pas le projet. Après les premières semaines apparaissent des besoins que personne n'avait prévus, les systèmes auxquels l'application est reliée évoluent, et les navigateurs comme les téléphones reçoivent de nouvelles versions. Une application demande un entretien continu — correctifs, mises à jour, surveillance — et c'est un coût récurrent, pas ponctuel.

Nous ne donnons pas ici de pourcentage de la valeur du projet « à consacrer à la maintenance », car les chiffres qui circulent n'ont pas de source primaire. Ce qui compose réellement la facture après le lancement, et ce que l'on peut chiffrer à l'avance, nous le détaillons dans notre article sur le coût de développement d'une application.

Combien de temps faut-il pour créer une application

Il n'existe pas de réponse unique du marché à cette question ; nous vous montrons donc la nôtre : les règles avec lesquelles notre assistant de brief estime la durée d'un projet. Ce sont les hypothèses de planification de nos propres projets, pas une mesure du marché — mais elles montrent des proportions qui se perdent le plus souvent dans les discussions sur les délais.

Le temps de base est de 12 à 24 semaines pour un portail ou une plateforme web, et de 16 à 32 semaines pour une application de type SaaS. Cet écart ne traduit pas une incertitude, mais l'étendue du périmètre : la même étiquette couvre une interface interne pour vingt employés et un produit pour des milliers de clients.

La répartition compte davantage que le total. Dans nos hypothèses, le développement représente 40 % de la durée du projet, soit moins de la moitié. L'UX et la maquette en représentent ensemble 35 %, et les tests 15 % de plus. Planifier un calendrier comme si une application était surtout du code revient en général à économiser sur les étapes qui décident si quelqu'un l'utilisera.

Traduit en semaines, un portail de 16 semaines se répartit ainsi : un peu plus de 3 semaines pour l'UX, 2,4 pour la maquette, 6,4 pour le développement, un peu moins d'une semaine chacun pour le contenu et le lancement, et 2,4 semaines pour les tests. Si le calendrier du prestataire ne prévoit que quelques jours de tests en fin de projet, ce n'est pas une économie : ces semaines sont simplement reportées après le lancement, quand ce sont les utilisateurs qui trouvent les bugs.

Certains éléments prolongent ce temps de base. Dans nos règles, un espace client avec connexion ajoute 2 à 4 semaines, une intégration CRM 1 à 3, une intégration ERP 2 à 5, et une API pour une application mobile 3 à 6. Chacun de ces éléments mérite d'apparaître comme une ligne à part dans le calendrier que vous remettra le prestataire. Pour chiffrer votre périmètre, notre calculateur du coût d'une application web montre l'écart entre une première version et un produit complet ; notre étude des prix des applications web en Pologne est une lecture utile, même si elle décrit le marché polonais, pas un repère suisse.

Comment choisir une agence

Un portfolio montre ce qu'un prestataire a construit. Il ne montre pas comment se passera la collaboration avec vous pendant plusieurs mois — et c'est cela qui décide si le projet livre ce que vous avez commandé. Cinq questions qui testent le processus, pas la présentation :

1. Qui dirige le projet de votre côté, et à quelle fréquence verrons-nous une partie de l'application qui fonctionne ? Une bonne réponse nomme une personne et un rythme de sprints, pas « nous resterons en contact ».
2. Aurons-nous accès à un environnement de test dès le départ ? Sinon, vous verrez l'application pour la première fois à la recette.
3. Comment écrivez-vous les critères d'acceptation ? Un prestataire qui pose la question dès l'analyse pense à la recette dès le début.
4. Qui est propriétaire du code, du dépôt et des comptes ? Hébergement, domaine, comptes stores — tout doit être à vous, ou transmis par écrit.
5. Que se passe-t-il après le lancement ? Qui corrige les bugs, en combien de temps et à quelles conditions — à inscrire dans le contrat avant d'en avoir besoin.

Vous trouverez une liste complète pour comparer plusieurs prestataires dans notre checklist de sélection d'une agence.