L'idée qui se cache derrière cette fausse vraie idée, c'est que le cycle des versions donne l'impression que l'informaticien travaille dans son coin, et livre régulièrement ses élucubrations, les clients subissant ou profitant les changements. L'informatique, ça n'est jamais que le remplacement des méthodes papier et manuelles par un traitement automatisé. Finalement, sans ordinateurs, on y arriverait aussi. De là découle aussi la seconde idée, vraie cette fois : l'informaticien est là pour prendre le boulot des autres et le donner à des machines. Le progrès fait qu'on a de moins en moins besoin d'intervention humaine dans un processus automatisable.

Pourquoi une idée reçue ? Parce que l'informaticien, il n'est pas là pour travailler pour lui, mais il devrait être là pour rendre délivrer un service à un autre, si possible plusieurs autres, leur ôter les charges laborieuses pour se concentrer sur la partie créative/motivante de leur métier.

Malheureusement, ce n'est pas toujours le vecteur d'innovation du métier, et c'est pour ça qu'on pense qu'un informaticien s'auto-finance en produisant une maquette, des alpha, des beta, des pré releases, des livraisons, puis de nouvelles versions. De la correction de bugs, techniques, fonctionnels, d'IHM. Mais si l'on faisait un sondage, je pense qu'on obtiendrait une toute autre version : une fois développée, une application ne devrait pas être génératrice de "travail". Or dans la presque totalité des grandes applications, le coût global de l'application pourrait se résumer à 20% de développement "utile", et 80% de gestion de plannings et de surdéveloppement. On va appeler un surdéveloppement un développement qui aura été improductif (remplacé par un autre parce que ne convenant pas, ...)

Alors, oui, il y a le progrès technique qui rend obsolète (comment parler d'obsolescence pour un produit fonctionnel à 100% ?) certains développements. Il n'empêche.
Un cycle typique de développement se fait en plusieurs phases, dont maquette, pré versions, et release version. La maquette va servir au client de se faire une idée du produit final, mais aussi d'émettre des doutes sur certains points, proposer des modifications, etc. Une préversion permet de vérifier que dans un environnement proche de la production, l'application fonctionne comme on l'entend. La release, c'est ce qui sera donné au client.

Et c'est là que le bas blesse, la plupart des versions ne satisfont pas le client. Comment faire alors... Proposer des nouveaux développements bien sûr ! Mais d'où vient de dysfonctionnement ? Il se trouve souvent dans l'incompréhension entre le langage du développeur et le langage du client. Il est anormal que les défauts trouvés en production n'aient souvent jamais été même évoqués lors de la démonstration de la maquette. C'est que souvent, cette maquette, tout comme les préversions, n'est jamais montrée aux utilisateurs, le commercial croyant bien faire en pensant pour les utilisateurs.

Aujourd'hui, notre gestionnaire des incidents et changements (suivant les recommendations ITIL) a "évolué". Grosse montée de version. En un jour d'utilisateur, il faut savoir que à notre étage, aucun utilisateur n'a aimé cette nouvelle version. Lenteurs, bugs divers, aucune formation à la nouvelle interface. Et pourtant, aucun retour arrière à l'ancienne version ne sera mise en place, parce que cette version, c'est "le progrès"...

Et vous savez quoi ? L'industrialisateur de l'application, hé bien... c'est la personne qui m'avait jeté la dernière fois. Le monde est petit, vraiment petit.

Note : pour ceux qui se disent qu'une seconde de lenteur, ce n'est rien, dites-vous que derrière, cette seconde risque d'énerver l'utilisateur qui va la subir pour toutes les applications qui se dont dit ça. Et 1 seconde par heure pour 1000 utilisateurs, c'est 7000h de pertes sèches quotidiennes, je vous laisse imaginer le chiffrage à l'année...