Recharge de la carte OPUS | Un étudiant dame le pion à l’ARTM
www.lapresse.ca
Les utilisateurs des transports en commun le réclament depuis des années. C’est finalement un étudiant de l’Université McGill qui a réussi à programmer un logiciel permettant de recharger la carte OPUS en ligne directement avec son téléphone cellulaire.

Au-delà de la joke la plus complète que représente ce dossier, ce paragraphe me fâche le plus:

Cette prouesse informatique survient alors que l’Autorité régionale de transport métropolitain (ARTM) vient d’accorder 1,13 million à l’entreprise parisienne Spirtech pour développer une application semblable. À la clé, le contrat prévoit des redevances versées sur chacune des quelque sept millions de transactions annuelles projetées pour l’achat de titres de transport sur mobile.

Veux-tu me dire, ciboire, pourquoi on est pas capable de trouver une compagnie québécoise pour faire ça? C’est pas comme si le projet demandait des experts ultra spécialisés et rares. Pourquoi un projet qui peut potentiellement générer beaucoup de profits (avec les redevances) ne trouve pas preneur ici? Tk, tout ce dossier est tellement risible…

  • Bob@sh.itjust.works
    7·
    10 months ago

    Je peux pas croire que ça a pris 3 mois a une seule personne pour faire une application qui fonctionne, dans son temps libre alors que l’ARTM font faire ça par une compagnie étrangère pour 1M$ + des frais de transaction. Ou va cet argent la??

    A la place de lui demander de supprimer son repo GitHub ils auraient pas pu juste l’engager pour diriger une équipe locale pour développer et maintenir ce système la? Ça serait moins cher et ça contribuerait à la société tsé… Mais ils ont sûrement un contrat et des chums qu’ils veulent pas perdre donc ils vont rien changer

    • swan_pr@lemmy.caOP
      3·
      10 months ago

      Ben, y a une différence entre ce que l’étudiant a réalisé et les besoins de l’ARTM quand même. On parle de millons de transactions par année et toute l’infra nécessaire pour offrir le service et le supporter.

      Je suis d’accord avec toi (et c’est ce qui me fâche le plus), que ça aurait dû être réalisé ici. Mais selon ce que j’ai vu, le plus bas soumissionnaire québécois était à genre 12 millions vs les firmes françaises à 1-2 mil. Wtf esti. J’espère que quelqu’un s’est penché là-dessus aussi, parce que c’est complètement farfelu comme écart.

      • Bob@sh.itjust.works
        3·
        10 months ago

        Le plus bas soumissionnaire Québecois a 12M$ me rappelle étrangement VaxiCode… Mais oui tu as complètement raison pour le fait que ce soit un étudiant, je voulais plus dire ils auraient pu le payer en échange de pouvoir utiliser son code en tant que base pour le projet. Tout ça qui amène tout le débat des logiciels financés par le gouvernement avec du code closed source…

      • Max-P@lemmy.max-p.me
        3·
        10 months ago

        Ce que je comprends pas c’est pourquoi on est aussi obstiné à acheter des logiciels d’autres sociétés plutôt que d’engager du monde individuellement et localement pour le faire et maintenir. Même juste le salaire annuel d’une équipe de 5 très bien payée reviens à moitié prix, et t’as une équipe centrée exclusivement sur créer la meilleure application possible et avec les intérets de l’ARTM comme priorité.

        Mon expérience en tant que programmeur avec les entreprises tierces c’est qu’elles priorisent toujours les profits pour eux-même, doivent payer leur équipe de vente, plusieurs gestionnaires de projets. Souvent le projet est découpé et passé par plusieurs équipes différentes pour travailler sur des objectifs spécifiques le plus rapidement possible, ça se tient à exactement ce qui a été spécifié et rien de plus. Zéro flexibilité, zéro place pour les deviations et changements.

        Comparé aux petites équipes ou mêmes développeurs solo, qui eux priorisent la qualité et faire une application dont eux sont satisfaits et voudraient utiliser au quotidien, qui parfois vont expérimenter avec une façon alternative de faire. Beaucoup plus flexible, beaucoup moins rigide, pas de “le client l’a spécifié comme ça alors ça va marcher comme ça”. Si les plans font pas de sens c’est le genre de développeur qui va aller voir le gestionaire et proposer les changements. Et souvent c’est livré bien plus vite, de bien meilleure qualité, et beaucoup beaucoup moins cher.

        L’affaire avec les projets informatiques c’est que plus l’équipe est petite, plus le tout est bien intégré et uniforme. T’as besoin d’un changement côté serveur? Tu fais le changement toi-même ou limite demande un collègue au lieu de devoir passer par toute une bureaucracie et faire changer les plans, réevaluer les coûts et espérer que le gestionnaire de l’équipe serveur va avoir le temps de travailler sur ta demande. Ça produit des applications simples, minimaliste et élégantes.

        • Bob@sh.itjust.works
          2·
          10 months ago

          Sans oublier que le fait de recharger sa carte OPUS est un pas en avant, mais un pas en avant dans la mauvaise direction pareil. Ils devraient investir dans un système qui utilise le NFC du téléphone/smartwatch/whatever a la place de l’utiliser pour recharger la carte… On est en 2023 et acheter des billets de métro est toujours un processus chiant lent et qui laisse place a l’erreur (erreurs d’écrirure avec le NFC, carte bouge sur le dos du téléphone, bidule a 15$ qui se débranche, etc., etc.). Les autres métros dans le monde sont capables de le faire, pourquoi pas nous?? Surtout avec un budget de 1M$ + 2% de chaque ducking transaction qui s’en va dans les poches d’une compagnie étrangère qui va se faire Ben du cash sur notre dos pour même pas régler le problème a la source.

      • smsisko@lemmy.ca
        2·
        10 months ago

        Je ne serais pas surpris que la demande de soumission ressemble probablement plus à traiter quelques millions de clients simultanément dès le jour 1 sans comprendre qu’initialement on parle probablement plus de centaines de personnes simultanément, surtout que c’est encore pour recharger une carte…

        Habituellement le gros problème sur l’évaluation des systèmes informatiques, c’est une mauvaise évaluation de l’échelle…

        • swan_pr@lemmy.caOP
          1·
          10 months ago

          Oui, je me suis dit que peut-être l’évaluation était complètement off. Mais de quel côté? Est-ce ton scéniaro, ou le contraire? Où les infos fournies pour le devis étaient déficientes, que les firmes françaises ont sous-évalué et la firme queb s’est dit, “voyons, c’est tout croche st’affaire-là, ils ont pas tenu compte de ci et ça”. C’est plein de possibilités!

          • smsisko@lemmy.ca
            2·
            10 months ago

            Considérant que le gars en a codé une version MVP en 3 mois par lui-même, j’aurais tendance à dire que ça été surévalué

  • Smk@lemmy.ca
    2·
    10 months ago

    Le processus de soumission est probablement vraiment long et cave donc les petits joueurs sont juste pas dans game.