Logiciel : arrêter avant de recommencer

Quand j’utilise SAAQclic, je peine à comprendre comment un projet d’une telle ampleur peut produire une expérience aussi frustrante. Ce sentiment d’utilisatrice trouve un écho dans les problèmes documentés.

En février 2025, le Vérificateur général du Québec prévoyait que le programme CASA passerait de 638 millions à au moins 1,1 milliard de dollars d’ici mars 2027. Ce montant comprend le développement et l’exploitation du programme, dont SAAQclic est une composante.¹

L’audit relève aussi des tests insuffisants et une documentation de processus achevée après la signature du contrat.² On s’était engagé avant d’avoir suffisamment clarifié et vérifié ce que l’on construisait.

Les grands projets logiciels encore en préparation devraient être suspendus lorsqu’ils reposent sur cette logique : engager l’essentiel des ressources avant d’avoir éprouvé les besoins et la solution.

Comprendre avant de s’engager

Dans ma pratique, le second semestre de 2026 marque un changement d’échelle dans ce qu’une personne ou une petite équipe peut construire avec l’IA.

Dans Le logiciel avant la décision, je racontais comment j’avais obtenu un prototype fonctionnel avant de trancher plusieurs choix importants. Les organisations devraient s’appuyer sur cette possibilité.

Le prototypage existait déjà, mais l’effort nécessaire pour rendre une idée testable peut désormais diminuer fortement. On peut découvrir une règle oubliée ou abandonner une mauvaise approche avant qu’elle devienne un engagement coûteux.

Un prototype permet d’observer ce que les utilisateurs comprennent et réussissent réellement à faire. Il devient un instrument de décision.

Le métier au centre

Les experts du métier devraient conduire cette exploration, de préférence à l’interne. Ils connaissent les opérations, les exceptions et les conséquences d’une erreur. Il faut leur donner du temps et une véritable autorité sur les priorités et la validation.

Une règle administrativement correcte peut pourtant produire un parcours incompréhensible. Les utilisateurs doivent pouvoir essayer le service tôt, y compris ceux qui rencontrent des difficultés d’accès ou des situations moins courantes.

Les spécialistes du logiciel restent responsables de l’architecture, de la sécurité et de la fiabilité technique. Une interface convaincante ne prouve pas que la migration des données, les intégrations et l’exploitation fonctionneront.

Le rapport DORA 2025 décrit l’IA comme un amplificateur des forces et des faiblesses organisationnelles.³ Produire plus vite exige donc de vérifier aussi ce que l’on produit.

Des preuves avant les grands budgets

Cette exigence concerne les équipes internes comme les grandes firmes de services, dont CGI et IBM. Ces entreprises proposent déjà des offres liées à l’IA.⁴ Leurs gains annoncés devraient se traduire dans les coûts, les délais et la maîtrise laissée au client.

Les contrats devraient financer des étapes limitées, avec des critères explicites pour poursuivre : utilité démontrée auprès des utilisateurs, faisabilité technique, qualité et coût d’exploitation. L’organisation doit garder accès au code, à ses données et aux connaissances nécessaires pour faire évoluer son service.

Repartir du besoin peut conduire à conserver un système, à le simplifier, à remplacer certaines fonctions ou à renoncer au projet. Une réécriture complète doit elle aussi être justifiée.

Les projets déjà engagés doivent aussi être réévalués, en comparant le coût de poursuivre, d’adapter ou d’arrêter, tout en assurant la continuité des services essentiels.

L’argent déjà dépensé explique où nous en sommes. Il ne suffit pas à justifier ce que nous dépenserons ensuite.

Avant de signer pour construire à grande échelle, il faut pouvoir montrer ce que les utilisateurs ont essayé, ce que les experts du métier ont validé et ce que l’organisation a appris.