crédit photo Brian Snelson
Les projets gigantesques ont récemment eu très mauvaise presse dans les médias québécois. Comment en arrive-t-on là? Pourquoi de si gros projets? Pourquoi dépassent-ils les budgets prévus? Pourquoi certains échouent-ils? Je vais tenter de démystifier tout ça pour vous. Voici ma perception et mon opinion sur la chose, ayant moi-même participé à l’un d’eux, soit le projet RISE de la Commission administrative des régimes de retraite et d’assurances (CARRA)
La dette technique
Dans les grandes organisations, les systèmes informatiques ont souvent été gérés en mode projets. Une fois le projet terminé, il se retrouve en mode maintenance, et celle-ci répond à trois critères bien précis :
- La maintenance d’un projet consiste à affecter une équipe dont le rôle est uniquement d’apporter des correctifs en cas de problème (« break & fix »).
- Le programmeur assigné au soutien de l’application n’a pas pour mandat d’améliorer l’application. Il doit uniquement la remettre sur le droit chemin si elle déraille.
- Le programmeur est également contraint à des délais d’intervention déterminés par la gestion et qu’il doit respecter. Il doit alors réaliser la correction avec empressement, ce qui la rend par le fait même quelque peu boiteuse.
Par exemple, alors que j’étais affecté à la maintenance d’un projet, j’ai déjà reçu la consigne de cesser d’éplucher les journaux d’erreurs (« logs ») des applications en production pour corriger les anomalies des utilisateurs. Sans un appel de soutien technique formel, on ne devait pas bouger. On fermait les yeux sur des anomalies techniques importantes.
Ce genre de décision d’affaires crée inévitablement une dette technique. L’application est conçue pour un besoin « X » et une certaine charge d’utilisation « Y » au moment de sa création. Toutefois, les temps changent. Puisque le programmeur ne fait que des corrections très succinctes (mieux connues sous le vocable de « patchs »), le projet devient alors de plus en plus complexe et difficile à maintenir.
À force de repousser nos problèmes, on frappe un mur
Le retard devient si important qu’on ne peut plus améliorer l’application. C’est moins coûteux et moins risqué de la refaire à neuf. Le projet deviendra alors éléphantesque et on commencera à utiliser abondamment le terme « refonte ». Dès que vous entendez ce mot, « refonte », vous savez d’hors et déjà que vous entrez dans un processus qui implique beaucoup de heures-personnes. Dans le monde de la construction, une refonte, un événement très rare, consiste à raser un immeuble et ses fondations pour le rebâtir à zéro. Malheureusement, c’est une approche trop fréquemment utilisée en technologies de l’information. De plus, on doit la refaire de toute urgence. La continuité des affaires de l’organisation en dépend. On risque de ne plus être en mesure de fonctionner si une panne survient. La cloche d’alarme sonne ! D’ailleurs un signal d’alarme similaire a retenti d’un rapport récent de la vérificatrice générale du Canada récemment.
Finalité de cette démarche ? Un énorme projet avec un délai très court. En somme, tous les ingrédients réunis pour un échec. Et par la suite et on se surprend de la chose.
Une tâche colossale pour peu de compétiteurs
Le système est si gros qu’il exige une équipe considérable. Bien évidemment, l’organisme ne peut pas mobiliser des ressources humaines normalement affectées aux opérations courantes. Il faut alors se tourner vers l’externe. La question qu’il faut maintenant se poser est celle-ci : « Qui peut bien mobiliser autant de travailleurs temporaires en si peu de temps ? » Et selon vous, quelle est la réponse ? La voici : Des firmes de consultants en informatique gigantesques.
Vous comprendrez qu’il y a peu très d’élus qui peuvent répondre à cette demande. Un aspect qui empêche bien entendu une véritable concurrence, à ce niveau, dans le domaine des TIC. Conséquemment, les petites entreprises ne pourront répondre aux critères du futur appel d’offre.
Le système des appels d’offres et le plus bas soumissionnaire
Les soumissions sont bien évidemment examinées selon différents critères, mais le coût est le principal critère de sélection. Immanquablement, les candidatures se ressembleront beaucoup. Les critères de l’appel d’offres exigent des paragraphes au contenu spécifique, et les documents obtenus auront tous les mêmes sections avec des arguments de vente très convenus.
Sachant que la soumission ayant le prix le plus bas est souvent gagnante, cela ne peut que favoriser des manoeuvres discutables de fixation des prix comme le rapporte un reportage de Radio-Canada.
Le piège de la surprécision
Le porteur du dossier n’est pas dupe : il se protège en ajoutant encore plus d’exigences dans les futurs appels d’offres. Il ne veut pas se faire dire qu’une fonctionnalité n’était pas demandée au départ et se faire facturer une demande de changement (DDC).
Toutefois, le piège d’être trop précis a un effet pervers : le client met l’emphase sur la validation du produit final, et il doit alors vérifier si tout fonctionne comme demandé à la virgule près.
De plus, cette survalidation va forcément empêcher le fournisseur d’être créatif en simplifiant ou en améliorant intelligemment le produit livrable, car il créerait alors un écart trop important au regard de l’exigence initiale. On se retrouve donc avec un processus et une contrainte qui met le gros bon sens et l’imagination de côté. Des idées qui auraient pu rattraper des retards et ainsi faire sauver de l’argent au projet sans modifier les exigences deviennent alors impossibles.
Sortir de ce vicieux cercle sans fin
L’agilité, vous connaissez?
La nature même de l’agilité en entreprise est justement d’être à l’écoute des utilisateurs. On répond à leurs besoins en leur livrant une solution rapidement, laquelle sera à préciser et à bonifier à travers un échange continu avec les utilisateurs. On doit alors financer le développement des applications informatiques pour assurer leur évolution vis-à-vis les besoins changeants des utilisateurs.
Poursuivre l’évolution des systèmes
Concrètement, l’évolution d’un système consiste en une équipe permanente de programmeurs qui fait des déploiements réguliers vers les utilisateurs. Les programmeurs ont ainsi la possibilité de réusiner (« refactor ») l’application en réécrivant des portions de code entièrement pour améliorer sa lisibilité, sa rapidité et sa robustesse. L’évolution comprend aussi la conversion de certaines portions de l’application vers des plateformes et des langages plus modernes.
En procédant ainsi, l’application sera toujours au goût du jour et n’accumulera pas de dette technique. Elle se modernisera alors d’année en année et n’aura pas tendance à devenir désuète.
Toutefois, dans la fonction publique et dans les grandes entreprises, on ne maintient que les systèmes informatiques. Ce sont des postes budgétaires très faciles à réduire voir même couper. La terre n’arrêtera pas de tourner si on ne fait plus évoluer les applications. La conséquence est dans le futur, et peu d’organisations planifient longtemps à l’avance.
Tout le monde pourrait être gagnant
En évitant des projets de refonte de grande envergure, on peut confier l’évolution à sa propre équipe. Cette équipe interne devient alors maître d’oeuvre de la solution. Elle peut donc s’en remettre à des équipes externes pour des conseils ponctuels, mais elle doit essentiellement conserver le contrôle sur le développement de l’application. Nos employés demeurent motivés, car ils travaillent sur quelque chose d’utile qui se modernise constamment. Une réelle relation de complicité se développe alors entre les artisans du code et leurs utilisateurs.
Le bailleur de fonds y trouve forcément son compte, car il n’a qu’à procéder à des investissements réguliers tous les ans, ce qui est beaucoup plus facile à budgéter. Il ne se lance donc pas dans des projets trop importants souvent impossibles à contrôler adéquatement et qui comportent, bien entendu, de très grands risques.
