Ce que doit contenir une bonne proposition logicielle : nos dix pointsCe que doit contenir une bonne proposition logicielle : nos dix points

01Le problème, le périmètre, et ce qui en est exclu

Une proposition s'ouvre sur le problème, formulé avec les mots du client lui-même. Si nous le reformulons avec les nôtres, tout malentendu devient immédiatement visible — ce qui est une bonne chose, car il apparaît avant le contrat.

Vient ensuite le périmètre, sous forme de liste — chaque élément étant un livrable, pas une intention. Le troisième point est celui qu'on oublie le plus souvent : ce qui est hors périmètre. « Pas d'application mobile dans cette version », « la saisie de contenu revient au client », « licences d'intégration tierce non incluses ». Rédiger cette liste est inconfortable, ce qui explique précisément son utilité.

02Interrogez le travail derrière le même intitulé

« Nous voulons un CRM » — mieux vaut partir de « nous perdons le fil de qui doit être recontacté et quand dans le suivi commercial ». Une fois le problème clarifié, les écrans et les notifications nécessaires deviennent concrets ; vous n'avez plus à financer des modules qui ne seront pas utilisés.

La mention « il y a du reporting » ne suffit pas en soi. Quelles données, sur quelle période, visibles par quel utilisateur ? Un export est-il nécessaire ? Si une connexion à votre comptabilité, votre stock, votre système de paiement ou de vente est demandée, le périmètre de la proposition doit couvrir non seulement le nom de l'intégration, mais aussi le sens du flux de données, les conditions d'accès technique et le comportement en cas d'erreur.

03Calendrier, jalons et responsabilités du client

Nous exprimons le calendrier en jalons plutôt qu'en numéros de semaine : validation des maquettes, mise en production interne, tests de recette, mise en ligne. Chaque jalon a un livrable et un approbateur nommé. Les dates dépendent des jalons, et non l'inverse.

Le cinquième point concerne les responsabilités du client, source de la plupart des retards : fichiers de marque, accès au domaine, identifiants pour l'intégration comptable, textes de contenu, données de test réalistes. Inscrire ces éléments dans la proposition avec des dates ne vise pas à désigner un responsable ; cela permet aux deux parties de planifier.

04Interrogez la première version utilisable dans une livraison progressive

Demandez quel travail vous pourrez réaliser dès la première version utilisable. Une entreprise de services, par exemple, peut d'abord utiliser la création d'ordres de travail, l'affectation des techniciens et le suivi de statut ; les analyses avancées peuvent être traitées dans une étape suivante. Cet exemple est purement représentatif ; le bon ordre dépend des priorités de votre activité. Nous avons expliqué comment garder cette première version restreinte et complète dans notre article lancer une idée logicielle plus rapidement grâce au MVP.

La gestion des demandes de changement doit elle aussi figurer dans la proposition. Il est naturel que de nouvelles idées apparaissent en cours de développement ; mais ajouter chaque nouvelle demande de façon invisible dans le calendrier existant n'est pas fiable. L'impact du changement sur le coût, le délai et les autres fonctionnalités doit être montré.

05Données, droits d'accès et conditions de code source

Le personnel, les responsables et les clients ne doivent pas voir les mêmes informations. Le transfert des données, leur sauvegarde, la remise du code source et les licences tierces doivent être discutés explicitement. Savoir à l'avance quels fichiers et quels accès seront remis à la fin du projet est important ; nous avons détaillé ce que nous livrons de notre côté dans notre article ce que contient un pack de livraison logiciel clé en main.

06Prix, échéancier de paiement, garantie et remise

Le prix s'accompagne d'un échéancier de paiement lié aux jalons, pas au calendrier civil. La devise, le traitement de la TVA et la date à laquelle le taux de change est fixé sont indiqués explicitement — pour les clients européens, cette seule ligne élimine la moitié des échanges qui suivent.

Les trois derniers points : la période de garantie et ce qu'elle couvre, le contenu du dossier de remise, et la date d'expiration de la proposition. Cette expiration n'est pas une tactique de pression — elle nous permet de répondre honnêtement quand, trois mois plus tard, quelqu'un demande si elle tient toujours.

La correction d'anomalies, le développement de nouvelles fonctionnalités et la maintenance sont trois activités distinctes. Plutôt qu'une formule large comme « support inclus », demandez que le périmètre et le mode de communication soient précisés. Dans notre périmètre clé en main, nous installons le logiciel convenu sur un serveur répondant aux exigences techniques, le testons, et le livrons opérationnel. Nous offrons une garantie de correction des anomalies de douze mois à compter de la livraison ; les nouvelles fonctionnalités sont évaluées séparément. Le support standard est assuré aux heures ouvrées ; un pack d'assistance 24 heures et un contrat de maintenance annuel distincts peuvent être envisagés en option. Nous proposons notre service de développement logiciel sur mesure avec ce périmètre défini.

07Ces sept points à rechercher en comparant les propositions

• Le problème à résoudre est-il formulé avant la liste des modules à acheter ?
• Les scénarios utilisateurs inclus dans le périmètre sont-ils définis par les données, la période et les droits d'accès ?
• Les intégrations sont-elles décrites avec leur sens, leur accès et leur comportement en cas d'erreur ?
• Le travail réalisable dans la première version utilisable et son critère d'acceptation sont-ils précisés ?
• Le transfert des données, les droits d'accès, la remise du code source et les licences sont-ils explicitement indiqués ?
• La façon dont l'impact des demandes de changement sur le coût et le délai sera montré est-elle expliquée ?
• La garantie, le support et la maintenance sont-ils définis séparément ?