Difficulté des projets informatique

Aux Etats-Unis, le site Web de l' »Obamacare » est en pleine tourmente.  Ce site, lancé le 1er octobre, est sensé permettre aux américains de comparer et d’acheter une police d’assurance santé. Au lieu de ça, le site accumule problème sur problème. Performances désastreuses, pannes diverses, incidents techniques à répétition. On parle de 5 millions de lignes de code à réécrire (encore que je ne sais pas d’où vient ce chiffre ni qui l’a sorti). A tel point qu’Obama en personne a reconnu les problèmes.

Mais ce type de désastre est malheureusement loin d’être unique. Les projets informatiques qui tournent à la catastrophe sont légion. De nombreuses études ont été conduites sur le sujet, et si les chiffres peuvent varier d’une étude à l’autre, ils vont tous dans le même sens : nombreux sont les gros projets informatique qui échouent et/ou qui fournissent bien moins que prévu. Ne parlons pas de dépassement de budget.

Il existe de nombreuses raisons à cette triste tendance ; en voici quelques-unes.

1) La programmation n’a fondamentalement pas changé depuis les années 50

Un programme reste un script qui met des valeurs dans des cases, lit des valeurs, compare deux valeurs et peut sauter à d’autres endroit du script si une telle comparaison est vraie ou fausse. Les langages de programmation ont beaucoup évolué depuis COBOL, mais la logique métier continue d’être écrite en suivant ce principe de base (exception faite des langages dits fonctionnels, mais qui ne sont pas encore beaucoup utilisés). La complexité des programmes, elle, a drastiquement augmenté – rendant de plus en plus difficile de garder en tête toutes les pièces mobiles d’un programme. Les changements, quant à eux, sont de plus en plus fréquents, rendant la maintenance d’une application de plus en plus difficile. Il n’est pas rare que le cahier des charges évolue avant même que le projet soit terminé. De nombreuses méthodologies ont été inventées pour tenter de dompter cette complexité, mais pour l’instant personne n’a trouvé la recette miracle.

2) Les décideurs ne sont pas suffisamment impliqués

Pour tout projet, les décideurs ont de nombreux choix à faire, et ces choix ont souvent des implications importantes. Le problème est que les décideurs sont des gens très occupés. Ils ne prennent pas la peine de lire en détail le cahier des charges. Ils peuvent prendre longtemps avant de consacrer 5 minutes pour prendre une décision rapide mais importante. Ou ils ne comprennent pas forcément les implications de leurs choix. Ce qui explique pourquoi tant de projets sont des échecs en dépit du fait qu’ils respectent scrupuleusement le cahier des charges. Il n’est pas rare que les utilisateurs se rendent compte que ce qu’ils avaient demandé ne correspond pas à leur besoin, ou demandent des changements en plein développement qui perturbent grandement l’architecture interne utilisée.

3) Les développeurs ne sont pas des pions interchangeables à volonté

Tout projet qui se respecte se compte en homme/mois ou homme/année. Cela suppose que tous les développeurs sont interchangeables, et que 12 personnes abattent en un mois la même besogne qu’une seule personne en une année. Or rien n’est moins vrai. La loi de Brooks affirme que rajouter des développeurs à un projet en retard ne fait que le retarder d’avantage, du fait du temps gaspillé en meetings pour que tout le monde soit à jour. Quant aux développeurs mêmes, ils sont loin de tous se valoir. La différence entre un développeur médiocre et un développeur star est sans commune mesure. Pas forcément en termes de lignes de codes écrites par jour (il y a une limite à ce qu’un développeur peut écrire par jour) mais en terme de qualité du code produit. Les principes de programmation même sont relativement simples, si bien que quasiment n’importe qui peut développer une application suivant un cahier des charges. Par contre, développer une application qui offre de bonnes performances, qui puisse monter en charge et qui puisse être facilement maintenable n’est pas à la portée de tous. On notera que des compagnies comme Google, Microsoft ou Facebook se battent pour recruter les développeurs les plus talentueux qu’ils peuvent. Pourquoi ? Tout d’abord parce qu’étant éditeurs de logiciel, ils reconnaissent l’importance des développeurs de talent. D’autre part parce qu’une entreprise a une vision différente lorsqu’elle embauche quelqu’un que lorsqu’elle la paye à l’heure pour une durée déterminée.

Pour revenir au site d’Obamacare, l’administration américaine a parlé de « tech surge » pour remédier au problème. Le terme de « surge » a été employé par le passé pour décrire l’envoi de troupes supplémentaires en Iraq en 2007 pour calmer la vague de violence qui frappait le pays – envoi qui a eu un certain succès. Par contre, si le but est de ce « tech surge » est uniquement d’impliquer plus de développeurs, cela pourrait causer plus de problème qu’il n’en résout.

4) Les dates butoir serrées peuvent rallonger le temps de développement

Il n’est pas rare que les délais soient serrés et que la date butoir soit impossible à reculer pour des raisons diverses – comme dans le cas du site d’Obamacare. Que ce passe-t-il lorsque des complications rendent les délais de plus en plus difficiles à respecter ? Les développeurs travaillent plus d’heures par semaine, comme les nuits et les weekends. Ils dorment de moins en moins. En apparence, leur productivité augmente – ils écrivent plus de lignes de code par semaine. Mais en apparence uniquement. Car le cerveau humain a ses limites, et a une fâcheuse tendance à commettre des erreurs lorsqu’il manque de sommeil. C’est là où le nombre de bugs explose. Or un bug prend bien plus de temps à corriger que d’écrire du code « propre ». Pire, c’est là où certains choix malencontreux d’architecture peuvent être pris (là encore du fait du manque de sommeil) – et ces choix sont bien plus difficile à corriger que quelques bugs.

Et c’est justement lorsque les délais sont serrés que les bugs ont le moins de chance d’être détectés. Les tests qualité sont en effet les premiers à être sacrifiés lorsque les délais doivent être respectés à tout prix.

Quelles conséquences ?

Je prendrais pour exemple un projet dont j’ai été personnellement témoin. Dans les années 90, suite au boom Internet, n’importe qui qui le désirait pouvait travailler dans l’informatique. En manque de main d’oeuvre, les sociétés de services (SSII) embauchaient à tour de bras n’importe qui, les formant au lance-pierre – souvent avec des résultats médiocres. J’ai ainsi connu le cas d’un employé d’une SSII, parachuté chez un client pour développer une application en C++. Ce développeur ne savait même pas comment déterminer la version de Windows de sa machine (Windows NT ou 95 à l’époque) ! Il a certes terminé le projet. Le problème est que le logiciel avait des performances si terribles que je ne sais pas s’il n’a jamais été utilisé.

Où sont donc les sociétés de service responsables, qui embauchent du personnel qualifié et qui évitent à leurs clients de commettre des erreurs ? La plupart du temps elles sont éliminées lors de l’appel d’offre. Lorsque le client ne regarde que le prix, cela ne favorise pas les SSII qui veulent embaucher du personnel talentueux et expérimenté. Lorsque la seule autre chose qu’il regarde est le cahier des charges, cela favorise les SSII non scrupuleuses qui vont fournir l’appel d’offre le moins cher possible, et qui vont se rattraper lorsque le client va immanquablement demander des changements au cahier des charges (« Vous voulez changer X, Y et Z ? Ca va vous coûter cher ! « ). Quant à la société de service honnête qui va dire au client que les délais ne sont pas raisonnables, elle n’a que peu de chance d’être écoutée…

Explore posts in the same categories: Non classé

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s


%d blogueurs aiment cette page :