Préparer son projet d'application ou de logiciel : le guide pour bien démarrer

Par l'équipe NRX3 · Mis à jour le

Vous avez une idée d'application, ou un problème qu'un logiciel sur mesure pourrait régler. Avant d'appeler un développeur, quelques heures de préparation font une grosse différence : sur le prix, sur les délais et sur le résultat. Pas besoin d'être technique pour bien les faire.

En bref

  • Décrivez le problème et les personnes qui vont utiliser l'outil, pas la technologie.
  • Séparez l'essentiel de ce qui peut attendre.
  • Préparez une fourchette de budget et un ordre de priorités.
  • Choisissez un fournisseur qui vous montre des versions tôt et souvent.
  • Assurez-vous que le code et les données vous appartiennent, et faites-le écrire dans le contrat.

1. Décrivez le problème, pas la solution

Le meilleur point de départ n'est pas une liste de fonctions, c'est une description de ce qui ne va pas aujourd'hui. Répondez par écrit, avec vos mots :

  • Qu'est-ce qui vous fait perdre du temps ou de l'argent, aujourd'hui ?
  • Comment le travail se fait-il en ce moment : fichiers, papier, courriels, autre logiciel ?
  • Qui va utiliser l'outil : vos employés, vos clients, vos membres ? Sur quel appareil, et où : au bureau, sur le chantier, au comptoir ?
  • À quoi verrez-vous que le projet est réussi, dans six mois ?

Une page suffit. Elle vaut plus qu'un long cahier des charges écrit dans un vocabulaire qui n'est pas le vôtre.

2. Séparez l'essentiel du « ce serait bien »

Faites trois colonnes : ce qui est indispensable dès le départ, ce qui serait utile ensuite, et ce qui est un bonus. Une première version limitée à l'essentiel coûte moins cher, sort plus vite, et vous apprend beaucoup sur ce que vos utilisateurs veulent vraiment.

3. Rassemblez ce qui existe déjà

  • Vos fichiers, formulaires et rapports actuels : ce sont les meilleurs exemples de vos données.
  • Les logiciels que vous utilisez et avec lesquels le nouvel outil devra échanger de l'information.
  • Des captures d'écran d'applications que vous aimez, ou que vous trouvez pénibles.
  • Les règles qui s'appliquent à vous : renseignements personnels, normes de votre secteur, exigences de vos clients.

4. Préparez votre budget

Le prix d'un logiciel sur mesure dépend surtout de son ampleur : le nombre d'écrans et de règles, les liens avec d'autres systèmes, le niveau de sécurité exigé, et les plateformes visées (web, iPhone, Android). Quelques conseils :

  • ayez une fourchette en tête et dites-la : un bon fournisseur adapte la portée au budget plutôt que l'inverse ;
  • prévoyez aussi l'après-livraison : hébergement, mises à jour, soutien, améliorations ;
  • méfiez-vous d'un prix très bas pour un projet mal défini : les surprises arrivent souvent plus tard.

5. Choisissez votre fournisseur

Posez ces questions et comparez les réponses :

  • Comment allez-vous comprendre notre métier avant de construire ?
  • Quand verrons-nous une première version à essayer ? Ensuite, à quelle fréquence ?
  • Comment suivrons-nous le budget et l'avancement ?
  • Qui relit et teste le code ? Comment la sécurité est-elle prise en compte ?
  • À qui appartiennent le code, les données et la documentation à la fin ?
  • Que se passe-t-il après la livraison si quelque chose ne fonctionne pas ?
  • Si vous utilisez l'IA pour développer, comment vérifiez-vous ce qu'elle produit ?

Faites écrire la réponse sur la propriété dans le contrat : au Canada, sans entente écrite, le code écrit par un fournisseur externe lui appartient généralement.

6. Pendant le projet

  • Essayez chaque version et donnez vos commentaires rapidement : c'est au début que les changements coûtent le moins cher.
  • Gardez une personne responsable de votre côté, qui a le temps de répondre et le pouvoir de trancher.
  • Impliquez de vrais utilisateurs tôt : ceux qui feront le travail tous les jours voient des problèmes que les gestionnaires ne voient pas.
  • Notez les décisions, pour ne pas en rediscuter à chaque rencontre.

Les signaux d'alarme

  • Aucune version à voir avant la toute fin.
  • Un budget qui grimpe sans explication claire.
  • Des réponses vagues sur la propriété du code ou de vos données.
  • Un vocabulaire technique qu'on ne prend pas le temps de vous expliquer.