SAAQclic et le monde merveilleux des projets de développement informatique

Normalement les sujets sur ce blog sont plutôt reliés à l'économie. Mais comme je suis un programmeur senior avec 35 années d'expérience dans le domaine pointu des applications industrielles et qu'en plus, j'ai souvent été impliqué dans des comités de réflexion sur l'amélioration des processus logiciels, j'ai pensé partager ici quelques réflexions sur l'échec du projet SAAQclic du gouvernement de la CAQ. Comme en plus je vais parler de l'estimation de coût des projets informatiques, c'est quand même pas complètement déconnecté de l'économie.
Certains gestionnaires ne seront pas content d'entendre ce que je vais dire ici mais je me base sur des donnèes solides et sur de bonnes références.
Note: je vais donner des références à la fin du texte

Esse que je suis surpris par cet échec et ces dépassements de coût?

Non. Pas vraiment. Les dépassements de coût pour les grands projets de transformation numérique sont endémique. Secteur privé, publique... personne n'y échape. C'est comme ça pour tout projet informatique. C'est difficile le développement logiciel. Particulièrement l'estimation de coût pour les gros projets. Le niveau de difficulté augmente de façon non linéaire avec la taille/complexité du projet.
Que disent les études? En agrégeant les données du Standish Group, de McKinsey/Oxford et du Project Management Institute (PMI) pour 2024-2026 on vois que 66% des projets dépassent leur budget (je ne tient pas compte des projets de AI qui sont encore plus catastrophique). Si on classe par catégorie (succès, dépassement modéré, dépassement critique) ça donne (merci ChatGPT):

Catégorie	% des projets	Ampleur du dépassement
Succès budgétaire	34%	0% (ou sous le budget)
Dépassement modéré	48%	20% à 50%
Dépassement critique (mais livré)	18%	100% et plus

Différentes études arrivent à des chiffres différents et c'est pour ça que j'ai combiné les études. J'ai vérifié certaines études individuellement pour être certain que les chiffres de l'IA faisaient du sens et tout semble correct et être cohérent avec d'autres sources.
Les résultats seraient probablement un peu mieux si j'excluais les résultats du Standish Group (CHAOS report) dont la méthodologie tend à biaiser les résultats. Mais l'ordre de grandeur est bon.
L'autre point c'est qu'on sait depuis longtemps que plus un projet est gros, plus la probabilité de dépassement (ou d'échec) est élevée (Capers Jones, cité dans Steve McConnell [1]). Entre 72% et 86% (79% en moyenne) des gros projets logiciels (plus d'un million de lignes de code ou plus de 10000 "Function Point") dépassent leur budget ou ne livrent pas une version fonctionnelle (ils sont considérés comme un échec). Seulement 21% en moyenne sont livrés à temps et respecte le budget. Certaines études arrivent a 10% mais ça dépend si on considère que en dessous d'un certain dépassement on est sur le budget (notre cas, donc on garde 21%). C'est effectivement moins que le 34% de succès dans le tableau qui lui, devait inclure des projets plus petits (ce qui tend à confirmer que les chiffres de Capers Jones sont probablement encore valides même s'ils sont plus vieux - 1998). En termes de budget, le chiffre qui revient souvent dans la littérature pour un gros projet, c'est 10 millions de dollars (ou plus). Donc SAAQclic, c'était un très gros projet.
Remarque : le nombre de lignes de codes (LOC) ou les "Function Point" ont leurs limitations pour ce qui est de mesurer la taille d'un logiciel, mais ils ont l'avantage d'être des mesures bien définies. Aujourd'hui, on pourrait utiliser des "Use case points" (ma mesure préféré) ou des "Story points", mais ça ne serait pas parfait non plus. Cependant, comme je disais, l'ordre de grandeur est bon.
L'autre facteur, c'est que les projets du secteur public tendent à avoir de plus gros dépassements et un taux d'échec plus élevé. Pas parce que les gens sont moins bons mais parce que souvent les projets sont plus gros, doivent respecter plus de réglementation, etc...
Si on s'en tient aux projets qui sont livrés, SAAQclic fait partie des 18% de projets qui vont vraiment mal et qui ont des dépassements critiques.

Qu'esse qu'on peut faire

Dans une publication comme celle-ci je ne peux donner que quelques pistes mais comme d'habitude je vais vous mettre des références et vous allez pouvoir approfondir en "suivant les miettes de pain".

Intermède (l'agilité dans tout cela)

Personne de sensé de nos jours n'exécute de projet logiciel sans incorporer au moins certains éléments des méthodologies agiles. Je ne parle pas de la notion ridicule d'agilité à laquelle certains politiciens et gestionnaires font appel dans leur discours. L'agilité tel que défini dans le cadre du développement logiciel, peut fonctionner parce qu'elle fait intervenir certaines techniques bien précises qui ne peuvent pas être transposées à d'autres domaines. Les tests unitaire automatisé étant probablement l'élément le plus important et ceux-ci demandent d'écrire plus de code (même si les IA sont d'une aide considérable pour cet aspect du travail). Quand les gestionnaires parlent d'agilité je ne pense pas qu'il parle de faire plus de travail.
Comme je disais, les projets informatique de nos jours vont nécessairement incorporer des éléments des méthodologies agile. Par exemple:

• Développement incrémental et itératif
• Tests unitaires automatisés
• etc...

Personnellement, je pense qu'une bonne partie des bienfaits de l'approche "agile" viennent de l'utilisation de tests unitaires automatisés.
Mais le plus important pour notre discussion ici c'est que le principal moteur des dépassements de coûts n’est pas la méthode (Agile ou Waterfall), mais la qualité de l’estimation et la gestion du risque d’estimation (S. McConnell [1], R. Glass [2]). Voir également Ellen Gottesdiener [6] qui parle de l'importance d'adapter l'approche au typed de projet (pour les requis entre autre).

Définissez clairement les besoins (requis) du projet

Robert Glass [2] et une multitude d'autres auteurs expliquent que les requis mal définis sont l'une des deux causes les plus importantes des dépassements de coût.
On peut utiliser différentes méthodes pour définir les requis, mais on a avantage à utiliser une méthode standard qui permet de mesurer la taille du projet. Ça peut être "Feature driven development" (Développement piloté par les fonctionnalités) avec sa façon standardisée de formuler les requis. Ça peut être une approche qui démarre avec les "Cas d'utilisation" (Use Case), "User Stories", etc....
L'important, c'est d'avoir quelque chose qui permet d'avoir une bonne communication avec les utilisateurs et d'avoir une mesure pour alimenter le travail d'estimation. La question de la définition des requis est vaste et je ne peux qu'effleurer la question ici. Voir Karl E. Wiegers [5] qui couvre beaucoup de fondamentaux qui n'ont pas vraiment changé depuis la 3e édition de son livre.

Évitez à tout prix de sous-estimer le travail

La première chose à comprendre, c'est qu'une des deux causes les plus répandues de dépassement de coût, c'est de sous-estimer le budget pour un projet logiciel (Robert L. Glass [2]). Beaucoup de gens (et pas les plus stupides) ne comprennent pas ce point et vont dire : "Ben voyons, c'est sûr que si tu sous-estimes le coût pour un projet, tu vas dépasser le budget..."
Ce qu'ils ne comprennent pas c'est que de sous-estimer le coût pour un projet logiciel met en place une dynamique infernale pour celui-ci. Entre autre:

• Les ressources allouées au projet (nombre de programmeurs, testeurs, etc...) vont être insuffisantes. La "loi de Brooks" va inévitablement finir par venir pénaliser le projet. La loi de Brooks : "ajouter du personnel à un projet qui est en retard augmente le retard". On dit "loi de Brooks" parce que cette règle a été confirmée par un grand nombre d'expériences. Il faut superviser les nouveaux employés et leur fournir des informations qu'on n'aurait pas eues à fournir s'ils avaient participé au projet dès le début. Etc...
• Sous pression, les développeurs vont avoir tendance à négliger certains aspects du développement qui ne sont pas absolument nécessaires pour la livraison du produit. Ils vont négliger les tests unitaires, les revues de code et autres techniques qui aident à garantir que le travail est de qualité. Cette négligence va rapidement agir comme du sable dans l'engrenage de la machine de développement et contribuer aux coûts additionnels (corrections d'erreurs plus tard dans le projet, etc...)

Quand on sous-estime le travail, le coût augmente de façon non linéaire, tandis que quand on surestime le travail, le coût augmente seulement de façon linéaire. Voici à quoi cela pourrait ressembler, disons, pour un projet dont le vrai coût en mois homme serait de 10.

La "question qui tue" évidemment c'est: quel est la bonne méthode pour estimer un projet logiciel. Malheureusement, il n'y a pas de réponse simple à cette question. Cependant, Steve McConnell donne une liste de caractéristiques qui se retrouvent chez les équipes qui s'en sortent bien avec leurs estimations:

1. Met l’accent sur le comptage (métriques) et le calcul plutôt que sur le jugement
2. Intègre plusieurs approches d’estimation et la comparaison des résultats
3. Inclut un plan de réestimation à des points prédéfinis du projet
4. Définit comment l’approche d’estimation requise évolue au cours du projet
5. Contient une description claire de l’imprécision des estimations
6. Définit quand une estimation peut être utilisée
   • Comme base pour un budget de projet
   • Comme base pour un engagement interne
   • Comme base pour un engagement externe
7. Prévoit l’archivage des données d’estimation et l’évaluation de l’efficacité de la procédure

Le point (1) est important. Si après x jours de travail (nombre de personne * nombre de jours de travail) vous avez implantez U "Use case points" (UCP) alors vous pouvez calibrer vos UCP et avoir une véritable idée de ou en est le projet: UCP-total - UCP-implanté * Nombre d'heure par UCP-implanté, vous donne le nombre d'heures restant (approximatiuvement)
La liste de Steve McConnell peut être utilisé dans le cadre d'une évaluation de l'équipe de développement ("avez vous des données achiver pour des projets que vous avez fait dans le passé" et "quel métrique avez vous utilisé pour la taille de vos projets", etc...).

Prévoyez la livraision de version intermédiaire du logiciel

Je ne sais pas à quelle fréquence ils ont déployé des prototypes intermédiaires en cours de route pour SAAQclic, mais c'est une excellente protection contre les surprises. L'idéal, c'est que le prototype soit évalué par une équipe indépendante.
Si les développeurs vous disent qu'ils ne peuvent pas faire ça, alors ce n'est pas une équipe avec qui vous voulez travailler.
Quand les prototypes sont livrés, l'équipe de tests devrait savoir les Use Case (Story, etc...) couverts dans la version à tester.

Demander des rapports sur la couverture des tests unitaires automatisés

L'équipe devrait pouvoir vous dire quel pourcentage du code écrit est couvert par des tests automatisés et le taux de succès (pourcentage des tests qui passent).

Conclusion et références

Je ne discute pas des problèmes d'éthique et des magouilles qui ont miné le projet SAAQclic. Pour moi, en partant, l'honnêteté et la transparence sont cruciales.
Comme je l'ai dit plus haut, je n'ai fait qu'effleurer le sujet. Entre autres, j'ai complètement mis de côté la question des différents types de développement logiciel. Ces aspects-là sont discutés dans certaines des références citées ici (Gottesdiener [6] et Wiegers [5] entre autre). Certaines de ces références remontent à plusieurs années mais les aspects fondamentaux discutés ici restent valides.

• [1] Steve McConnell, "Software Estimation", Microsoft Press 2006
• [2] Robert L. Glass: "Facts and fallacies of software engineering" chez Addison-Wesley 2003
• [3] The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution
• [4] Use Case point
• [5] Karl E. Wiegers, Sofware Requirements 3rd Edition, Microsoft Press 2013
• [6] Ellen Gottesdiener, Software Requirements (Memory Jogger), GOAL/QPC 2005