28/06/2004 : Les coûts de développement

Face à la demande des utilisateurs, les logiciels se multiplient. Oui, mais voilà. L'activité n'est pas assez rentable, en particuliers pour les entreprises qui n'ont pas pour activité première l'édition. En effet, pour la plupart des entreprises, l'informatique n'est qu'un outil, et pas une fin en soi.

Reste donc à trouver les solutions afin de diminuer les coûts. Ces solutions tournent autour des développeurs eux-même, mais aussi autour des outils de développement, les deux sont en fait relativement liés.

Repartons en arrière... Il y a quelques années (1997-2000) le secteur informatique était plutôt florissant. La demande était si forte (en particuliers autour des projets Euro et An 2000) qu'il y avait une véritable pénurie d'informaticiens, et une flambée des coûts.

Ces points ont favorisé des profils faibles compétences. Les porjets ont donc souffert d'un allongement des temps de développement. Des palliatifs ont été mis en place parallèlement par la modification des languages et outils de développement.

Jusqu'alors, la politique était de faire confiance au programmeur. Cette époque est maintenant révolue. On fait tout pour empêcher le programmeur de pouvoir se tirer une balle dans le pied.
Les langages fortement typés ont refait irruption. Les sources potentielles de danger ont été soigneuesement évitées, à l'instar du pointeur en Java.

Certes, les risques ont été quelque peu réduits... au prix d'une prise de poids conséquente des produits et de la chute notable des performances.

Performances ? Obésité ? Peu importe, nous avons maintenant la puissance pour venir combler ces éffets secondaires! Qui n'a jamais entendu voire utilisé cet argument ?

Tout le monde y a trouvé son compte : baisse du temps de développement, baisse de coût des programmeurs, et quelques éditeurs d'outils en position difficile ont pu revenir au devant de la scène et raccrocher à leur croissance perdue.

Cette euphorie à fait croîtres les langages, les concepts. Je passe les notions 100% marketting qui n'ont aucune utilité pratique (n-tiers, middleware, ...).

Corba a fait son chemin. On le retrouve partout. Java, n'en parlons pas. On veut même nous faire croire qu'on l'utilise pour faire des clients légers ! XML ? Encore un [sacré] Graal.

Le plus drôle, c'est que tout le monde semble y adhérer !

Dans la pratique, une application C++ qui tourne en 2 minutes avec 50Mo de RAM, met 15 minutes et 1,5Go avec l'interface CORBA ad hoc optimisée pour nos besoins. Cerise sur le gateau, la mémoire n'est libérée que quand le client léger est Deconnecté.... ! ! !

Pour la petite histoire, le serveur qui nous a servi de plateforme de test est un Spark Ultra-4 quadri-cpu muni de 4Go de RAM + 8Go de swap. Moyennement chargé, il est tombé à genoux lors de notre test et nos écrans gelés pendant 9 minutes.

Ce test visait à vérifier la faisabilité d'une mise à jours d'une nouvelle version orientée client léger d'un progiciel orienté finance des marchés. Il mimait la connexion d'un seul utilisateur! alors qu'en moyenne une vingtaine est connectée. Par comparaison, son client "lourd" sous eXceed (P3 / 256 Mo de ram), devra être remplacer par un « client léger » (P4 / 1Go de ram minumum conseillé).


retour