Cette semaine, en lisant le Journal de Québec, je n’ai pas pu m’empêcher de réagir à cette chronique de Joseph Facal portant sur le «bordel informatique» à la SAAQ, qu'on découvre un peu plus de jour en jour avec la commission Gallant. J'ai décidé de lui répondre par courriel pour partager mon point de vue, mais dans le contexte où il se dit beaucoup de choses sur la transformation numérique, l'ingénierie logicielle et la gestion de projets technologiques, je me permets d'étendre la portée de ma réponse afin d'améliorer la compréhension de notre secteur d'activités. Je suis très curieux d'entendre mes pairs également sur le sujet : n'hésitez pas à réagir!
Bonjour M. Facal,
Je suis un lecteur assidu de vos chroniques et je souhaitais réagir à votre dernière publication concernant le «Bordel informatique» à la SAAQ.
Je suis un développeur logiciel de 28 ans travaillant pour Nexapp, une firme d’ingénierie logicielle de Québec qui, depuis plus de 10 ans, aide les entreprises à maximiser et accélérer l’impact de leurs investissements logiciel.
D'abord, j'aimerais souligner que les 5 raisons que vous avez notées pour lesquelles les projets de transformation numérique peuvent déraper sont tout à fait justes :
Or, j'aimerais aussi critiquer un peu la solution proposée.
Dans notre jargon, ce que vous suggérez porte un nom bien connu : le développement en cascade (waterfall).
Les requis et les contraintes sont longuement analysés par des analystes d'affaires, des spécialistes du domaine, la direction du projet et certaines parties prenantes. À la suite de cette étape, des architectes logiciels digèrent les rapports d'analyse afin de définir les grandes lignes de la solution à implémenter : les technos a utiliser, les patrons de conceptions a appliquer, les modèles de bases de données pour supporter les divers besoins d'affaires, les requis de performance et de sécurité, ainsi que les autres besoins non-fonctionnels.
Ensuite, le travail est divisé entre les équipes de développement. Si le projet se prétend le moindrement moderne, il tentera d'appliquer diverses méthodologies tirées de la philosophie Agile : cérémonies scrum, sprints, story points, estimations, ou encore, dans sa forme maligne, le framework SAFe (Scaled Agile Framework). C'est ici que le gros du travail est effectué et que les développeurs et développeuses se mettent à l'ouvrage.
Quand une équipe a terminé un morceau de fonctionnalité, souvent celle-ci est passée à une équipe d'assurance qualité (QA) afin de valider les contraintes et les requis énumérés lors de la phase d'analyse.
Enfin, quand la fonctionnalité reçoit le sceau d'approbation de l'assurance qualité et des gestionnires, celle-ci est déployée en production pour les utilisateurs finaux.
Cette approche peut apparaître attirante aux yeux de la plupart des gens. En effet, à première vue, on pourrait faire plusieurs parallèles avec d'autres domaines de l'ingénierie et dire que, par comparaison, une méthode similaire devrait donner les mêmes résultats : fiabilité et prédictibilité.
Or, émettre cette hypothèse c'est ignorer l'une des prémisses les plus fondamentales en développement logiciel : qu'il n'existe pas deux projets logiciel qui soient identiques. Plus souvent qu'autrement, un projet logiciel est une solution originale qui tente de répondre à des problèmes spécifiques que vivent un certain groupe d'usagers.
Et c'est ici que l'on peut retirer le plus de valeur d'une solution informatique : en se demandant quelle est l'automatisation minimale qui permettrait d'améliorer la vie d'une personne. Cette façon de penser porte un nom : agilité. Cette méthodologie peut parfois avoir mauvaise presse en fonction de la direction des vents. D'ailleurs, elle est aussi connue pour son surnom de la Silicon Valley : move fast and break things.
De mon côté, je préfère de loin le parallèle que l'on peut en faire avec la méthode scientifique: hypothèse -> expérimentation -> validation. Ce qui distingue et avantage énormément l'informatique par rapport aux autres domaines de l'ingénierie, c'est qu'il est possible d'avoir une boucle de rétroaction quasi instantanée. Avec les bons processus en place, les développeurs et développeuses sont capables d'émettre un design (hypothèse), de produire une solution (expérimentation) et de vérifier par eux-mêmes le résultat de ce qu'ils ont fait (validation). Et tout ça, dans une même journée.
Un projet logiciel, c'est une panoplie d'hypothèses que l'on pose. Qu'est-ce que le bon produit pour mes utilisateurs? Quels sont les besoins de performance liés à notre implémentation? Quels sont les enjeux de sécurité? Le rôle d'un développeur ou d'une développeuse de logiciels, c'est de mettre en application ces hypothèses pour savoir si elles répondront aux besoins escomptés. Le problème majeur avec la plupart des fiascos informatiques, c'est qu'on met trop de temps en amont avant de tester chacune de nos prémisses contre les feux de la production. D'ailleurs, comme la Loi de Murphy s'applique davantage à l'informatique qu'à d'autres domaines, l'une des meilleures façons de s'en prémunir, c'est en testant chaque petite hypothèse le plus fréquemment possible.
Enfin, je vous laisse avec cette citation de Melvin E. Conway qui résume très bien pourquoi on obtient les systèmes informatiques que l'on mérite :
Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
— Melvin E. Conway, How Do Committees Invent?
William Picard
Artisan du logiciel