En regardant le très bon reportage « Prêt à jeter » passé dans le Théma d’Arte mardi soir (le 15 février 2011), je me disais que la même démarche s’applique depuis bien longtemps  à l’informatique…

Pour ceux qui n’ont pas eu la chance de le voir, le reportage décrivait l’approche consistant à intégrer volontairement dans la conception des produits de grande consommation des éléments limitant leur durée de vie : c’est l’obsolescence programmée.
L’amoralité de ce type d’approche reste la même pour les prestations intellectuelles et le développement logiciel. Bien entendu, en informatique, le contexte est différent, et n’a pas de conséquence directe sur l’environnement. Par contre, la démarche reste la même : le fournisseur fait une action délibérée qui se traduit pour le client par le fait de payer plus cher.
Dans ce billet d’humeur, nous ne nous intéresserons pas à l’obsolescence programmée des logiciels (les principes étant connus et restant très proches que ceux utilisés pour les produits de consommation industriels) mais à d’autres possibilités annexes offertes aux fournisseurs de logiciels. Par la suite, nous utiliserons le terme « composant » mais « logiciel » ou « produit informatique » conviendrait tout aussi bien. Quant au terme « fournisseur », il désigne tout éditeur informatique qui réalise des prestations d’accompagnement technique (consulting, assistance et expertise technique).

Imaginons ce dialogue fictif entre Vipère Noire (consultant J2EE de la vieille école) et Priscilla (jeune développeuse J2EE encore naïve).

Priscilla : tu as vu le reportage d’hier « Prêt à jeter » sur Arte ? ça fait froid dans le dos

Vipère Noire : oui je l’ai vu, mais ça ne m’étonne pas, on fait pareil en informatique. Il y a des années, j’ai un de mes directeurs techniques qui disait « non, on ne va pas mettre des boucles d’attente exprès pour ralentir la v1 du soft, mais bon, il serait bien qu’il reste une marge d’optimisation pour qu’on nous achète la v2 ou qu’on nous passe un contrat de maintenance évolutive ».

Priscilla : oui, c’est un sujet à part entière qui est bien connu : il s’agit de vendre la version suivante des composants parce que les fonctionnalités (ou performances) ne sont volontairement pas complètement couvertes dans la version courante.

Vipère Noire : oui, mais je veux te parler d’un autre moyen exploité moins ouvertement par les fournisseurs de produits informatiques. Il s’agit – dans le cadre de la vente de composants – de déclencher des prestations d’expertises supplémentaires. En fait,  Il s’agit d’inclure des effets induits (non désirables) dans la conception des composants vendus.

Priscilla : ça me parait un peu dangereux pour le fournisseur. Il doit constamment naviguer entre « amener des revenus récurrents supplémentaires (expertise technique) autour du produit » et le point de non retour où le client abandonne le produit ou composant informatique. En plus, le client peut légitiment considérer qu’il s’agit de bogues du composant.

Vipère Noire : non, parce qu’en fait je ne parle pas d’un composant qui a des bogues flagrants ou dont les effets induits se manifestent systématiquement dès qu’on l’utilise. Je te parle d’un composant qui est conçu pour fonctionner correctement dans son cadre d’utilisation normal et qui ne pose problème que si on sort de ces conditions.

Priscilla : ok, et comme ça, la prestation déclenchée est complémentaire, elle ne rentre pas dans le cadre d’un éventuel contrat de maintenance existant.

Vipère Noire : c’est tout à fait ça. Et pour te le prouver, il y a quelques années, mon directeur technique m’a passé ce document que je vais te montrer :

Règles de conception permettant de déclencher des prestations de services récurrentes

Il s’agit de règles utiles pour amener le client à déclencher des prestations complémentaires tout en garantissant une zone de sécurité au fournisseur. Le principe est de déclencher un effet induit qui ne peut être directement qualifié de bogue. Il s’agit par exemple de rétention mémoire, de mauvaise performance, de non résistance à la montée en charge… En plus, cet effet induit doit apparaître comme étant du à une mauvaise utilisation du composant (la responsabilité du client doit être engagée). Il s’agit donc en fait de « Règles de conception de composants dont l’utilisation sans précautions a des effets induits ».

Règle 1.

Pour éviter tout reproche de la part du client, il faut accompagner le composant d’une documentation technique complète indiquant les précautions d’utilisation (s’il y a un problème, c’est que le client n’a pas lu la documentation).

• Pour bien montrer qu’il ne cache rien, le fournisseur peut aussi fournir le code source du composant. Les probabilités que le client final puisse en tirer des conclusions sont très faibles. En plus, le client n’est sensé y trouver que des explications confirmant des règles d’utilisation qui sont déjà correctement documentées.

Règle 2.

Les précautions d’utilisation doivent paraître conformes à « l’état de l’art » (s’il y a un problème, c’est bien parce que les développeurs du client sont mauvais ou pas assez expérimentés).

Règle 3.

Ces précautions ne doivent pas avoir un caractère évident (elles ne doivent pas dépendre de façon trop évidente des fonctionnalités inhérentes au composant). Sinon, les développeurs pourraient immédiatement en déduire quels pièges ils doivent éviter.

Règle 4.

Les précautions d’utilisation ne doivent pas être « tout ou rien » : on doit pouvoir continuer à utiliser le composant (avec toutes ses fonctionnalités) ; les effets cachés ne doivent pas être visibles immédiatement. Il faut qu’il y ait déjà eu un maximum d’utilisations effectives du composant. C’est très important parce que plus le nombre d’utilisations du composant est important, plus il est difficile pour le client d’envisager de s’en séparer. En plus, ça augmente les opportunités d’expertise technique (pour couvrir toutes les applications où le composant a été utilisé)

Règle 5.

L’effet induit ne doit pas être systématique pour éviter une levée de bouclier du client, il vaut mieux que l’effet induit n’ait lieu que dans certains cas d’utilisation.

Règle 6.

Les effets induits d’une mauvaise utilisation ne doivent pas facilement être détectables automatiquement. Par exemple, ils doivent difficilement être vérifiables dans l’environnement de développement ou de test standard. Au contraire, ils doivent nécessiter un outillage important (ex : effet détectable seulement lors d’un test de montée en charge), un temps de test important (ex : effet caché qui ne se déclenche que lors d’une utilisation récurrente, c’est par exemple le cas pour une rétention mémoire) ou des interventions manuelles (mesures non standards).

• Les meilleurs effets induits dus à une mauvaise utilisation sont donc souvent : mauvaises performances, rétention mémoire accrue, utilisation CPU trop importante…

Règle 7.

Il n’y a pas de niveau de performance qui soit universellement reconnu (par le marché), encore moins garanti par le fournisseur : il faut que ce soit le client qui les impose et de préférence a posteriori. Si le client reproche au fournisseur que son composant TABLE met plus de 10 secondes sous IE6 pour afficher 40 colonnes de 10.000 lignes et qu’il ne l’a pas précisé dans le cahier des charges, il n’a qu’à s’y prendre à lui-même. Dans le même ordre d’idées, il ne faut pas qu’on puisse facilement comparer les performances du composant du fournisseur avec celui d’un concurrent. Les métriques associées ne doivent donc pas être disponibles.

Priscilla : arrête, je n’imagine pas un instant qu’un manager prenne le risque de faire circuler ce genre de document. Le risque est bien trop grand d’avoir une fuite.

Vipère Noire : si tu as bien regardé le reportage d’Arte, tu as bien vu qu’il y avait des documents de ce type (pour interdire aux fabricants de vendre des ampoules qui durent plus de 1000 heures).

Priscilla : oui, mais ces documents étaient tout à fait confidentiels.

Vipère Noire : bon. Effectivement, je raconte des histoires. Ce document est bidonné. Par contre, le conseil de mon directeur technique était bien réel.

Priscilla : tant qu’à faire, tu pourrais aussi parler des trucs permettant de rendre plus difficile l’identification des problèmes dans les applications (par exemple en favorisant la non répétabilité de ces problèmes) et donc de limiter la capacité pour les équipes du client d’identifier par eux-mêmes le problème, c’est là aussi un sujet à part entière.

Vipère Noire : ça n’est pas le sujet, là, je te parle uniquement de la façon dont un fournisseur peut jouer sur les conditions d’utilisation

Priscilla : ok

Vipère Noire : il n’empêche que j’ai rencontré des composants qui semblaient tout à fait obéir à ces règles. Par exemple, je peux te parler d’un composant destiné à faciliter la mise à jour dynamique (via AJAX) d’une portion d’une page jsp. Pour le développeur de page JSP, l’implantation est très simple : il faut juste insérer une balise JSP pour indiquer le début du fragment d’HTML à mettre à jour, et une autre balise pour en indiquer la fin. Au runtime, ces balises JSP génèrent simplement des balises de marquage dans la page HTML (par exemple des balises DIV avec des identifiants spécifiques). Ces balises sont ensuite utilisées lors de la mise à jour dynamique de la zone.

Au runtime, on peut déclencher via javascript une mise à jour du fragment HTML limité par les balises de marquage. Cette mise à jour consiste à effectuer un appel AJAX sur le serveur, appel qui réévalue totalement la page JSP sur le serveur. Sur le serveur, on ne conserve du code HTML résultant de cette évaluation que la partie située entre les balises de marque générées ultérieurement. Ce fragment HTML situé entre les balises de marquage est alors renvoyé en réponse de l’appel AJAX . Dans le navigateur, javascript remplace ensuite le DIV de marquage, par le nouveau fragment HTML contenu dans le retour AJAX.

Priscilla : Un composant de ce type est super, il est facile à utiliser et pratique pour des développeurs qui ne veulent surtout pas avoir à gérer directement du javascript.

Vipère Noire : Néanmoins, si tu étudies les choix d’implémentation. La page JSP est réévaluée totalement lorsqu’on veut mettre à jour dynamiquement une partie de la page dans le navigateur. Le seul intérêt de cette réévaluation totale, c’est que si la page comporte des scriptlets ou des balises JSP d’affectation de beans en dehors du fragment qu’on souhaite réévaluer, leurs effets de bords pourront être utilisés par la partie mise à jour dynamiquement. Si un développeur a dans sa page un scriptlet qui fait des appels en base de données, l’appel aura lieu à chaque fois que l’on veut remettre à jour la zone que cela soit souhaité ou pas.

Priscilla : La documentation du composant précise que la totalité de la page est réévaluée à chaque fois ?

Vipère Noire : oui, et donc la règle 1 est respectée.

Priscilla : En plus, le fournisseur peut se réfugier derrière l’état de l’art : « il est clair qu’il est déconseillé d’utiliser des scriplets ou des balises d’affectation dans les pages JSP, tout le monde sait çà depuis le MVC 2 de Sun » (règle 2).

Vipère Noire : Oui. Mais comme, la tendance générale des acheteurs des grands comptes est de baisser le tarif journalier des développeurs, les clients se retrouvent avec des développeurs juniors qui n’ont pas forcément le recul et les connaissances nécessaires.

Priscilla : oui, et comme la fonctionnalité du composant est « une mise à jour dynamique d’une portion de JSP » ; tu vas me dire que le développeur ne peut pas en conclure que sur le serveur, toute la page JSP est réévaluée ce qui est conforme avec ta règle 3.

Vipère Noire : en effet. En plus, le composant continue à fonctionner, même s’il y a des scriptlets dans la page. La règle 4 est donc aussi respectée.

Priscilla : Oui parce que c’est seulement si ces scriptlets font des traitements importants sur le serveur (appels en base de données par exemple) que l’effet se fait sentir en termes de performance. L’effet caché n’est donc pas systématique, et il dépend de l’utilisateur, donc la règle 5 est couverte.

Vipère Noire : quant à la règle 6, elle nécessite que les effets induits d’une mauvaise utilisation ne doivent pas facilement être détectables automatiquement. C’est en effet le cas ici, parce que les mauvaises performances dépendent du traitement fait par les scriptlets qui n’a pas du tout les mêmes performances en test et en production.

En ce qui concerne la règle 7, le composant en question n’est pas standard, il n’y a donc pas de niveau de performance qui soit universellement reconnu (par le marché).

Priscilla : tout ça n’est pas une preuve. En plus, là, le rasoir d’Ockham s’applique totalement : l’explication la plus simple reste une mauvaise conception initiale du composant, pas une volonté malfaisante de la part du fournisseur.

Vipère Noire : arrête ! je suis sûr que tu as appris ce qu’est le rasoir d’Ockham dans Big Bang Theory !

Priscilla : c’est ça, et toi tu développais en Occam sur transputer, peut être ?

Vipère Noire : tu as raison, ce composant a sans doute été juste mal conçu. Peut-être mais en tout cas, il fait carton plein ! Il vérifie la plupart des règles précédentes et effectivement, il a l’avantage pour le fournisseur d’entraîner des missions d’expertises assez récurrentes. Par exemple, mon équipe a du intervenir sur une page développée par le client qui utilisait ce composant et comportant 600 lignes de scriplet en haut de la page JSP (lignes comportant des appels en base de données).

Priscilla : et vous avez corrigé le problème ?

Vipère Noire : oui, par une refactoring complet de la page qui a d’ailleurs amené à se passer de ce composant. Le client avait cependant une excuse : il n’avait même pas utilisé ce composant explicitement, il était inclus d’office dans un autre composant du même fournisseur .

Priscilla : et comment a réagi le client ?

Vipère Noire : Ce qui est intéressant, c’est que le client lui-même, en tout cas ses équipes techniques, a pris conscience du problème. Un responsable technique du client en question m’expliquait que « le niveau des développeurs ayant tellement baissé (à cause des baisses des grilles de tarifs journaliers) » que l’utilisation d’un tel composant devrait maintenant être interdite.

Priscilla : C’est marrant, parce qu’en faisant ce constat, le client ne remettait en cause ni les choix d’implantation du composant ni le fournisseur, mais bien le comportement de sa direction générale vis-à-vis des prestations informatiques.

La morale de l’histoire

Bien entendu, si beaucoup d’éléments de ce dialogue comportent des éléments existants (entre autres choses, l’exemple est réel), il n’en n’est pas de même en ce qui concerne la suspicion d’une mauvaise foi du fournisseur.

En fait, l’amoralité potentielle de l’utilisation de telles règles n’a aucune importance pour le client. Le client ne voit que les problèmes réels auxquels il est confronté, que ceux-ci soient issus d’une volonté délibérée ou simplement d’une conception maladroite des composants que ses équipes utilisent.

Les aspects positifs

Il y a quand même un aspect positif. En effet, pour arriver à déclencher des missions d’expertise (et pas un rejet pur et simple du composant par le client), le fournisseur doit quand même assurer un certain niveau de qualité à son composant. Nous avons en effet exclu de cette discussion le cas des bogues explicites mais aussi les composants qui ont des effets cachés, même dans le cas d’une utilisation nominale. Cela implique déjà un certain niveau d’exigence :

• Un fonctionnement conforme dans le cas de l’utilisation préconisée
• L’existence d’une documentation technique de bon niveau (règle 1),
• Une utilisation « conforme à l’état de l’art » (règle 2),
• Une bonne résistance (fonctionnement en mode dégradé) (règle 4)

Comment le client peut contrer ce problème

Par ailleurs, la règle 6 permet au client de savoir quels aspects il doit regarder en priorité :

• Les performances,
• La rétention mémoire,
• L’utilisation CPU,
• La résistance à la montée en charge

Néanmoins, il n’y a pas que des bonnes nouvelles : le test de ces aspects peut être difficile, voire même peu compatible avec l’utilisation d’une plateforme d’intégration continue (la durée des tests peut en effet être très importante). La problématique de ces tests est générale, et n’est pas liée à la bonne ou mauvaise utilisation, encore moins au respect des bonnes pratiques. Et le coût de la mise en place de ces tests est important, surtout si on souhaite couvrir tout le périmètre du composant :

• Axe ressources : temps, occupation mémoire (instantanée et en rétention), charge CPU, taille (en transport sur le réseau), nombre de transactions par seconde
• Axe fonctionnalités (par exemple, pour un composant graphique TABLE, l’affichage initial, la pagination, le tri sur une colonne…),

Plutôt que de faire ces tests exhaustivement, le client peut être tenté de recourir à une couverture contractuelle en demandant au fournisseur de garantir le niveau de performance. Par exemple, au niveau des temps, le client pourrait demander au fournisseur une garantie, pour chaque fonctionnalité :

• De mesure absolue (ex : le temps maximal pour une taille de données précisée)
• De complexité des algorithmes utilisés par rapport aux données (ex : pour un composant graphique de type TABLE, donner la complexité de l’algorithme en fonction du nombre de lignes et du nombre de colonnes).

C’est assez intéressant pour le client parce que du coup, il peut se contenter de faire des tests ponctuels (juste pour vérifier que les engagements du fournisseur sont suivis et demander des corrections le cas échéant). Cependant, on imagine mal un fournisseur prendre ce genre d’engagement, surtout que s’il veut garantir un prix faible des composants ; il ne peut répercuter le coût afférant à la garantie. Bien sûr, en ce qui concerne les engagements contractuels, le client peut éventuellement faire jouer la concurrence en incluant dans le cahier des charges de choix des composants cette dimension d’engagement.

Dans l’hypothèse prise ici où les règles d’utilisation recouvrent en fait les bonnes pratiques, le client peut commencer par s’assurer que ces bonnes pratiques sont suivies par les équipes de développement. D’un point de vue RH, çà implique :

• D’augmenter le niveau d’expertise des développeurs internes,
• De conserver ces développeurs plus longtemps sur ces projets (pour qu’ils puissent acquérir les connaissances liées à l’utilisation des composants en question)

Ces deux options ont un coût qui ne semble pas très compatible avec la tendance actuelle. La baisse des tarifs journaliers implique de ne pas avoir ce niveau d’expertise, en plus, la simple augmentation automatique des salaires des juniors implique un renouvellement fréquent des développeurs sur ces projets (les contraintes financières imposant de conserver constamment des débutants).

Si le client ne se donne pas les moyens de mettre en place les tests nécessaires, ne réussit pas à obtenir des engagements contractuels du fournisseur et ne peut pas conserver des équipes techniques avec le niveau d’expertise suffisant, lui reste t’il des solutions ?

Bien entendu, le client peut demander au fournisseur de concevoir des composants pouvant être utilisés dans n’importe quel contexte et par n’importe quel niveau de compétences. Néanmoins, des composants de ce type sont beaucoup plus complexes à concevoir même en limitant drastiquement leur fonctionnalité (et donc leur intérêt même). Et même si le fournisseur prend des précautions légitimes telle que « ne pas préjuger du niveau technique des utilisateurs », jusqu’à quel niveau de non technicité doit il les appliquer ?

Pour une solution répondant à cette problématique

L’idéal serait une solution ne touchant ni au périmètre du composant, ni à sa capacité d’être utilisé par des experts aussi bien que par débutants, et qui permettrait au client de :

• s’assurer que ses équipes utilisent le composant dans son cadre d’utilisation nominal,
• avoir une garantie générale (qui soit technique et pas contractuelle) du comportement du composant dans le cas d’une utilisation nominale

Pour des détails sur cette solution « miracle » et bien…. il faudra attendre un nouveau billet…