Par où commencer pour concevoir un logiciel quand l'informatique n'est pas votre métier

Faire développer un logiciel, un ERP ou une application sur mesure est un gros projet qui se planifie minutieusement. Voici quelques bonnes explications et étapes à suivre pour vous préparer à demander des soumissions qui comprendront non seulement vos critères, mais aussi les éléments auxquels vous n’avez probablement pas pensé.

La description de vos fonctions par un cahier des charges

Pour que votre soumission soit la plus fidèle possible d’un prix qui ne souffrira pas de fortes fluctuations pour des imprévus, le cahier des charges qu'on attend de vous sert à une chose : qu'un développeur qui n'a pas vu votre entreprise comprenne comment les processus. Une liste rédigée un dimanche, où chaque ligne commence par « le système doit », n’est pas suffisante pour plusieurs raisons. Elle décrit le logiciel que vous imaginez, mais la compréhension du contexte est aussi pertinente pour permettre une fluidité.

Le malentendu part de là. Vous décrivez sans doute des écrans et des boutons; le développeur lit des fonctionnalités et chiffre des fonctionnalités. Les exceptions, celles qui décident du prix et du calendrier, ont peu de chances de figurer dans une liste comme celle-là, et encore moins dans le chiffre bâti dessus. Sans contexte clair, il ne pouvait pas les deviner.

En décrivant le contexte de manière bien détaillée, c’est par là qu’il faut commencer pour concevoir un logiciel sans être programmeur. La matière, c'est une journée réelle de votre entreprise, vue par la personne qui fait le travail.

Suivez une seule commande, de l'appel du client au paiement

Prenez une situation ou une problématique que votre logiciel devra adresser, ni trop simple ni trop tordue, et écrivez le maximum de contexte possible. Qui a pris l'appel, et sur quoi l'a-t-il notée? Qui a fixé le prix, avec quelle information sous les yeux? Comment la commande s'est-elle rendue au technicien, et quand l'argent est-il entré? Une ou deux pages, écrites comme vous le raconteriez à un nouvel employé, suffisent.

Nommez les postes et les documents avec leurs noms d'usage, le bon de travail ou la liste de coupe. Puis ajoutez les cas qui sont plus exceptionnels ou dérangeants. Le client qui paie en deux ou plusieurs versements et pour qui le formulaire de facturation n'a pas de case. L'ordre de production qui porte une note manuscrite « demander au contremaître ». Si chez vous une commande sur dix sort du cadre, celle-là ajoutera un écran au logiciel, et on oublie de l'écrire. Ce ne sont que quelques exemples concrets permettant d’illustrer que le contexte complet est crucial à détailler.

Faites ensuite relire l’explication du contexte par la personne qui fait l'étape suivante. Si le répartiteur et le technicien décrivent le même bon de travail de deux façons, vous venez de trouver la première chose que le logiciel devra trancher. Il vaut mieux la trancher entre vous qu'avec un développeur qui facture à l'heure.

Ce récit tient lieu de cahier des charges au départ. Ainsi la firme de développement logiciel peut le lire en quelques minutes et revenir avec des questions précises.

Choisissez ce que la première version laissera de côté

Une fois la transaction écrite, décidez ce que la première version ne fera pas. Cette décision prendra le temps d’une bonne réunion. Ce qu'elle épargne ensuite dépend de la rigueur de vos échanges dans cette réunion. Si vous n'arrivez pas à retirer quoi que ce soit de votre liste, le projet n'est peut-être pas prêt à être soumissionné.

Si vous vous trompez sur une fonctionnalité, tout n'est pas à refaire, à une condition. Cette fonctionnalité doit avoir été bâtie comme un morceau détachable, et non comme pilier central qui sera difficile de retirer. Ce que vous écartez va dans une liste datée et détaillée dans le carnet de produit (backlog), à relire une fois que la version 1 tourne depuis un mois. Avec une telle rigueur, vous vous approchez des étapes permettant de réduire les extras et les malentendus.

Une maquette répond à une question, un prototype à une autre

Une maquette est un dessin (low fidelity) des pages du logiciel, sans code derrière. Elle sert, dans un scénario d’exemple, à vérifier que le vendeur retrouve sa soumission là où il la cherche, et que le champ rempli vingt fois par jour tombe sous sa main. Un prototype cliquable enchaîne ces pages; il vérifie l'ordre des gestes, et l'apparence attendra.

Une preuve de concept (POC) ne regarde pas l'utilisateur. Elle répond à une question technique à laquelle on ne sait pas répondre de mémoire. Le système de géolocalisation des véhicules laisse-t-il un autre programme lire la position des techniciens? Le fichier de production, avec sa colonne jaune dont la signification n'est écrite nulle part, se lit-il sans erreur? Elle se paie à part et se conclut par oui ou par non.

Si les trois figurent dans la proposition, demandez quelle question chacun règle dans votre cas. Pour un outil destiné à deux employés, un avant-midi avec eux devant une feuille en dit souvent plus.

Vos données existent déjà quelque part, et ça change le projet

Si vos soumissions vivent dans un chiffrier et vos clients dans le système comptable, le nouveau logiciel ne part pas de zéro, dans notre jargon, on dit qu’il hérite. Vous aurez à décider ce qui se migre et ce qui reste relié. Relier veut dire que le logiciel parle au système comptable par une API, une porte prévue par l'éditeur pour échanger des données. Si le vôtre n'en offre pas, dites-le tôt : la connexion se fait autrement et coûte plus cher à entretenir.

Si le nouveau logiciel doit remplacer un programme maison déjà en place, le projet change de nature. Réécrire un ancien logiciel se décide avec d'autres critères, détaillés dans un article à part.

Dès que le logiciel enregistre le nom d'un client ou le cellulaire d'un technicien, la Loi 25 s'applique. Elle demande que la conception prévoie qui voit quoi, pendant combien de temps les renseignements personnels sont conservés, et où ils sont hébergés. Certains projets exigent une évaluation des facteurs relatifs à la vie privée. La Commission d'accès à l'information publie des guides; un conseiller juridique répond aux cas flous. Un logiciel n'est pas « conforme » en soi; ce que vous en faites après la livraison compte autant.

Quatre façons de faire bâtir le logiciel, et la situation où chacune convient

Une plateforme sans code (No-Code) convient à des cas simplistes comme en un formulaire et une liste : la réservation de la salle de formation, le registre des clés du garage. Elle aide si quelqu'un chez vous aime monter ses propres outils, et si les utilisateurs se comptent sur les doigts d'une main. Le développement sans code convient moins dès que les exceptions s'accumulent ou que le système comptable doit recevoir chaque facture sans intervention. Vérifiez aussi qu'un logiciel du commerce ne couvre pas déjà presque toute la transaction; où s'arrête l'outil acheté et où commence le sur-mesure fait l'objet d'un autre article.

Embaucher un développeur devient nécessaire s'il y aura du travail pour lui après la version 1. Si votre idée est un produit pour votre industrie, regardez cette option et la firme en premier : un produit se met à jour pendant des années. Un développeur seul porte tout le projet; prévoyez qui relit son code et qui le remplace l'été.

Reste la firme. Relisez votre cahier des charges ou votre petit récit : s'il compte plus de trois cas d’exception ou si un autre système doit recevoir ce qui en sort, elle passe avant les trois autres. Vous payez plus cher au départ. En échange, vous achetez une équipe au lieu d'une personne, et quelqu'un répond après la livraison.

Combien de personnes utiliseront le logiciel, et pendant combien d'années faudra-t-il y toucher? Ces deux questions sont essentielles à se poser pour évaluer le sérieux d’un bon budget pour voir à long terme sans devoir tout réécrire dans 2 ans ou moins advenant des manières d’aborder la situation avec du bricolage et des solutions No-Code non appropriées.

Ce qu'une première rencontre vérifie avant qu'une soumission soit présentée

Nous demandons deux choses avant la première rencontre : le parcours complet et le contexte de l'employé qui fera les tâches en lien avec le logiciel à tous les jours. Un accès en lecture à vos données existantes aide, sans être obligatoire. Pendant la rencontre, un programmeur de CyberPerformance lit le récit avec cette personne et l'arrête à chaque « ça dépend ». Chaque « ça dépend » est une règle d'affaires que le logiciel devra connaître, et le prix dépend du nombre de ces règles.

À la fin de la rencontre, nous sommes généralement en mesure de dire si le projet se compte en semaines ou en mois, et quel morceau bâtir en premier. Le morceau que nous vous recommandons d'attendre fait partie de la réponse. Ce que nous ne dirons pas ce jour-là c’est un montant précis. Nous allons faire une analyse plus approfondie avant de le faire pour éviter les angles morts. L'analyse des besoins commence par cette lecture.

Avant de signer, posez ces questions à toute firme que vous rencontrez, la nôtre incluse :

• Qu'avez-vous compris de mon besoin? Faites-vous la raconter; si le cas type du client qui paie en deux versements n'y est pas, le récit n'a pas été bien compris.

• Qu'enlèveriez-vous de la version 1 si le budget était coupé de moitié?

• Lequel de mes « ça dépend » réglerez-vous avant d'écrire une ligne de code?

• Si la version 1 se révèle fausse sur un point, que coûte le changement, et qui en décide?

Par où commencer pour concevoir un logiciel : la première étape, cette semaine

Avoir une bonne équipe qui vous épaulera pour votre projet pour bien encadrer votre projet est primordial. Nous avons réalisé plus de 150 projets numériques permettant de bien mettre en application les meilleures pratiques pour mener à bien la réalisation de projets complexes.

Communiquez avec nous pour planifier une rencontre Google Meet que nous puissions prendre connaissance de vos attentes dans la section Nous contacter.