Pièce 25.6
Le Système informatique de la base - Les mauvaises techniques
Le projet du Système informatique de la base vise à doter les bases des Forces canadiennes de la technologie
de l'information nécessaire pour appuyer une vaste gamme de fonctions administratives et de soutien, y compris
le génie construction, la gestion du personnel militaire et du personnel civil, la gestion d'atelier, les opérations de
transport et les pharmacies des bases. Le Ministère a approuvé le projet en 1981, mais aucun financement n'a
été consenti avant 1986, année où le Conseil du Trésor a autorisé un montant de 55 millions de dollars destiné
au projet. En 1994, huit ans plus tard, les produits ne sont toujours pas prêts.
Le projet ne peut pas être considéré comme un succès. Au moment de notre vérification, la plupart des modules
d'application étaient en retard sur le calendrier, et les budgets n'étaient pas respectés. Ainsi, le module de génie
construction accusait un retard de 22 mois et des dépassements de coûts de 10 p. 100. Le système proposé de
gestion du personnel militaire a été jugé inacceptable et on prévoit maintenant qu'il y aura un retard d'environ
deux ans pour ce module. Pour réduire les coûts, les administrateurs du personnel civil ont abandonné le projet
initial et l'ont remplacé par un système déjà existant. Le module pharmacie accuse un retard de deux ans. Le
module gestion d'atelier est un an en retard sur le calendrier et il dépasse de 500 000 $ son budget. Le module
des opérations de transport, lui, a été conçu pour tourner sur un gros ordinateur, mais le projet fournira des
ordinateurs personnels; le client le refusera probablement.
Ces problèmes s'expliquent ainsi :
-
Faible participation de l'utilisateur
. Le projet du Système informatique de la
base utilise un modèle de développement dépassé qui ne fait intervenir
directement les utilisateurs qu'à la première étape. Le bureau de projet a défini les
besoins au début des années 80, au moyen de sondages, d'entrevues et de
visites. Cette version des besoins constituait le fondement du projet approuvé en
1986, même si les besoins des utilisateurs avaient changé, attendu les progrès
technologiques et les changements opérationnels.
-
Absence de méthodes de développement adéquates
. Le bureau de projet
a utilisé une méthode de développement de systèmes qui, même si elle était
acceptée à l'époque, éloignait encore plus les programmeurs des utilisateurs
fonctionnels et les obligeait à travailler à partir de devis plutôt qu'en collaboration
avec l'utilisateur.
-
Lacunes du contrat
. Le contrat ne prévoyait pas de pénalité en cas de retard
des travaux; il n'y avait aucune disposition concernant l'approbation de
changements éventuels au sein du personnel exécutant le contrat; aucun
mécanisme de consultation avec l'entrepreneur pour préciser les exigences n'était
prévu.
-
Faiblesses de l'équipe de projet
. Une grande partie du personnel clé n'avait
pas d'expérience antérieure en gestion de projets et en développement de
systèmes. Le roulement du personnel du bureau de projet était élevé.