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.

par joebeone

Avez-vous remarqué un choc de générations ces dernières années dans l’industrie des TI? Il me semble que les jeunes dans ce domaine passent leur temps à affronter la génération qui les a précédées. Vous me direz que ce n’est pas limité aux TI, vous avez raison, mais puisque c’est mon domaine, pardonnez-moi cette étroitesse dans ce billet.

Depuis que l’informatique existe, de nouvelles technologies et de nouveaux concepts révolutionnent notre monde. À chaque fois, une confrontation s’en suit. Malgré que ce domaine est censé être accoutumé au changement, il est rare de voir un spécialiste se renouveler. Notre capacité d’assimiler des nouvelles notions diminue avec l’âge. Je le constate moi-même. Mon fils de 4 ans est en mesure d’acquérir des connaissances avec une seule explication. Quand je lis des textes explicatifs, je me perds parfois. J’ai alors besoin de visionner une présentation vidéo pour y saisir les nuances. Ça n’ira pas en s’améliorant à force de le constater.

Pour vous aider à vous aussi de comprendre, voici quelques phénomènes qui ont révolutionné les TI.

L’ordinateur personnel

La première division a été entre celles de l’informatique d’entreprise et personnelle. L’abréviation PC (Personal Computer) signifiait un ordinateur pour la maison. Ceci se differienciait aux ordinateurs centraux ou mini (ex: VAX ou AS400) qui dominaient les grandes corporations et les gouvernements. Cette division perdure à ce jour. Il n’est pas rare de voir des spécialistes d’ordinateur central lire leur courriel une fois par jour (et écrire en majuscules!). Toutefois, les adeptes des ordinateurs centraux sont de moins en moins nombreux. TECHNOcompétences a même produit un rapport assez éloquent à ce sujet.

Les logiciels libres

Sachant que les PC dominaient le marché, des futés ont pensé de créer un système d’exploitation qui utiliserait la même architecture matérielle. Linux est né en 1991 et n’a jamais cessé d’évoluer. On y attribue beaucoup l’essor du web, puisque son faible coût d’acquisition (0$) a permis de l’installer sur des millions de serveurs sur internet. L’idée que le développement d’une technologie est l’affaire de tout de le monde est difficile à comprendre pour un spécialiste d’une technologie propriétaire éprouvée. Ces derniers voient le phénomène avec beaucoup de méfiance. Ils s’imaginent que le logiciel a été développé anarchiquement et peut être abandonné à tout moment. Mais, si on se fie aux finissants des cégeps et universités, le logiciel libre a la cote. Il sera important de voir l’évolution dans les prochaines années à cet égard.

Agile

Le développement de systèmes depuis la nuit des temps a toujours été une affaire de gestion de processus serrés. Les grandes compagnies de consultation en TI, ont développé des méthodologies qui ont fait longtemps des jaloux. Ils étaient maîtres de la gestion du temps, des coûts et de la qualité, mais malheureusement pas toujours de la satisfaction des utilisateurs. Les grands chantiers informatiques perdent parfois leur dimension humaine. Les méthodologies agiles comme Scrum ont adressé ces problématiques à leur manière. La philosophie nombriliste des méthodologies waterfall perd du terrain vis-à-vis l’approche agile qui fait plus de place aux utilisateurs dans le processus de développement de systèmes.

Le web

Le web est probablement le plus grand diviseur. Le web n’a pas juste divisé les informaticiens en deux clans, une seconde industrie s’est créée parallèlement. Le phénomène était trop grand et les TI ont perdu le contrôle sur la destinée du web. Tous les succès du web sont attribuables à de nouveaux joueurs. Les grands joueurs d’autrefois se sont taillé une place malgré tout en achetant des petits startups (ex. : Hotmail par Microsoft). Les technologies les plus utilisées ne sont pas celles des grands joueurs non plus. Les technologies Java, PHP, Perl, Python et Ruby on rails domine le paysage.

La venue de la virtualisation par le nuage (cloud computing) risque d’élargir le fossé encore plus. L’industrie des TI est en mode réaction face à ce phénomène. Il invalide en quelque sorte leur modèle d’affaire qui a fait leur succès. Le cloud fera-t-il Microsoft, Oracle, Novell et IBM les GM et Chrysler de demain?

Que devrions-nous faire?

En conclusion, on peut constater que le changement n’est pas toujours facilement accepté. Mais, que l’on veuille ou non, il est là pour rester. Il est là parce que les gens en ont le besoin. L’adoption générale se fait par nécessité. Si on ne veut pas, en prendre part, c’est louable et c’est un choix personnel. Le changement fait peur et parfois il est difficile à assimiler.

Faut-il alors se ranger et laisser nos prochains prendre les règnes? Si on ne le fait pas, devient-on obligatoirement un empêcheur?

Avez-vous d’autres exemples où les générations s’affrontent en TI? Quelles sont vos solutions pour mieux intégrer les ressources seniors aux nouveautés?

Billets sur le même sujet :

1. Le 400e de Québec et le choc des générations

Le succès de différents services sur internet dit « web 2.0 » est indéniable. Prenons l’exemple de Twitter, ce réseau social où ses membres diffusent de courts messages textes de 140 caractères à d’autres membres qui sont abonnés à leurs mises à jour. Ce site a vécu et vit toujours d’importantes difficultés de « scalability » ou d’extensibilité (merci l’OLF). L’adoption du site par les internautes n’a jamais été ralentie par ses innombrables problèmes techniques. Lorsqu’on parle de ses problèmes techniques, ils sont sérieux :

1. Perte de données : des messages ont été perdus.
2. Violation de la confidentialité : des messages privés entre membres sont apparus dans les messages publics.
3. Pannes intermittentes : tous les jours, il y a des périodes aléatoires où le système ne répond pas.

Normalement, ce genre de problèmes sont suffisants pour décourager et effrayer les utilisateurs. Mais, au contraire, le site continue à croitre en membres. Alors, je me questionne : l’innovation qu’un service amène dans la vie des utilisateurs a-t-elle plus d’importance que sa fiabilité?

par karpidis

Je viens de l’école de pensée qu’il faut livrer des produits de qualité supérieure au risque de livrer en retard. Il ne faut pas livrer des bogues majeures qui pourraient causer un préjudice envers l’utilisateur. Mais, est-ce que cette école de pensée est désuète?

Cette obsession de la perfection nuit-elle au TTM (« time-to market »)? Si on livre trop tard à nos utilisateurs, risquons-nous de perdre la fenêtre d’opportunité de faire une différence dans sa vie?

Je vous avoue que je ne sais pas sur quel pied danser sur cette question. Possiblement, les microlivraisons permettent de remplir ces deux objectifs. Si l’usager a un besoin pressant, serait-il plus judicieux de lui offrir une solution simple sans artifices rapidement? Si le besoin évolue, peut-on faire évoluer intelligemment ce produit? Qu’en pensez-vous?

Billets sur le même sujet :

1. Twitter pour les avis de fermeture d’écoles
2. L’informatisation totale viendra-t-elle un jour?
3. Québec pourrait-elle devenir une ville 2.0?

par kawanet

Je viens de prendre connaissance d’un superbe billet sur le blogue de Coding Horror qui s’intitule “Paying Down Your Technical Debt“. La dette technique (Technical Debt) est un concept qui a été lancé par Ward Cunningham. Lorsqu’on développe ou maintient une application sur une longue période de temps, ça arrive souvent qu’on prenne des chemins discutables pour arriver à nos fins. Cela se justifie par des échéances trop serrées, une ignorance de la technologie ou un manque de familiarisation avec le patrimoine bâti (ce qui a été fait avant nous).

Lorsqu’on décide de ne pas revisiter ces erreurs et de constamment les éviter, c’est qu’on produit un déficit qu’on rajoutera à la dette technique. Éventuellement, l’application deviendra un gros spaghetti incompréhensible composé d’innombrables passes passes de cowboy. On vient alors à la conclusion qu’elle doit être refaite et mise au rancart. On fait faillite en sorte!

Le billet nous conseille de prendre une pause du développement de nouvelles fonctionnalités et dédier un peu de temps à réécrire des portions de l’application (refactorisation). Il existe des techniques pour faire de la refactorisation sans déstabiliser l’application.

Aussi la refactorisation devrait être encouragée pendant le projet et devrait être une priorité pour une application en maintenance. L’amélioration d’une application qui compte déjà ses adeptes fera du programmeur une mégavedette sans trop d’efforts de sa part. C’est une parfaite application de la loi de Pareto (loi du 80/20).

Avez-vous des exemples où vous avez réduit ou accumulé une dette dans un projet?

Le développement traditionnel de type waterfall comprend les étapes d’analyse de besoins, de conception de la solution, de programmation et de tests. On doit prévoir tout à l’avance. Toutefois, cette méthode s’avère très longue et amène parfois les informaticiens à surfaire ce qui était demandé au début.

L’extreme programming se veut une façon de développer rapidement de quoi de simple pour le besoin immédiat. Si le besoin vient à changer, on changera le programme. Si on doit le réécrire, on le fera.

Toutefois, pour assurer la qualité et la non-régression de la solution existante, on doit écrire des tests unitaires automatisés qu’on peut lancer aussitôt la modification est terminée.

Voici la vidéo:

Billets sur le même sujet :

1. Le cloud computing expliqué simplement