Un système hérité[1], système patrimonial[1] ou système obsolète[1](en anglais : legacy system) est un matériel ou un logiciel continuant d'être utilisé dans une organisation (entreprise ou administration), alors qu'il est supplanté par des systèmes plus modernes. L'obsolescence de ces systèmes et leur criticité les rendent difficilement remplaçables sans engendrer des projets coûteux et risqués.

Par exemple, les banques et assurances qui ont informatisé leur traitement des informations dans les années 1970 ont des applications qui tournent avec du code hérité souvent en COBOL ou en Fortran. Les risques pris pour réécrire l'application dans un autre langage et les coûts inhérents au changement dissuadent souvent la modernisation du système, voire son remplacement.

Les entreprises peuvent avoir des raisons sérieuses de conserver un système hérité, par exemple :

  • Le système fonctionne de manière satisfaisante, et son propriétaire décide de ne pas allouer de ressources à l'analyse du rapport bénéfice/risque de l'évolution du système, possiblement par heuristique assumée, aversion au changement, voire par négligence ou ignorance de répercussions néfastes envisageables et raisonnablement anticipables.
  • Les coûts pour retravailler ou remplacer le système seraient prohibitifs, parce que celui-ci est de grande taille, monolithique (en), complexe.
  • Former les utilisateurs au nouveau système demanderait beaucoup de temps et d'argent, ceci étant à comparer avec les avantages apportés par le remplacement du système (ceux-ci pouvant être nuls).
  • Le système requiert une haute disponibilité et ne peut être interrompu. De plus, les coûts pour concevoir un nouveau système atteignant le même niveau de disponibilité seraient élevés. Ces systèmes contrôlent des secteurs critiques, tels que : gestion bancaire, réservations, contrôle aérien, distribution d'énergie (réseau électrique), contrôle de centrale nucléaire, installations de défense militaire, trafic ferroviaire, etc.
  • Le fonctionnement du système existant n'est pas entièrement maîtrisé. De telles situations peuvent se produire lorsque les concepteurs du système ont quitté l'entreprise et que celui-ci n'est pas entièrement documenté, ou bien que la documentation a été perdue ou pas mise à jour.

Exemple de la NASA

modifier

La NASA continue d'utiliser des technologies des années 1970. Les processus de validation sont très lourds et coûteux. Aussi la NASA a été obligée d'acheter sur eBay des microprocesseurs 8086 en 2002 pour les systèmes de contrôle des navettes spatiales parce qu'ils n'étaient plus fabriqués par Intel[2]. Ils sont bien connus des développeurs, et étant plus gros, ils résistent mieux aux radiations que les microprocesseurs récents.

Un système hérité d'une ingénierie rigoureuse peut se perpétuer avec une portée incommensurable. Les normes des chariots romains sont à l'origine de celles des trains et des tunnels ferroviaires, et ont limité la taille des réservoirs auxiliaires des navettes ravitaillant la station spatiale internationale[3].

Conséquences

modifier

Les systèmes hérités sont généralement considérés comme problématiques pour différentes raisons :

  • Maintenance compliquée par un manque de documentation, de compétences, de composants (disparus)
  • Maintenance potentiellement coûteuse
  • Lenteurs dues à l'obsolescence du matériel
  • Ergonomie inférieure à celle des systèmes modernes
  • Risques de panne accrus
  • Vulnérabilités liées à l'absence de correctif
  • Absence d'évolutivité et d'adaptation aux nouveaux besoins fonctionnels ou a une augmentation de la volumétrie

Améliorations et solutions

modifier

Améliorations

modifier

Le développement d'une nouvelle interface homme-machine généralement plus ergonomique peut être une manière d'améliorer l'expérience utilisateur mais ne constitue pas une réelle solution, pas plus que la virtualisation des machines ou des applications qui permet plutôt de conserver les systèmes hérités en les décorrélant du matériel ou du système d'exploitation, leur offrant ainsi une deuxième vie[4].

Lorsqu'un système hérité ne peut pas être supprimé, il est toujours possible de changer son interface. La plupart des développements consistent à ajouter de nouvelles interfaces à un système hérité. La technique la plus proéminente est de remplacer l'accès à une application via un terminal de mainframe par une accès via une interface web. Cela peut réduire la productivité du personnel en raison de temps de réponses plus lent, et d'actions à la souris plus lentes. Toutefois, même avec cette lenteur, cela est souvent perçu comme un "upgrade", parce que le style de l'interface web est familier des nouveaux utilisateurs ou employés, à qui il semble plus intuitif[5].

Solutions

modifier

Il faut prévoir l'apurement progressif des systèmes hérités par une démarche régulière d'urbanisation du système d'information.

Utilisation du terme Legacy en informatique

modifier

Le terme legacy support (ou support legacy) est souvent utilisé en conjonction avec des systèmes légacy. Le terme peut désigner une fonction d'un nouveau logiciel. Par exemple, un système d'exploitation avec un "support legacy" peut détecter et utiliser un hardware ancien. Le mot peut aussi être utilisé pour désigner une fonction d'entreprise; par exemple un vendeur de matériel ou de logiciel qui prend en charge, ou fournit de la maintenance logicielle, pour des produits plus anciens.

Un produit "legacy" peut être un produit qui n'est plus vendu, qui a perdu des parts de marché substantielles, ou est une version d'un produit qui n'est pas courant. Un produit legacy peut avoir certains avantages les rendant plus attrayants aux consommateurs que les produits modernes. Un produit n'est véritablement "obsolète" si aucune décision rationnelle ne permet à personne de choisir de l’acquérir comme produit neuf (en:pareto efficiency").

Le terme mode legacy désigne souvent spécifiquement la rétrocompatibilité. Un produit logiciel qui est capable de performer comme une version précédente de lui-même est dit fonctionner en mode legacy (running in legacy mode). Ce type de fonctionnalité est commune dans les systèmes d'exploitation et les navigateurs internet, où de nombreuses applications dépendent de ces composants sous-jacents.

L'époque du mainframe a vu de nombreuses applications fonctionner en mode legacy. Dans les systèmes informatiques modernes, les architectures n-tier, ou 3-tier sont plus difficiles à exploiter en mode legacy car le système se compose de plusieurs composants.

La technologie de virtualisation du matériel informatique est une récente novation permettant à des systèmes anciens de continuer à fonctionner sur un matériel moderne en exécutant des navigateurs et systèmes d'exploitation antérieurs sur un système logiciel qui émule le matériel antérieur.

Perspectives sur le code logiciel hérité

modifier

Dans l' ingénierie logicielle, certains utilisent l'expression "code legacy" ("legacy code") sans connotation d'obsolescence. Parmi les plus prévalents des concepts neutres sont le code source hérité de quelqu'un d'autre et code source hérité d'une version précédente d'un logiciel. Eli Lopian, CEO de Typemock, l'a défini comme le code que les développeurs rechignent à changer par appréhension (des régressions)[6]. Michael Feathers[7] introduit une définition du code legacy comme du code sans test, qui reflète la perspective d'un code hérité difficile à travailler en partie en raison d'un manque de tests de non-régression automatisé. Il définit également des tests de caractérisation pour créer des premiers tests de code hérité.

Ginny Hendry considère la création de code comme un challenge des développeurs actuels pour créer du code qui comme d'autres héritages de notre vie, comme les antiquités, les objets de famille et les histoires, qui sont chéries et transmises amoureusement d'une génération à la suivante. Pourquoi ne pourrions-nous pas être fier du code hérité?[8].

Références

modifier
  1. a b et c « système hérité », Grand Dictionnaire terminologique, Office québécois de la langue française (consulté le ).
  2. William J. Broad, « NASA checks EBay for obsolete parts », New York Times,
  3. « How the width of the SRBs relates to horse's bums »
  4. « Virtualization : Dealing with Legacy Apps », sur Microsoft.com (consulté le ).
  5. John McCormick, « Mainframe-web middleware », sur Gcn.com, (consulté le )
  6. Eli Lopian, « Defining Legacy Code », (consulté le )
  7. Michael Feathers' Working Effectively with Legacy Code (ISBN 0-13-117705-2)
  8. Ginny Hendry, « Take Pride in Your Legacy (Code) », (consulté le )

Article connexe

modifier

Lien externe

modifier
  NODES
Intern 2
mac 2
os 11
server 2
web 3