En navigant sur le net, il vous est sans doute arrivé de tomber nez à nez avec un lien qui ne pointe plus vers son contenu. Une page d’erreur 404 ou bien même aucune page d’erreur du tout, comme si le site entier s’était lui-même volatilisé. On dit souvent entre nous, « tiens, ce lien est « mort »… ». Un lien à jour est vivant, un lien obsolète est mort. Et si c’était la même chose pour les logiciels ?

Lorsqu’un projet de développement débute, c’est en général l’effervescence ; les chefs de projets sont tout excités à l’idée de découvrir le métier du client et répondre à son besoin, les développeurs-euses sont excité-es à l’idée de « créer » un nouveau logiciel avec de nouvelles technos toutes neuves et ainsi expérimenter de nouveaux paradigmes et architectures (chacun son truc, comme on dit..). La joie de l’ouverture des cadeaux de Nowël, en somme. Le logiciel est alors en phase de gestation.

A la première livraison, c’est l’accouchement. Vous êtes fiers de votre nouveau bébé. Vous y avez mis tout votre cœur, avec du code tout beau tout propre. Vous le mettez au bain à coup de refactoring tous les jours. Les commentaires ont du sens, les nouvelles technos sont « super-sympas », même si vous avez pu à cette occasion y découvrir des inconvénients majeurs. C’est pas grave, on fait avec. Et le clou du spectacle, il y a même des tests unitaires qui garantissent la non régression des fonctionnalités de base.

Puis le projet grandit. Votre bébé est devenu grand. Au départ, vous ne saviez pas trop ce qu’il allait devenir. D’autres développeurs ont rejoint l’équipe et lui ont appris à faire de nouvelles choses. A bien y regarder, il a aussi pris de l’embonpoint. Il ne fait pas encore le café, mais il n’en est pas loin. Les technos (plus toutes jeunes) utilisées sont agréables, mais leurs inconvénients vous font de plus en plus râler. Ce n’est pas grave, il fonctionne toujours bien, il est en production, et les mises à jours et les évolutions sont nombreuses.

Puis les années passent. Le bébé a disparu pour laisser la place à une cathédrale. Non pas que l’architecture était mauvaise, non. Pris dans son contexte, celui des débuts, tout fait sens, mais les besoins ont évolué. Les règles métier se sont étoffées, les usages également. Les utilisateurs, toujours plus nombreux, toujours plus exigeants, ont fait évoluer le logiciel, ce qui n’est pas un mal, car cela prouve que le projet est bel et bien vivant.

Mais les technos utilisées vous semblent bien loin de ce que l’on fait de nos jours ; très très loin. A bien y réfléchir, avec ce qui existe maintenant, nous pourrions imaginer faire mieux. Beaucoup mieux.  Beaucoup plus efficace. A la fois pour les développeurs, mais aussi pour les utilisateurs, qui ressentent bien un décalage entre ce monument, et le monde tel qu’il est aujourd’hui. Et puis il y a toutes ces petites briques faites main, toutes ces petites gargouilles magnifiques qui ornent l’ouvrage, et sur lesquelles vous avez passé tant d’heures avec vos collègues pour le rendre plus beau, plus riche, plus attrayant. Oui. L’air de rien, 15 ans se sont écoulés entre les débuts du projet et ce stade, une éternité dans le domaine de l’informatique. Et vous vous demandez bien comment le faire évoluer pour qu’il ne devienne pas un de ces monuments que l’on admire, mais sans jamais ou rarement y rentrer… comment le garder en vie ? … sans le détruire complètement et construire un gratte ciel à la place ?

Bien sûr, un projet logiciel n’est pas un organisme vivant. Il ne ‘vit’ que par l’activité que lui donnent ses participants, ses utilisateurs, et surtout ses développeurs. A mon sens, il y a deux morts pour un logiciel. La première (pas forcément la 1ère dans le temps), c’est l’équipe de développeurs qui la lui donne. Plus de mises à jour majeures. Plus d’évolution. Parfois, même, plus de maintenance. L’éditeur peut faire ce choix délibérément (cf. Windows XP), ou pas (cf. Open Office suite au rachat du projet par Sun).  L’autre mort, bien plus définitive, est celle qui est donnée par les utilisateurs. Parfois un logiciel est même mort-né, car ce dernier n’est pas encore livré qu’il est délaissé par les gens censés s’en servir (Windows Millenium, si tu nous entends..).

Les solutions à un tel problème sont loin d’être évidentes, mais il existe plusieurs pistes :

• dans le cadre d’une licence propriétaire, cadrer dès le départ du projet les conditions de « fin de cycle » et anticiper un renouvellement des développements à long terme. Ce dernier peut prendre plusieurs formes, comme par exemple une réécriture par partie, si tant est que ce soit techniquement possible de séparer des morceaux de l’ouvrage pour le faire évoluer au moins partiellement. Il s’agit dans ces cas là d’un investissement sur le long terme, mais comme chacun sait, personne n’est prophète en son pays …
• dans le cadre d’une licence libre, c’est un peu plus ouvert (par définition ;)) ), sans toutefois apporter de solution évidente au problème. La continuité de l’activité au sein du projet peut émaner d’autres sources comme des bénévoles, d’autres entités professionnelles, qui peuvent repartir de la base existante pour faire ressusciter le logiciel. Le cas d’Open Office est très intéressant ; le rachat du projet par Sun a provoqué le départ d’une grande partie des contributeurs d’Open Office qui n’ont pas voulu continuer de faire vivre le projet « dans de telles conditions ». Ce dernier a donc été « fourché » (fork) pour renaître sous la forme de LibreOffice. OpenOffice est donc mort dans la bataille, mais LibreOffice a continué d’avancer et d’évoluer.

Bref, n’est pas immortel qui veut. Dans tous les cas, un gros projet, qu’il soit logiciel ou pas, amène avec lui son histoire. Bien qu’il soit toujours tentant de la réécrire et d’y porter un jugement facile, il convient toujours de ne pas l’oublier et d’en tirer les leçons, et ainsi éviter que certaines erreurs du passé ne se répètent…