Les étapes du développement d'un logiciel sur mesure, côté client : le guide en 9 étapes

Un projet de logiciel sur mesure compte neuf étapes quand on le regarde du côté de celui qui paie : poser le problème, choisir un prestataire, valider un prototype, arrêter le périmètre et le contrat, valider le design, fixer les fondations techniques, suivre le développement, conduire la recette, puis mettre en production et organiser la maintenance. À chaque étape, le prestataire produit quelque chose, et vous devez fournir des éléments et prendre une décision. Les projets qui échouent butent rarement sur le code. Ils butent sur une décision que personne n'a prise au bon moment.

La plupart des guides décrivent le cycle de développement tel que le voit l'équipe technique : analyse, conception, développement, tests, déploiement. Celui-ci suit le dirigeant ou le responsable qui commande le logiciel, et indique pour chaque étape ce que vous fournissez, ce que vous validez, et les signaux d'alerte.

Les neuf étapes en un coup d'œil

Étape 1 : poser le problème

Avant de contacter qui que ce soit, rédigez une page qui répond à quatre questions : qu'est-ce qui coince aujourd'hui, qui en souffre, à quoi ressemblerait un bon résultat, et qu'est-ce qui est hors sujet. « Nos commandes arrivent par e-mail et deux personnes les ressaisissent dans l'ERP chaque matin, avec des erreurs » est un bien meilleur point de départ qu'une liste de fonctionnalités.

Vous fournissez : le problème avec vos mots, les profils d'utilisateurs, les outils avec lesquels le logiciel devra travailler, et les contraintes fermes (échéance, localisation des données, plafond de budget).

Vous décidez : si le besoin justifie vraiment un logiciel sur mesure. Si un progiciel bien paramétré couvre l'essentiel, achetez-le. Pour un projet plus large, cette étape devient une vraie phase de cadrage, avec ateliers et livrables, décrite dans notre article sur le cadrage d'un projet logiciel.

Étape 2 : choisir un prestataire

Envoyez votre note à quelques prestataires et observez surtout les questions qu'ils vous renvoient. Un bon partenaire s'intéresse à votre façon de travailler, à vos utilisateurs et à vos données avant de parler de technologie.

Vous fournissez : la note, votre calendrier et le mode de paiement que vous préférez.

Vous décidez : à qui vous confiez la suite. Les 12 questions à poser à une agence de développement vous aident à départager les candidats.

Signal d'alerte : un devis ferme envoyé avant que quiconque ait demandé comment votre équipe travaille aujourd'hui.

Étape 3 : valider un prototype avant de s'engager

C'est l'étape que la plupart des guides oublient, et celle qui fait économiser le plus. Un prototype visuel transforme votre note en écrans : les parcours principaux, les rôles, les données clés. Vos utilisateurs réagissent à quelque chose de concret plutôt qu'à un document.

En une séance, on découvre que l'atelier a besoin d'une autre vue que le bureau, qu'il manque un statut, ou qu'un écran que personne n'avait demandé est en fait indispensable. Le corriger sur un prototype ne coûte rien. Le corriger après trois mois de développement coûte cher.

Vous fournissez : deux ou trois utilisateurs réels pour la séance de présentation, et des retours francs.

Vous décidez : si le prototype reflète votre façon de travailler, et ce que doit contenir la première version.

Chez LPR Studio, cette étape est gratuite : nous présentons un prototype de votre logiciel en visio sous 5 jours ouvrés. C'est une démonstration, ni payée ni livrée, qui devient la référence commune du devis. Nous expliquons dans voir son logiciel avant de le payer ce qu'un prototype prouve, et ce qu'il ne remplace pas.

Étape 4 : arrêter le périmètre, le prix et le contrat

Avec un prototype validé, le périmètre devient précis : la liste des écrans, les règles de gestion, les connexions aux autres outils, la reprise des données pour la première version, et ce qui est explicitement remis à plus tard.

Vous fournissez : vos priorités (ce qui est indispensable au lancement, ce qui peut attendre), le mode de prix souhaité et une relecture juridique du contrat.

Vous décidez : trois choses qui pèsent sur tout le projet.

• Le mode de prix. Forfait, régie, ou abonnement sans payer le développement au départ. Le forfait fait porter le risque de dépassement au prestataire, la régie le laisse chez vous.
• Les clauses. Critères de recette, gestion des changements, garantie, droits sur le code (définis au cas par cas dans le contrat), réversibilité des données. Notre liste des clauses à vérifier dans un contrat de développement les passe en revue.
• La première version. Gardez-la courte. Tout ce qui n'est pas indispensable au premier jour peut venir dans une deuxième livraison.

Signal d'alerte : un contrat sans critères de recette écrits. Sans eux, « terminé » veut dire ce que chaque partie veut qu'il dise.

Étape 5 : le design

Le prototype devient des écrans définitifs. Le parcours idéal se valide facilement. Ce qui compte, c'est tout le reste : ce que voit chaque rôle, les écrans vides, les messages d'erreur, ce qui se passe quand un dossier est annulé à mi-parcours.

Vous fournissez : les cas particuliers que seule votre équipe connaît, votre charte graphique et de vrais contenus (vrais noms de produits, vrais types de clients).

Vous décidez : les écrans définitifs, rôle par rôle. Validez-les quand les parcours principaux ne bougent plus, pas avant.

Étape 6 : les fondations techniques

L'équipe de développement choisit l'architecture, l'hébergement, le modèle de sécurité et la façon de se connecter à vos outils existants. Vous n'avez pas à comprendre chaque choix technique, mais certaines décisions vous reviennent.

Vous fournissez : les accès aux outils à connecter (documentation de l'API, comptes de test, un contact chez l'éditeur), vos règles sur la localisation des données et la sécurité, et le nom de la personne qui détiendra les comptes administrateur chez vous.

Vous décidez : où sont hébergées les données, qui détient les clés, et si les risques identifiés sont acceptables. Si le logiciel traite des données personnelles, le RGPD s'applique dès cette étape : registre des traitements, contrat de sous-traitance avec le prestataire, durées de conservation.

Signal d'alerte : un hébergement, un nom de domaine ou des comptes tiers ouverts au nom du prestataire, sans plan pour vous les transférer.

Étape 7 : le développement par itérations

Le développement avance par cycles courts, chacun terminé par une démonstration d'un logiciel qui fonctionne. Le Scrum Guide limite chaque sprint à un mois au plus ; beaucoup d'équipes travaillent sur une ou deux semaines.

Vous fournissez : à chaque démonstration, quelqu'un qui peut décider, et des réponses rapides entre deux démonstrations. Une question qui attend une semaine coûte une semaine.

Vous décidez : si chaque livraison respecte ses critères. « Le code est fini » ne veut pas dire « c'est accepté ». Toute idée nouvelle passe par une demande de changement écrite, chiffrée en coût et en délai, plutôt que par une extension silencieuse du périmètre.

Étape 8 : la recette

La recette est le moment où votre équipe, et non celle du prestataire, vérifie que le logiciel permet de travailler. De vrais utilisateurs déroulent de vrais scénarios avec des données réalistes : une commande de la saisie à la facture, une clôture de mois, un utilisateur aux droits restreints. Dans les marchés publics et chez certaines grandes entreprises, le CCAG TIC prévoit une vérification d'aptitude, puis une vérification de service régulier (VSR), menée en conditions normales d'exploitation sur une période d'observation ; une PME peut garder la même logique sans le vocabulaire.

Vous fournissez : des testeurs dont l'agenda est libéré, des scénarios tirés du quotidien et un jeu de données réaliste.

Vous décidez : si le logiciel est prêt pour la production. Séparez les anomalies bloquantes des améliorations qui peuvent suivre, sinon la recette ne finit jamais. Notre check-list de recette logicielle détaille la méthode.

Signal d'alerte : un plan de tests rédigé par le seul prestataire. Seule votre équipe sait quels cas comptent vraiment.

Étape 9 : mise en production, remise des accès et maintenance

La mise en production combine trois choses : la reprise des données définitives, la formation des utilisateurs et la bascule. Si vous remplacez un outil existant, gardez-le quelques semaines en lecture seule, comme filet de sécurité.

Vous fournissez : l'export final des données, du temps de formation et une date qui évite votre période la plus chargée.

Vous validez : la remise. Au minimum, vous devez recevoir les accès au dépôt de code selon le contrat, les accès administrateur à l'hébergement, au nom de domaine et aux services tiers, la documentation, la description des sauvegardes et de leur restauration, et un engagement écrit de maintenance couvrant corrections, mises à jour de sécurité et délais d'intervention.

Un logiciel n'est jamais terminé. Prévoyez dès le départ un budget de maintenance et d'évolutions, et faites le point sur l'usage après quelques mois : la deuxième version la plus utile vient en général de ce que font réellement les utilisateurs, pas de la liste de souhaits initiale. Ce qui se passe après la livraison est détaillé dans notre article sur la maintenance d'une application métier.

Combien de temps dure le processus

Cela dépend du périmètre bien plus que du processus. Une première version ciblée et une grande plateforme suivent les mêmes neuf étapes, à des échelles très différentes.

Les étapes qui glissent le plus souvent sont celles du client : une présentation du prototype qui attend deux semaines un créneau, une validation de design bloquée par un responsable absent, des testeurs jamais déchargés de leur travail quotidien. Inscrivez ces moments dans les agendas dès l'étape 4, quand le planning est arrêté.

Les erreurs les plus fréquentes côté client

• Sauter le prototype. Découvrir un parcours manquant en plein développement est la façon la plus chère de le trouver.
• Pas de décideur unique. Quand cinq personnes valident, personne ne valide. Nommez une personne habilitée, et un suppléant.
• Traiter le contrat comme une formalité. Critères de recette, gestion des changements et droits sur le code décident de ce qui se passe quand quelque chose tourne mal.
• Être absent des démonstrations. Un retour donné à la fin coûte bien plus qu'un retour donné à chaque itération.
• Laisser les comptes au nom du prestataire. Vous devez pouvoir changer de prestataire sans perdre votre logiciel.
• Oublier le budget de maintenance. Les mises à jour de sécurité et les petites corrections font partie du coût d'un logiciel.

Vous n'avez pas besoin d'un cahier des charges complet pour commencer : une note d'une page suffit pour atteindre l'étape 3. Ensuite, avec les écrans sous les yeux, vous choisissez la suite parmi nos trois formules : un forfait à prix fixe, un abonnement sans payer le développement, ou l'édition d'un SaaS. Nous ne vendons ni heures ni personnel.