Développement de logiciels sur mesure : quelle part bâtir

Développement de logiciels sur mesure pour entreprise : ce qu'on bâtit, ce qu'on garde

La phrase a peut-être été lancée à la fin d'une réunion de production, ou dans le camion entre deux chantiers. « On ne peut plus continuer comme ça avec les outils qu'on a. » Depuis, la question circule dans votre entreprise, du bureau à l'atelier, sous une forme qui paraît simple. On achète un logiciel, ou on en fait bâtir un?

Le sur-mesure ne dépend pas de votre taille, mais d'une part de votre travail

Une entreprise de douze employés a parfois une part de travail qu'un éditeur de logiciels n'a pas de raison de programmer. Le sur-mesure sert cette part-là, celle qui n'existe que chez vous.

Un logiciel à visée commercial est écrit pour ce que des milliers d'entreprises aient leurs besoins répondus avec beaucoup de fonctionnalités. La comptabilité et la paie en sont quelques exemples. Sur certains cas précis, il fait mieux, et pour moins cher, que ce qu'on pourrait vous bâtir; alors nous n'y toucherons pas.

Le reste, comme chez beaucoup de PME, est une couche formée autour des logiciels. Des fichiers Excel calculent ce que l'ERP ne sait pas de vos machines, et des courriels à la pièce représentent des approbations. Les ajustements manuels et petites techniques pour utiliser de manières optimales le grand logiciel populaire, eux, s'enseignent au nouvel employé une fois la formation officielle terminée.

Quelle opération, dans votre entreprise, ne se fait pas comme chez des entreprises semblables?

Des procédures qu’une seule personne est responsable dans votre entreprise peuvent être automatisées ou être plus faciles à opérer. Aussi, si elle occupe plusieurs personnes pour l'opération pour laquelle vos clients vous choisissent, vous êtes devant la partie qui vaut la peine d'être revue. Le développement de logiciels sur mesure coûte les frais de développement au départ, avant d'avoir vu un seul écran; l'abonnement SAAS s'étale par mois. En échange, le logiciel fait ce que vous avez décrit et de manière plus fluide, avec les fonctions désirées, les procédures de votre choix et plein d’autres avantages.

Remplacer le logiciel, ou bâtir ce qui lui échappe : comment on tranche

Quand un logiciel existant couvre presque tout le besoin, on bâtit le morceau qui reste et on le branche dessus. Remplacer vient en dernier recours.

Le branchement passe par une API, l'interface par laquelle un logiciel accepte qu'un autre lui parle. La plupart des logiciels loués par abonnement en offrent une. Deux questions la concernent : existe-t-elle, et laisse-t-elle écrire autant que lire dans les permissions API?

Prenez les listes de prix par client. Chez vous, elles vivent peut-être en pièces jointes datées dans la boîte de réception des représentants; le logiciel de facturation n'est pas en cause. Des ententes qui dépendent du volume de l'année sont une règle à vous. On la programme dans un petit module qui calcule le prix et l'écrit dans la facture par l'API. Le compromis : ce morceau dépend de l'API de l'éditeur, qui fait évoluer son produit et permet ou pas d’avoir des accès tiers supplémentaires.

Quand la couche développée dépasse le logiciel lui-même, le remplacement passe devant. Si le bureau planifie les livraisons de la semaine dans un agenda papier et n'ouvre le logiciel que pour facturer, le vrai système est l'agenda. Et si le logiciel qui déborde est lui-même un programme maison, la question devient celle de la modernisation, qui suit un autre raisonnement.

Qu'est-ce qui serait perdu si le logiciel actuel disparaissait demain matin? Généralement, si la réponse tient en deux lignes, remplacez. Si elle prend une page, complétez.

Sept signes que les heures se perdent à côté de vos logiciels

Plusieurs signes indiquent que votre solution actuelle est à repenser, en voici quelques exemples:

• Le chiffrier de planification est réimprimé en début de semaine parce que l'ordre réel de passage sur les machines n'a pas été entré dans l'ERP.

• Les estimateurs prennent leur numéro de soumission dans un cahier partagé, pour que deux personnes ne sortent pas le même numéro le même jour.

• La colonne « commentaires » du CRM sert d'état d'avancement des dossiers, en abréviations qu'il faut se faire expliquer.

• Le bureau rappelle les contremaîtres le jeudi pour savoir qui était sur quel chantier, parce que les heures de route ne s'écrivent nulle part.

• La facture part seulement quand le chauffeur rapporte le bon de livraison au bureau, parfois le surlendemain.

• Les techniciens sur la route appellent le bureau pour savoir si une pièce est en stock, parce que l'inventaire ne se lit qu'au comptoir.

• Un rappel au calendrier du directeur des opérations sert à vérifier à la main les pièces dont le seuil de commande change avec la saison.

• Deux de ces signes justifient de compter les heures. À partir de cinq, c’est un signe évident qu’il faut refaire votre logiciel.

• Un de ces signes peut aussi vouloir dire qu'une fonction de votre logiciel actuel dort, ou que la formation aux employés s'est arrêtée trop tôt. Nous vérifions cela avant de proposer quoi que ce soit, parce que c'est moins cher que nous.

Ce qui fait monter le prix, dans l'ordre où nous le regardons

Au téléphone, nous ne donnons pas de prix sans diagnostic complet. Nous analysons l’ampleur du travail, ses différents facteurs à considérer, le niveau d’intégration à prévoir, les languages à utiliser pour parler à votre écosystème de logiciels autres à faire communiquer et pleins d’autres facteurs.

D'abord, le nombre de systèmes à connecter. Une intégration de systèmes se programme deux fois : une pour le cas normal et l’autre pour les cas où il y aurait un arrêt de fonctionnement partiel ou complet. Quand le système comptable ne répond pas pendant une heure, les commandes doivent attendre dans une file et repartir seules ensuite, sans doublon. Ce travail-là n'apparaît pas dans la maquette et pèse dans le prix.

Ensuite, les exceptions. Une règle d'approbation d'achat avec deux exceptions, c'est trois chemins à programmer et à tester. Une exception qui arrive trois fois l'an peut rester manuelle. Puis les données à reprendre, si vos historiques de prix ont changé de format au fil des années, on décide avec vous ce qu'on garde. Enfin, qui teste? Selon le cas, des données fictives peuvent être mises en test ou un échantillon de vos vraies données.

Deux choses font baisser le prix : un besoin bien délimité, et un logiciel actuel dont l'API est documentée.

Le développement de logiciels sur mesure se paie d'abord en heures de vos gens

Pendant le projet, la feuille de temps qui grossit est celle de votre testeur interne, et elle compte autant que notre facture. Ce testeur reçoit les questions du développeur comme par exemple pourquoi la soumission numéro 4 a-t-elle deux taux de main-d'œuvre? Il essaie une livraison avant que le développeur commence la suivante, et il tranche quand une règle a plus d'exceptions que prévu.

Sans lui, le développeur suppose sans avoir de réelles validations. La supposition se corrige plus tard, et la correction coûte plus que la réponse. Selon le mandat, comptez pour cette personne quelques heures par semaine pendant le développement, puis des journées entières aux tests de la première livraison.

La personne la mieux placée est souvent celle qui a le moins de temps soit le directeur des opérations, ou le contremaître qui connaît les machines. Qui, dans votre équipe, peut répondre à une question de développeur dans la journée sans que la production en souffre?

Après la livraison, quelqu'un chez vous devient la personne ressource pour faire le bilan des fonctions à ajouter pour soit des exceptions qui n’avaient pas été pensées ou des fonctions permettant une meilleure efficience qui n’avaient pas été pensées ou demandées.

Développement stratégique par MVP / POC

On ne bâtit pas le logiciel entier avant de vous le montrer. On découpe le mandat en tranches, et la première contient une seule tâche : celle où les heures partent.

Avant de commencer, une preuve de concept (POC), un montage jetable qui vérifie un point technique, répond à la question qui fait peur. Est-ce que votre ERP accepte qu'on écrive dedans, avec vos vraies données, sans casser la facturation? Ce montage se paie, et il fait partie de notre proposition globale. En échange, vous savez si le branchement tient avant de vous engager sur le reste.

La seconde version arrive ensuite en version utilisable, et nous demandons à votre testeur de la faire essayer, la semaine même, par les employés qui font la tâche. Les livraisons viennent avec leurs tests automatisés, des programmes qui rejouent les cas connus à chaque modification du code. Quand une règle change, le test de la règle précédente avertie avant vos employés, pour les cas qu'il connaît.

Ce que l'entente doit écrire sur le code et sur vos données

Le code source vous revient, selon les modalités de notre contrat, dans un dépôt à votre nom : l'espace en ligne où il est conservé et suivi.

Posséder le code ne suffit pas à le reprendre. Pour qu'une autre équipe s'en charge un jour, quatre choses doivent exister.

Un langage que les développeurs pratiquent couramment. Une documentation qui dit comment installer le logiciel sur un nouveau serveur ou ordinateur. Les accès à l'hébergement et au dépôt. Un historique des modifications lisible, ce que Git fait de lui-même.

Où le logiciel tourne est une décision et pas un détail. Sur un serveur chez vous, ou en infonuagique (cloud), c'est-à-dire sur des serveurs loués dans un centre de données, souvent au Canada.

Héberger hors Québec reste permis. La Loi 25 demande, avant de le faire, une évaluation des facteurs relatifs à la vie privée dès que des renseignements personnels sont en jeu. Si votre situation est celle-ci, nous concevrons en tenant compte de ces obligations : qui accède à quoi, et où se situent les copies de sauvegarde. Pour le reste, votre responsable de la protection des renseignements personnels ou la Commission d'accès à l'information (CAI) sont les bons interlocuteurs.

Reste la maintenance. Avec un forfait prévu soit à la signature initiale ou ultérieurement, l'éditeur du logiciel applique les correctifs de sécurité. Avec un logiciel à vous, quelqu'un doit les appliquer, parce que les bibliothèques, ces morceaux de code tiers dont le vôtre dépend, en reçoivent toute l'année. C'est une dépense récurrente, chez nous ou chez une autre firme, et elle fait partie du prix réel du sur-mesure. Demandez à qui vous parlez ce qui arrive si une bibliothèque change et que le logiciel cesse de démarrer un lundi.

Les éléments qu’on a besoin pour faire une bonne soumission pour votre logiciel sur mesure

Vous devriez vous poser les questions suivantes:

• Qu'est-ce que vous me conseillez de garder dans mes outils actuels? Une réponse utile nomme des fonctions précises et dit pourquoi.

• Qu'est-ce qui, dans mon projet, coûtera plus cher que je le pense? Attendez-vous à entendre le nom d'une intégration ou d'une exception précise.

Prévoir une rencontre pour parler de votre projet

Nous serions heureux de participer à la réussite de votre projet de logiciel sur mesure et nous vous proposons une rencontre de 30 à 60 minutes pour en discuter sans obligation. Demandez votre rencontre ou votre soumission avec notre formulaire de contact.