Comment choisir une entreprise de développement logiciel sur mesure?

Une entreprise qui cherche un fournisseur de développement logiciel peut recevoir une proposition à 40 000 $ et une autre à 100 000 $ pour un projet qui semble identique. Pourtant, les deux firmes ne prévoient peut-être ni la même analyse, ni les mêmes tests, ni le même accompagnement après le lancement.

Le prix seul ne permet donc pas de choisir. Il faut d'abord rendre les offres comparables, puis vérifier qui comprend le besoin, qui construira réellement le logiciel et ce que l'entreprise possédera à la fin.

Ce guide peut servir de checklist pour évaluer une entreprise de développement logiciel sur mesure avant de signer un contrat.

Que votre recherche vise une firme de développement logiciel à Montréal, ailleurs au Québec ou entièrement à distance, les mêmes critères s'appliquent : la proximité géographique ne remplace ni la transparence ni l'accès à l'équipe qui réalisera le mandat.

Définir son besoin avant de contacter des firmes

Vous n'avez pas besoin d'un cahier des charges de 100 pages. Une spécification trop détaillée, rédigée avant toute discussion technique, peut même enfermer le projet dans une solution imaginée trop tôt.

Vous devez néanmoins pouvoir expliquer huit éléments :

• le problème d'affaires à résoudre;
• les personnes qui utiliseront le logiciel;
• la façon dont le travail est effectué aujourd'hui;
• les fonctions absolument nécessaires;
• les systèmes, fichiers et équipements déjà en place;
• les intégrations et données à reprendre;
• les contraintes de sécurité, de terrain, de calendrier ou de conformité;
• le résultat attendu et la façon de reconnaître qu'il est atteint.

Par exemple, « nous voulons un nouveau système de gestion » reste trop large. « Nos planificateurs recopient chaque commande dans trois fichiers, puis le contremaître réorganise la production à la main » donne à la firme un processus qu'elle peut observer, mesurer et améliorer.

Séparez aussi les besoins essentiels des idées souhaitables. Une première version doit accomplir un parcours utile de bout en bout. Les fonctions secondaires pourront être priorisées lorsque les utilisateurs auront validé la base.

Vérifier si la firme comprend réellement le problème d'affaires

Une bonne firme de développement logiciel ne devrait pas transformer immédiatement votre liste de fonctions en jours de programmation. Elle devrait chercher à comprendre pourquoi chaque demande existe.

Supposons qu'un dirigeant demande une application mobile pour permettre aux employés de remplir des formulaires sur le terrain. Le fournisseur qui acquiesce sans poser de questions peut chiffrer deux applications et leur publication dans les boutiques. Une équipe qui analyse le contexte pourrait découvrir qu'une application web responsive avec un mode hors ligne répond au besoin avec moins de surfaces à maintenir. Notre comparatif application web ou application mobile explique précisément cet arbitrage.

À l'inverse, la discussion pourrait révéler une utilisation intensive du Bluetooth ou du GPS en arrière-plan qui justifie réellement le mobile. Challenger une demande ne signifie pas toujours la réduire; cela signifie relier la solution au besoin réel.

Observez les questions posées pendant les premières rencontres :

• La firme demande-t-elle de voir un cas concret?
• Cherche-t-elle les exceptions et les conséquences d'une erreur?
• Distingue-t-elle le symptôme de sa cause?
• Propose-t-elle des options avec leurs compromis?
• Est-elle capable de dire qu'un produit existant suffirait?

Une compagnie de développement logiciel qui ne parle que de technologie avant de comprendre les opérations risque de construire correctement la mauvaise chose.

Vérifier les compétences techniques sans comparer des listes de frameworks

Un acheteur non technique n'a pas à décider si un framework est supérieur à un autre. Il doit plutôt vérifier si les choix proposés sont adaptés, maintenables et expliqués clairement.

Demandez à chaque prestataire de décrire :

• l'architecture générale et la séparation des responsabilités;
• les technologies utilisées et la disponibilité future de développeurs;
• la gestion des comptes, rôles et données sensibles;
• l'expérience avec les API et systèmes à intégrer;
• l'approche pour la base de données et la migration;
• l'hébergement, les sauvegardes et la surveillance;
• la stratégie web, mobile ou hors ligne lorsque pertinente;
• la façon dont une autre équipe pourrait reprendre le logiciel.

La réponse devrait être compréhensible. « Nous choisissons cette technologie parce qu'elle convient à vos intégrations, que notre équipe la maîtrise et que le marché permet de la maintenir » est plus utile qu'un défilé d'acronymes.

L'expérience pertinente n'exige pas que la société de développement logiciel ait déjà construit exactement votre produit. Une équipe ayant relié un ERP à des équipements industriels peut être mieux préparée à votre risque d'intégration qu'une firme ayant livré un écran visuellement semblable sans contrainte technique comparable.

Demander qui développera réellement le logiciel

La personne qui vend le projet ne sera pas nécessairement celle qui l'analyse ou le développe. Avant de choisir une agence de développement logiciel, demandez :

• si l'équipe est composée d'employés, de sous-traitants ou des deux;
• où se trouvent les personnes affectées au mandat;
• leur niveau de séniorité et leur rôle;
• qui sera votre interlocuteur principal;
• combien de projets elles mènent simultanément;
• si les mêmes personnes resteront jusqu'au déploiement;
• qui prendra les décisions d'architecture;
• qui interviendra après le lancement.

La sous-traitance n'est pas automatiquement un problème. Elle peut donner accès à une expertise rare. Le risque apparaît lorsque le fournisseur ne sait pas qui sera disponible, ne supervise pas le travail ou présente une équipe senior pendant la vente avant de transférer le mandat à des ressources que le client n'a jamais rencontrées.

Demandez à rencontrer les personnes clés avant de signer. Une conversation de 30 minutes permet souvent de vérifier si elles comprennent le contexte et peuvent communiquer sans jargon inutile.

Petite ou grande firme de développement logiciel : quelle taille choisir?

Le nombre d'employés n'est pas un indicateur direct de qualité. La taille influence surtout la capacité, la spécialisation et le nombre de couches entre le client et l'équipe technique.

Ce qu'une grande firme peut apporter

Une grande firme dispose souvent de plus de ressources, de plusieurs spécialités internes et de processus structurés. Elle peut mobiliser plusieurs équipes, remplacer plus facilement une personne indisponible et prendre en charge un programme qui combine de nombreux systèmes, unités d'affaires et exigences de conformité.

Le compromis possible est la distance avec les développeurs. Dans certaines organisations, le parcours ressemble à ceci :

Client → chargé de projet → analyste → développeur

Imaginez qu'un directeur de production explique au chargé de projet pourquoi certaines commandes doivent rester ensemble malgré une règle habituelle d'optimisation. L'information devient ensuite une exigence fonctionnelle. Le développeur reçoit la tâche sans avoir entendu les exceptions, les exemples et le coût d'une mauvaise séparation. Le résultat peut respecter la phrase écrite tout en ratant le véritable besoin opérationnel.

Une bonne grande firme évite ce problème par des ateliers bien menés, une documentation claire et un accès direct aux spécialistes lorsque nécessaire. Il faut donc évaluer son fonctionnement réel, pas présumer que sa taille crée forcément des silos.

Ce qu'une petite ou moyenne firme peut apporter

Une équipe plus petite offre souvent un accès direct aux développeurs, moins d'intermédiaires et une transmission plus rapide du contexte. La personne qui écrit le code peut demander directement au responsable des opérations pourquoi une règle existe et proposer une solution différente.

Cet accès est particulièrement utile en développement logiciel sur mesure. Le travail ne consiste pas seulement à programmer une tâche; il faut comprendre les exceptions, anticiper les impacts et arbitrer avec le client.

Une petite firme présente aussi des risques à vérifier : moins de ressources disponibles simultanément, une dépendance envers certaines personnes clés, moins de spécialités internes ou une capacité limitée pour un programme qui exige plusieurs équipes en parallèle.

Petite firme et freelance ne sont pas synonymes

Un développeur logiciel sur mesure indépendant peut être excellent et convenir à un mandat ciblé. Le risque de continuité demeure toutefois concentré sur une personne.

Une petite firme structurée peut conserver le contact direct tout en offrant plusieurs développeurs, de la révision de code, une gestion de projet, des expertises complémentaires et une relève pour la maintenance. Demandez des preuves de cette structure plutôt que de vous fier au nombre d'employés affiché.

Ces tendances ne remplacent pas l'évaluation. La question décisive est : avec qui vais-je communiquer pendant le développement et pourrai-je parler directement aux développeurs qui travaillent sur mon projet?

Vérifier la propriété du code source et des accès

La propriété intellectuelle doit être écrite dans le contrat, pas supposée. Vérifiez qui possède :

• le code développé spécifiquement pour votre projet;
• les composants génériques ou antérieurs utilisés par la firme;
• les maquettes, la documentation et les scripts de déploiement;
• le nom de domaine et les certificats;
• les comptes cloud, les bases de données et les sauvegardes;
• les comptes des services externes;
• les clés de publication Apple et Google, si applicable.

Demandez où le dépôt Git sera hébergé et si votre entreprise y aura accès pendant le mandat. Précisez aussi la procédure pour récupérer le code, les données, les variables de configuration et les instructions de déploiement.

Recevoir une archive de code à la fin ne suffit pas toujours. Si l'infrastructure, les comptes et la connaissance du déploiement restent entièrement chez le fournisseur, le changement de prestataire peut demeurer très difficile.

Une firme peut légitimement conserver la propriété de ses outils réutilisables ou utiliser des composants sous licence. L'objectif n'est pas d'exiger tous ses actifs internes, mais de s'assurer que vous pouvez exploiter, maintenir et transférer votre logiciel sans verrouillage artificiel.

Comparer correctement les soumissions de développement logiciel

Deux estimations ne couvrent pas nécessairement le même produit ni les mêmes responsabilités. Avant de comparer les totaux, alignez les inclusions.

Une soumission de développement logiciel devrait préciser le traitement de :

• l'analyse fonctionnelle;
• les maquettes UX/UI;
• le développement du frontend et du backend;
• les intégrations et la migration des données;
• les tests automatisés et manuels;
• la gestion de projet et les rencontres;
• la sécurité et les permissions;
• les environnements, le déploiement et l'infrastructure;
• la formation et la documentation;
• la période de garantie ou de correction;
• la maintenance après le lancement;
• les licences et services tiers.

Demandez les hypothèses. Une estimation peut supposer que vos données sont propres, que l'API d'un partenaire est bien documentée ou que votre équipe fournit les textes et validations dans un délai précis. Si cette hypothèse est fausse, le prix et l'échéancier changent.

Une grille d'évaluation pour comparer trois fournisseurs

Notez chaque critère de 1 à 5, puis ajoutez un commentaire factuel. Les critères critiques — propriété, sécurité ou continuité, par exemple — peuvent recevoir un poids plus élevé selon votre projet.

Une note sans preuve est une impression. Ajoutez une référence au contrat, à une réponse écrite, à une démonstration ou à un projet vérifiable.

Forfait ou taux horaire?

Le forfait convient lorsque la portée est claire, stable et vérifiable. Il donne de la prévisibilité, mais oblige la firme à inclure une marge pour les risques. Toute zone non définie peut ensuite devenir une exclusion ou une demande de changement.

Le taux horaire convient mieux à une découverte, une reprise de système inconnu ou un produit qui doit évoluer à partir des apprentissages. Il offre de la flexibilité, mais exige de la transparence sur le temps, les priorités et le budget restant.

Une approche hybride est fréquente : analyse initiale à effort contrôlé, estimation d'une première portée, puis développement par incréments avec des points de décision. Aucun modèle n'est automatiquement plus honnête. Ce qui compte est de savoir qui porte le risque lorsque l'information manque et comment les changements sont approuvés.

Attention à la soumission la moins chère

Une petite équipe efficace peut être moins chère qu'une grande firme et livrer un excellent résultat. Le prix inférieur n'est donc pas un red flag en soi.

Il doit toutefois être expliqué. L'écart peut provenir :

• d'un périmètre plus étroit;
• d'une analyse, d'un design ou d'une QA moins poussés;
• d'hypothèses optimistes sur les données et intégrations;
• d'une architecture conçue pour le lancement, sans marge d'évolution;
• d'éléments reportés à des frais ultérieurs;
• d'un taux plus bas ou de moins d'intermédiaires;
• d'une réutilisation légitime de composants éprouvés.

Demandez au fournisseur le moins cher ce qu'il ferait avec 20 % de budget supplémentaire, et au plus cher ce qu'il retirerait pour réduire le coût. Leurs réponses révèlent souvent les différences de portée mieux qu'une comparaison ligne par ligne.

Combien coûte le développement d'un logiciel sur mesure?

Le coût de développement d'un logiciel sur mesure varie fortement selon :

• le nombre et la complexité des parcours;
• le nombre d'interfaces et de rôles;
• les intégrations avec d'autres systèmes;
• la qualité et le volume des données à migrer;
• la présence d'applications mobiles;
• les exigences de sécurité et de conformité;
• le volume d'utilisateurs et de transactions;
• l'infrastructure et la disponibilité requise;
• le niveau de finition, de tests et de documentation.

Un nombre d'écrans ne suffit pas pour établir le prix. Un formulaire simple relié à cinq systèmes peut coûter davantage qu'un tableau de bord visuellement complexe alimenté par une seule base bien structurée.

Notre analyse détaillée du coût d'un logiciel sur mesure au Québec présente des fourchettes tirées des projets que DevActif chiffre et livre. Pour comparer des firmes, utilisez surtout les mêmes hypothèses et demandez le coût total sur plusieurs années : développement, hébergement, licences, maintenance et évolutions probables.

Demander comment le logiciel sera maintenu après le lancement

La mise en production commence la vie utile du logiciel; elle ne la termine pas. Demandez qui prendra en charge :

• les correctifs et incidents;
• les mises à jour de dépendances;
• la correction des vulnérabilités;
• les sauvegardes et les tests de restauration;
• la surveillance de l'application;
• les changements des services externes;
• les nouvelles fonctionnalités;
• les délais de réponse ou SLA lorsque les opérations l'exigent.

Une application interne utilisée durant les heures de bureau n'a pas le même besoin de soutien qu'une plateforme transactionnelle disponible en tout temps. Le niveau de service doit suivre l'impact d'une panne, pas une formule universelle.

Vérifiez aussi ce qui est documenté et combien de personnes peuvent intervenir. Notre guide sur le coût de maintenance d'un logiciel sur mesure détaille ce budget souvent oublié.

Vérifier les références et les projets comparables

Une bonne référence permet de valider la collaboration, la capacité de livraison et la tenue du logiciel après son lancement. Demandez depuis combien de temps le système est en service, comment les changements ont été gérés et si le client retravaillerait avec la firme.

Ne cherchez pas seulement un logiciel identique au vôtre. Comparez les risques :

• intégration avec un ERP ancien;
• travail hors ligne sur le terrain;
• migration de données difficiles;
• permissions complexes;
• reprise d'un code existant;
• volume élevé ou disponibilité critique.

Une firme qui comprend le même type de difficulté peut être plus pertinente qu'une autre qui connaît le secteur, mais n'a jamais affronté la contrainte centrale du projet.

Les questions à poser à une firme de développement logiciel

Utilisez ces questions pendant les rencontres et demandez que les réponses importantes apparaissent dans la proposition ou le contrat.

1. Qui travaillera réellement sur notre projet, et combien de personnes seront affectées?
2. Pourrons-nous rencontrer les développeurs avant le début du mandat?
3. Les développeurs participent-ils aux rencontres où les besoins sont définis?
4. Pourrons-nous communiquer directement avec eux lorsqu'une règle est ambiguë?
5. Utilisez-vous des sous-traitants, et comment leur travail est-il supervisé?
6. Les mêmes développeurs resteront-ils sur le projet?
7. Comment évitez-vous la perte d'information entre le client, le chargé de projet et les développeurs?
8. Comment estimez-vous le projet et quelles hypothèses soutiennent le montant?
9. Qu'est-ce qui n'est pas inclus dans votre estimation?
10. Comment gérez-vous les changements de portée et leur approbation?
11. Comment testez-vous le logiciel avant chaque mise en production?
12. Qui sera propriétaire du code et aurons-nous accès au dépôt Git?
13. Qui possédera les comptes cloud, les données et les services externes?
14. Comment gérez-vous les vulnérabilités, les mises à jour et les sauvegardes?
15. Que se passe-t-il après la mise en production?
16. Comment documentez-vous l'architecture, le déploiement et les décisions importantes?
17. Pourrions-nous confier le logiciel à une autre firme éventuellement?
18. Quels sont les principaux risques que vous voyez dans notre projet?

La dernière question est particulièrement révélatrice. Une réponse crédible nomme des inconnues précises et propose une façon de les réduire. « Aucun risque, nous avons déjà tout fait » devrait inquiéter davantage que l'aveu d'une incertitude bien encadrée.

Les red flags avant de choisir un prestataire

Un signal d'alarme mérite une vérification; il ne condamne pas automatiquement le fournisseur.

• Une estimation ferme sans véritable analyse. Elle peut convenir à un mandat minuscule et connu. Pour un système complexe, elle cache probablement des hypothèses ou des changements futurs.
• Le refus de donner accès au code. Une licence ou un produit propriétaire peut l'expliquer, mais le contrat doit alors exposer clairement la dépendance.
• Une infrastructure entièrement contrôlée par le fournisseur. Un service géré peut être pratique; l'absence de procédure de transfert ne l'est pas.
• La dépendance à une seule personne. Demandez qui révise le code et qui intervient si elle est indisponible.
• Aucune stratégie de tests. « Les développeurs testent en programmant » ne remplace pas des critères, des environnements et une validation structurée.
• Aucune discussion sur la maintenance. Le logiciel devra recevoir des correctifs et suivre ses dépendances après le lancement.
• Des réponses vagues sur la sécurité. La firme devrait pouvoir expliquer les accès, les sauvegardes et la protection des données sans promettre une sécurité absolue.
• Une technologie choisie seulement par habitude. La maîtrise interne compte, mais le choix doit aussi convenir à la durée de vie, aux intégrations et au recrutement futur.
• Des délais irréalistes. Une livraison très rapide peut être possible avec une portée réduite. Elle doit laisser du temps pour les validations, les données et le déploiement.

L'approche de DevActif

DevActif développe des logiciels sur mesure pour des entreprises québécoises. Notre objectif n'est pas de maximiser la taille du projet, mais de trouver la solution la plus simple qui répond au besoin et qui pourra être maintenue.

Cela peut mener à un ERP ou logiciel de gestion sur mesure, à une application web, à une application mobile, à une intégration ciblée ou à la reprise d'un logiciel existant. Il nous arrive aussi de recommander un produit du marché lorsque le développement ne se justifie pas.

Le point important demeure le même pour DevActif comme pour les autres fournisseurs que vous évaluez : demandez qui comprend votre besoin, qui prendra les décisions techniques, qui écrira le code et comment vous garderez le contrôle de votre logiciel.

Vous comparez actuellement des firmes pour un projet? Présentez-nous votre besoin. Nous pouvons vous aider à clarifier l'approche, la portée et les principaux risques avant de commencer le développement.