Tant d’efforts consentis, tant d’heures passées par ses concepteurs à préparer une application pour son entrée dans le grand monde. Après de nombreux mois, voir des années de gestation sur un serveur et alimentée par ses concepteurs, elle peut faire face à sa future famille : ses clients. Enfin le grand jour, la voici présentée et installée chez le client. La version 1.0.0 peut s’afficher au grand jour.
Les informaticiens à l’origine de sa création la voient partir sur d’autres serveurs. Ce moment émouvant leur rappelle le travail effectué : les longues semaines passées à concevoir la base de données, à dessiner les interfaces (l’apparence physique de l’application), à implémenter les règles métiers attendues par le client.
Si le client est satisfait, leur application leur amènera du travail. Il faudra l’adapter pour quelle corresponde encore mieux à ses utilisateurs finaux. Ils ajouteront de nouvelles fonctionnalités. Ils corrigeront ses petits défauts pour qu’elle plaise au client. Peut être qu’elle se fera une réputation dans le domaine du client. Ainsi, d’autres clients souhaiteront l’amener sur leurs serveurs.
Arrêtons ici l’anthropomorphisme. Autrement mes propos précédents risque d’être mal interprétés. Même si les bons développeurs mettent une part d’eux mêmes dans leurs créations, une application est à l’origine un contrat.
Et comme tout contrat, il est figé dans un environnement qui évolue. Un arbitrage sera alors nécessaire pour revoir le périmètre des fonctionnalités de l’application. Et la version 1.0.0 livrée pourra être partiellement différente de la version imaginée à l’origine. Cela donnera à l’ESN la possibilité de vendre de la maintenance les futures versions (1.0.1, 1.1.0, 2.0.0, …)
Comme tout contrat, il se peut qu’il soit annulé pour des motifs définis antérieurement. Dans ce cas, l’application ne sortira jamais. Pour autant, elle n’aura pas été inutile. Le REX (retour d’expérience) permettra à l’équipe de développement de progresser dans ses méthodes. De plus, certains développements pourront être utilisées pour de futures applications.
Pour les applications qui sortent au grand jour, les destins sont très variés. Une application peut être conçue pour n’être utilisée qu’une seule fois. Dans ce cas, on parle d’application ‘oneshot’. Vite écrite sur un besoin très cadré, une fois sa mission réalisée, elle devient inutile et disparaît alors dans un répertoire d’un serveur d’archivage pour un hypothétique rappel. Un oneshot ne sert qu’une fois. Par contre, ses sources sont souvent réemployées.
Les destins des applications sont définis bien avant leur création. Ainsi, il n’est pas impossible que pour une application qui vient juste de sortir, sa remplaçante soit déjà en cours de développement. Mais le destin est farceur, et le succès arrive parfois de façon inattendu. Un utilisateur satisfait de son application ne verra pas l’intérêt de la remplacer par une autre application qui n’apporte pas d’améliorations critiques. Et c’est ainsi que les applications bancaires tournent encore sur des AS-400 emmurés.
Une application n’a pas que des vocations professionnelles. Un jeu vidéo est une application informatique. Et le destin peut l’amener au succès. Une règle de 3 mal appliquée a donné à l’héroïne de Tomb Raider des arguments qui l’ont rendue célèbre. De même, un simple bac à sable donc le principe n’a pas évolué depuis 15 ans est l’un des jeux les plus célèbres au monde et présents sur des millions de machines.
Même dans le cas des applications ‘sérieuses’, certains existent depuis des décennies et ne cessent d’évoluer. J’utilise la version 80.0.3987.149 de Chrome sous Windows 10 (version 18362.720). Mes serveurs Linux utilisent la version 4.19 du noyau. Et les développeurs de ce dernier viennent de mettre à jour les pilotes pour utiliser un lecteur de disquettes.
Lors de son entrée dans le monde réel, le destin d’une application est loin d’être écrit. Certains peuvent penser que c’est la chance qui permettra à quelques élues de figurer dans le panthéon de l’informatique. Il est vrai que les raisons des succès et des échecs des applications sont parfois difficile à établir. Et les quelques exemples que j’apporte dans cet article ne sont qu’une infime part de leur histoire.