Le vague à l'âme des mégaprojets en informatique

"Le fait d'intituler "Projet informatique" à des mégaprojets destinés à transformer un métier est déjà en soi, un symptôme de la mauvaise gestion qui entraîne l'échec de telles initiatives", disait le professeur de l'IT, Georges Ataya.

J'avais déjà parlé des problèmes de code des programmes informatiques qui donnaient la nausée. Ici, Georges Ataya, professeur de l'IT remonte le problème plus haut dans la chaîne de développement.

Ce qui est sur la sellette, cette fois, c'est la totalité du processus de développement d'un projet trop important que pour être limité à un seul projet même "mégastore".

Datanews mettait déjà en garde en avril dernier de la possibilité d'arriver à un fiasco pour un projet eHR (Human Ressource électronique).

Cette fois encore c'est l'Inspection des Finances qui confirme. On relance ou non, eHR?

Le SPF Fedic n'aurait pas demandé suffisamment à la partie "SPF Personnel et Organisation". Solliciter tous les utilisateurs de la base jusqu'au sommet avant d'écrire la moindre ligne de code.

Analyse des besoins réels et imaginer un concept généralisé et fonctionnel devrait prendre le plus de temps dans la totalité d'un projet.

Limiter cette analyse à sa seul entreprise, en sortir la conjonction des besoins dans un mégaprojet c'est dépasser de loin un problème informatique. Sur réalité du terrain, c'est d'ailleurs rarement le cas, perdu derrière tellement de tentacules de sociétés et de sous-ensembles. Estimer le coût global d'une telle entreprise est seulement devenu une chimère.

SPF Justice, que l'on pourrait appelé eJustice, avait déjà eu du plomb dans l'aile dès son départ. Échecs successifs, d'ailleurs. Projet repris comme une course relais mais dont on ne voit pas la ligne d'arrivée.On se rappelle de Madame Onkelinkx alors Ministre de la Justice qui a mis un point final au projet Phenix avec un procès en Justice sans programmes informatiques, et céder le bâton de coursier de relais, en 2007,  à un autre groupe privé qui n'a pas fait mieux. D'après Datanews, le projet serait même empoussièré avec des coupables des deux côtés. Cinq projets avaient été mis en chantier vu que le budget de la Justice était en forte hausse. Projets dont les noms Cheops, Prisma et d'autres sous-projets... Il s'agit d'un consortium de projets dans lequel chacun a ses prérogatives, ses plate-formes personnels ce qui augmente l'overhead pour s'assurer de la compatibilité entre elles. La sous-traitance en offshore n'y est pas absente, ce qui allonge le temps au niveau des contacts et des cultures.   

Depuis fin 2001, date de la première signature, rien n'a encore vu le jour. Echéance du deuxième contrat est pronostiquée en 2014, c'est à dire sept ans de plus avant, qui sait de redéfinir un nouveau délai. Ce qui pourrait prouver que la complexité n'était pas un vain mot. En cause différents paramètres entrent en jeu:  politiques, décideurs qui ne sont la que pendant un terme court, le défilé des ministres en charge, leur changement d'optique et de desiderata, l'évolution du temps, des besoins et des potentiels matériels.

Le secteur public est, peut-être, plus transparent en étalant, au grand jour, les problèmes que le secteur privé, quand la justification des décisions de rupture de contrat s'impose pour des raisons électorales.

En cas d'échec, les dirigeants d'entreprises ont l'habitude de montrer du doigt la partie informatique d'un projet, alors que celle-ci, logiquement, ne devrait être que le maillon déterminant du développement général. Les gestionnaires du projet ne font que répondre à un cahier des charges au mieux de leurs possibilités et parfois en essayant de rattraper un retard. 

Le coût, la qualité, les délais demandés sont des points qui sont traités lors de la prospection de candidatures. Les projets sont alors encore dans les limbes. On pense savoir ce que l'on veut obtenir mais il faut y mettre des notes à la partition. Qui établit les devis de la commande? Qui en fixe les limites? Qui décide de l'acceptation d'un candidat plutôt qu'un autre au moment des choix? Les benchmarks, l'expérience, le prototype, s'ils ont eu parfois la chance d'exister, mais ont-ils été suffisamment concluants?

Des réponses aux questions qui restent très vagues. 

Les décideurs ont des impératifs différents à remplir. Les vendeurs d'un projet sont-ils à mène d'établir un temps théorique nécessaire pour un développement qui n'a pas encore de précédents? Les coûts et les décisions sont pris du côté "client" et évidemment estimés au plus juste prix, c'est-à-dire à une niveau qui tient la corde. S'en suit, un rattrapage par le secteur de l'informatique pour corriger l'estimation trop parcellaire, au départ, simplement pour rester dans la course et obtenir le contrat des premiers.

Dans l'estimation, le prix du hardware, en chute libre, fausse souvent le poids global du prix du software dans l'estimation globale d'un projet informatique, alors qu'ils se sont dissociés depuis longtemps. 

D'après les statistiques, il y a seulement 32% de chance pour qu'un projet arrive à temps avec une réussite finale.

Un projet sur vingt quatre est complètement raté et à recommencer à zéro, "from scratch", comme on dit dans le milieu.

Changer un métier représente un changement organisationnel plus que complexe, presque un modèle de société différent à intégrer dans des habitudes ancestrales, un modèle stratégique qui changent l'architecture d'un département et de son entourage, qui modifie les méthodes de travail avec des fonctions relativement inédites, difficiles à digérer par les "users".

Cela implique la présence de ceux-ci, dès le début, au premier chef puisque c'est eux-même qui vont devoir chevaucher la "nouvelle cavalerie". Entendre après l'implémentation d'un projet "c'était mieux avant" est une preuve que les utilisateurs n'ont pas été questionnés et que le fonctionnel n'a pas fait son travail de recherche des responsables.

Le reste, l'informatique, elle-même, n'est qu'un maillon faible, de cuisine intérieur, d'exécutant, bien moins important.  

Alors, il y a les grosses "usines à gaz", celles qui sont étudiées pour et habilitées à répondre aux désiderata géneraux et qu'il faudra adapter aux besoins spécifiques. Je ne vais pas citer de noms, ils sont connus.

Il y a les systèmes rigides, les "frigides", qui ne permettent pas de customisation ou peu. Dans ce cas, la clé n'est pas fournie. Les autres systèmes, maléables à souhait s'écartent de la version standard, originale. Cet écart, salutaire au début, nécessitera une réinstallation complète à chaque nouvelle version ou release, que le software standard ne comprend pas. Réinstallation qui nécessitera une recherche de compatibilités.

Parmi eux, d'un côté les CRM (Customer Relational Management) et les ERP (Enterprise ressource Planning), de l'autre.

Packages "généraux" et "généreux", s'il en est.

"Généraux" parce qu'il sont appelés à être utilisés tels quels dans leurs généralités sans frais supplémentaires. "Généreux" parce que, dans le cas contraire, le coût de la mise à niveau n'est pas compris dans la localisation, coût qu'il faudra assumer et répercuter pour garder une chance de rester supporté par le fournisseur en cas de déraillements majeurs.

Le syndrome du mégaprojet restera une plaie toujours ouverte pendant toute la durée de l'exploitation puisque ce n'est plus du "clé sur porte". De plus, quand le doigt est mis dans l'engrenage, difficile de changer de système, de plate-forme par la suite.

Dès le départ, un calcul de risques de tous les étages, fait par un gestionnaire de ceux-ci, doit prendre une place essentielle dans un projet de cette envergure.

Il n'est pas rare qu'il y ait des points cachés ou plus politiques derrière toutes décisions. L'aspect protection de l'emploi qui entre en jeu n'est pas illusoire. Restructurer n'importe quel système sous-entend des diminutions de personnels, d'où cette résistance vis-à-vis d'un processus informatique qui est quelque part, un fossoyeur de travailleurs. Qu'on ne disent pas que l'informatique n'a pas contribué à réduire les personnels dans son histoire. Ce serait faux, même s'il a créé d'autres jobs avec plus de parcimonie.

Lors de l'installation, le nouveau système est vendu avec ses avantages, ses améliorations, qu'ils travailleront mieux et plus vite, alors qu'en fait, il s'agit d'une vente forcée. Cela tente aussi de faire oublier que son étude préliminaire se passe en parallèle avec la maintenance de l'ancien avec la même cadence. Certains se complaisent dans un système parce qu'il s'y trouvent bien et ont peur de tous les changements même en mieux. On ne fait toujours bien que ce qu'on connaît bien. 

Évitons le mot corruption qui ferait mauvais genre, ici. 

Les risques peuvent être structurels, passagers, ponctuels entraînant un développement inadéquat ou obsolète bien avant l'implémentation. Le temps très long entre la signature d'un contrat et l'implémentation va vite trouver des développements concurrents sur son chemin et rendre obsolètes les siens.

Le bon chef de projet peut être comparé avec un chef de chantier. Le grutier est capable de creuser une tranchée au milimètre près avec de bons plans. Mais il n'est qu'un maillon. Les erreurs, les ratés se retrouvent dans les effets collatéraux qui feront sauter une canalisation, que l'on retrouve par analogie dans les bugs informatiques. Ce "project manager" fait aussi ce qu'il peut avec les collaborateurs qu'il est loin d'avoir choisi lui-même.

D'après l'auteur de l'article initial, l'optimisme exagéré, l'absence de gestionnaire de risques se partagent les fleurs ou les pots. Les responsabilités des deux, elles, sont partagés.

C'est peut-être, aussi, oublier que les intérêts ne sont pas les mêmes au sommet et à la base. Au sommet, les dirigeants se sentent forcés de lancer la "sauce" le plus rapidement possible, comme un bulldozer, pour résister et contrer la concurrence. Alors, parfois les projets dérapent en porte-à-faux pris par le temps et sont mort-nés.

Chiffrer le prix de ceux-ci est difficile, mais Gartner a évalué les fiascos de tels genres de mégaprojets à plusieurs centaines de milliards de dollars dans le monde.

Vous avez dit "fiasco"?

Avril 2013: Les développeurs belges d'applications ne courent pas que pour le plaisir. Les hackatons rassemblent les developpeurs à certaines occasions. 200 déveoppeurs se réunissaient dans un superhachaton pendant 18 heures d'affilé.

Ces développeurs et designers, des "devigners" connaissent, lors de ces marathons, toutes les couleurs d'une applic...

En Belgique, on compte 35.000 professionnels et 50.000 non-professionnels ou étudiants. Sur des plateformes aussi différentes que Windows8, IOS ou Android sous Java.

Définir le cahier des charges, les différentes petites fonctions à rassembler bien avant de s'intéresser à l'inrterface utilisateur. On passerait ainsi de 4-5 mois à quelques semaines de développement. La facture s'élève de 600 à 1500 euros par jour pour ce genre de 'magicien" du bit. 

 

L'enfoiré,

 

Citations:

 

• « Une petite impatience ruine un grand projet.  », Confucius 
• « Le chemin est long du projet à la chose. », Molière
• « Mon projet préféré ? C'est le prochain. » Frank Lloyd Wright