L’un des plus graves problèmes du legacy, en particulier quand il est ancien, concerne la compétence. Si ce patrimoine a été codé avec un langage propriétaire et “mort” depuis des années, la compétence sur le code disparaît de l’entreprise. Pour éviter cela, il est vital de constituer une base de connaissances et d’entretenir la compétence en interne. Le Cobol est un exemple parmi d’autres. Aujourd’hui, les nouveaux développeurs formés au langage sont quasi inexistants. Et avec les départs en retraite, ou départ du salarié pour diverses raisons, l’entreprise perd de la compétence Cobol. Le SI ne doit surtout pas laisser partir les compétences en outsourcing, sous peine d’abandonner la maîtrise de son legacy.
Nuançons tout de même cette affirmation. “Certaines écoles introduisent du Cobol (dans les cursus). La demande existe, sur Pacbase, par exemple, elle est assez forte. Mais mettre ces technologies en avant dans une annonce, ce n’est pas ‘vendeur’. Il y a danger pour les entreprises qui n’investissent pas dans la formation, cela fait le jeu de l’externalisation. Nous avons, chez Microfocus, mis en place des partenariats pour des cursus comme à l’IUT de Nantes. Il y a un réel besoin sur le marché, même si cela n’est pas toujours bien compris par les universitaires”, explique Henrik Jacobsen. Une tendance croissante consiste à avoir la double compétence, Objet et legacy.
L’obsolescence des langages et des outils demeure un souci : de nombreux langages sont désormais des langues mortes et quantité d’outils arrivent, ou sont déjà arrivés, en fin de vie. Et le support de l’éditeur (s’il existe toujours !) n’est pas éternel. Le cas de Pacbase est éloquent, d’ici 6 ans, son support chez IBM s’arrêtera.
A chaque fin de cycle de vie d’un outil, d’un progiciel, le DSI doit prendre des décisions. Et à chaque nouvelle version, se poser des questions sur le support, sa durée et l’intérêt de garder une plate-forme en fin de vie.
