Le manque flagrant de gouvernance dans les projets informations engendre des situations complètement inacceptables comme celles mentionnées dans l’article :

On interdisait aux analystes d’Etiah de parler aux usagers, ce qui est illogique lorsqu’un logiciel est conçu pour répondre aux besoins de ces derniers. Tout devait passer par quatre niveaux d’approbation et les usagers se trouvaient en bout de ligne, alors qu’ils auraient dû se trouver au tout début du processus.

La SAAQ a imposé à l’équipe d’Etiah un « analyste d’affaire » qui avait le pouvoir d’approuver des documents cruciaux. Ce dernier était un employé de CGI, une firme informatique rivale.

via Dany Doucet du Journal de Québec.

Je peux aussi en témoigner, car j’ai vu les mêmes faits dans d’autres projets. On indique que l’acceptation des travaux était faite par un autre fournisseur. C’est complètement idiot de faire ça. Le client devrait toujours valider les travaux pour lesquels ils payent. C’est à la base de la relation client-fournisseur. Ça ouvre la porte à des abus de pouvoir entre concurrents chez le client.

Un autre article mentionne que la firme Etiah avait été mandatée pour rédiger son propre appel d’offres. Les fournisseurs sont alors impliqués du début à la fin dans le processus d’appel d’offres. Ils déterminent les besoins, ils réalisent le mandat et ensuite ils approuvent le travail. Et celui qui paie, il est où dans le processus?

Projets informatiques gouvernementaux sans gouvernance est un article provenant du blogue d'Evollia

Toutes les solutions modernes sont interopérables. Ce n’est plus risqué qu’auparavant de migrer vers d’autres plateformes ou solutions. La montée du web a soufflé un vent de standardisation à travers l’industrie des TI. Les logiciels doivent être compatibles entre eux sinon ça sera leur mort.

Pour en savoir plus sur le jugement:

• Contrat public en TI: victoire de Savoir-Faire Linux – Branchez-vous
• Le logiciel libre remporte une manche – Radio-Canada
• Jugement à l’encontre de la Régie des Rentes – Cyrille Béraud gagne sa bataille pour le logiciel libre – Rue Frontenac
• Le logiciel libre remporte une victoire en cour – Cyberpresse

MAJ 2010-06-07 : Cyrille Béraud de Savoir-Faire Linux a fait un billet et a reçu une pluie de commentaires.

Victoire de la libre concurrence face aux vieilles pantoufles est un article provenant du blogue d'Evollia

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.

Le cercle vicieux des projets éléphants est un article provenant du blogue d'Evollia

Étrangement, au Canada le CRTC vient d’autoriser Bell Canada à faire le contraire le 21 octobre dernier. Forcé d’admettre que les libertés individuelles des citoyens pour le gouvernement canadien ne sont pas aussi importantes que nos voisins du sud.

C’est quoi ça la neutralité du NET?

Voici un petit rappel de ce que c’est la neutralité du net. Vous accédez internet à l’aide d’un fournisseur d’accès à Internet. Vous accédez des sites qui ne sont pas sa propriété et souvent ses compétiteurs. Votre fournisseur peut et dans certains cas a déjà modifié la priorité en vitesse à certains sites internet selon ses intérêts commerciaux.

Voici un exemple fictif pour un véhicule automobile : des moyens techniques seraient mis en oeuvre pour nuire et ralentir le travail d’un garagiste indépendant pour ainsi favoriser l’entretien de votre véhicule chez le concessionnaire.

Explication simple de la neutralité du NET est un article provenant du blogue d'Evollia