Choisir une entreprise de développement logiciel au Québec : comparer trois soumissions

Une demande de soumission ne doit pas déjà contenir toutes les réponses techniques. Elle doit décrire ce qui se passe aujourd’hui, ce qui doit changer et les limites que le projet devra respecter. Pour un distributeur québécois, cela peut être : recevoir une commande, confirmer le stock, réserver les articles et transmettre les informations à la comptabilité, avec un responsable désigné pour chaque exception.

Fournissez un petit dossier commun : description des utilisateurs, parcours principal, systèmes à connecter, exemples anonymisés de données et contraintes de disponibilité. Indiquez ce qui demeure inconnu. Un fournisseur sérieux peut proposer de lever ces inconnues pendant une étape de découverte, plutôt que d’enfouir une réserve dans le prix.

Demandez ensuite une réponse dans le même ordre : compréhension du problème, périmètre inclus, hypothèses, exclusions, livrables, critères d’acceptation, équipe, calendrier, dépendances et maintenance. Ce format réduit la place des présentations commerciales qui ne répondent pas aux contraintes de votre organisation.

Cette grille est une méthode éditoriale, pas une certification des fournisseurs. Elle doit être adaptée à votre contexte. Une application utilisée pendant les heures de bureau n’appelle pas les mêmes engagements qu’un système qui bloque des expéditions pendant une panne.

L’équipe de développement doit pouvoir expliquer comment elle maintient le système après la première livraison. La démonstration d’un prototype est utile; elle ne prouve ni la restauration des données, ni la capacité de reprise par une autre équipe.

Définissez vos priorités avant d’ouvrir les propositions. Utilisez la même échelle de zéro à cinq pour tous les critères, comme dans la grille pondérée ci-dessous. Une affirmation seule mérite moins de points qu’une démonstration sur votre scénario accompagnée d’une responsabilité écrite. Pondérez ensuite selon le risque réel du projet.

Gardez un commentaire à côté de chaque note. « Trois points pour la migration » n’aide pas une direction à décider; « une répétition sur copie des données est incluse, avec contrôle des montants et test des relations clients-commandes » explique ce qui a été évalué. Les désaccords entre TI, opérations et finance deviennent alors discutables.

Un score total élevé ne doit pas effacer un critère éliminatoire. Si vous avez besoin d’exporter toutes les données et que la proposition ne prévoit aucune sortie utilisable, l’écart mérite d’être résolu avant de signer. De même, l’absence d’une personne disponible pour valider les processus chez vous peut retarder les trois fournisseurs.

Prévoyez une rencontre centrée sur un parcours concret. Par exemple : une commande contient un article devenu indisponible, le représentant modifie la quantité et la comptabilité a déjà reçu une première version. Demandez qui possède l’information, comment une modification est propagée et comment un employé comprend l’état final.

Observez la manière dont les équipes posent des questions. Cherchent-elles à comprendre le processus ou proposent-elles immédiatement un outil? Peuvent-elles expliquer un compromis sans jargon? Reconnaissent-elles les risques et la nécessité d’un essai? Cette rencontre vous renseigne sur la collaboration quotidienne, qui compte autant que la pile technologique.

Pour l’accessibilité, les ressources du W3C recommandent d’intégrer la démarche à la planification et aux responsabilités du projet. Dans votre demande, traduisez cet objectif en parcours utilisables au clavier, messages compréhensibles et vérification avec les profils concernés. Ne présumez pas qu’une interface moderne est automatiquement accessible.

Le coût initial est une partie du coût total. Comparez aussi les environnements, services tiers, licences, support, formation, correctifs et évolutions. Demandez ce qui se passe si un service externe change son interface ou si une personne clé quitte l’équipe. Faites distinguer les coûts fixes, les coûts d’usage et ceux qui dépendent d’un changement de périmètre.

Illustration fictive : une proposition moins chère peut exclure le nettoyage des données et prévoir chaque reprise comme un travail additionnel. Une proposition plus élevée peut couvrir une répétition de migration et deux ateliers d’acceptation. Cela ne rend pas la seconde automatiquement meilleure; cela révèle que les prix ne portent pas sur la même livraison.

Ne construisez pas un rendement fictif à partir d’une économie annoncée. Mesurez d’abord le temps actuel, le volume concerné et les exceptions. Une amélioration sur un parcours rare peut être moins prioritaire qu’un petit changement utilisé quotidiennement par toute l’équipe.

Demandez où vivent le code, les données, les environnements et les accès. Clarifiez les comptes appartenant à votre entreprise et les services exploités par le fournisseur. La transmission doit couvrir le déploiement, les sauvegardes, les dépendances, les incidents connus et les étapes permettant de remettre le système en marche.

OWASP documente notamment les risques d’autorisation et d’accès aux ressources dans les API. Pour un projet intégré, demandez quels droits possède chaque connexion, comment ils sont réduits et comment les événements sensibles sont examinés. Cette discussion doit déboucher sur des contrôles observables, pas sur une promesse de sécurité absolue.

Enfin, comparez la décision de construire avec les autres options. Notre cadre application sur mesure ou SaaS aide à déterminer ce qui mérite réellement d’être développé. Le meilleur partenaire peut être celui qui réduit le périmètre initial à une première livraison utile.

Voici un modèle de travail proposé par Daillac, à adapter au projet. Les poids ci-dessous sont un exemple de décision, pas un classement des agences. Attribuez une note de zéro à cinq : zéro signifie aucune réponse; un, une affirmation; trois, une démonstration partielle; cinq, une preuve sur votre scénario et une responsabilité écrite. La contribution au total est le poids multiplié par la note, divisé par cinq. Faites noter les propositions séparément par les opérations et les TI avant de discuter des écarts.

Un score ne compense pas un blocage essentiel. Si la reprise des données est indispensable et exclue de la proposition, demandez un complément avant de noter. Conservez une colonne de commentaire dans votre propre feuille : « preuve reçue », « hypothèse » ou « question ouverte ». Une case vide reste une inconnue, plutôt qu’une note moyenne attribuée par défaut.

Imaginons un distributeur québécois qui veut remplacer ses suivis de commandes par une application interne. A propose 40 000 $ CA avec les écrans, mais sans migration; B propose 55 000 $ avec une reprise documentée; C propose 48 000 $ avec un connecteur dont les exceptions restent à préciser. Ces montants sont entièrement fictifs et ne constituent pas un barème Daillac. Le scénario comprend la création d’une commande, une modification après validation et la reprise de cinq années d’historique.

Avec les critères dans l’ordre de la grille, A reçoit 4, 2, 3, 4, 2, 3; B reçoit 4, 4, 4, 3, 4, 4; C reçoit 4, 3, 3, 4, 3, 3. Les totaux sont respectivement 62, 77 et 68 sur 100. B obtient le meilleur total provisoire, mais le choix dépend encore des exclusions et du coût complet. A peut améliorer sa proposition en chiffrant la migration; C doit montrer la reprise après échec du connecteur. On compare donc aussi une version clarifiée de chaque offre.

Avant d’arbitrer, demandez à chaque équipe les mêmes coûts supplémentaires : migration, licences, exploitation sur deux ans et changements hors périmètre. N’additionnez pas des estimations internes à une seule soumission : appliquez la même méthode aux trois. Le résultat attendu de la réunion est une liste d’écarts à lever et une décision justifiée, pas une moyenne qui donne une impression de précision.

W3C WAI — Planning and managing accessibility · OWASP — API Security Top 10, édition 2023. Sources consultées le 1er octobre 2026; les grilles et exemples de décision sont une analyse éditoriale de Daillac.