IT

Comment assurer la survie d’un projet logiciel après sa mise en production ?

Découvrez comment prolonger le cycle de vie des projets logiciels industriels grâce à la documentation, aux builds reproductibles et aux stratégies open source.

Dans le cadre de projets industriels dont le rythme de maintenance diverge de celui d’autres types de projets (ex : SaaS), on a tendance à focaliser son attention sur le début : la conception, les sprints, la mise en production, les retours utilisateurs, etc. sans prêter dès le départ attention à la fin du cycle de vie. Pourtant, c'est une période qui peut se révéler problématique.

Qu'est-ce qu'un cycle de vie dans un projet logiciel ?

Un cycle de vie logiciel décrit l’ensemble des phases successives qu’un projet traverse, depuis son idée initiale jusqu’à sa maturité et son évolution dans le temps. On retrouve généralement :

1. L’expression des besoins et l’analyse (audit, cahier des charges, compréhension du contexte industriel ou métier),
2. La conception (choix d’architecture, modèles de données, technologies, contraintes système),
3. Le développement (implémentation du code et intégration des modules),
4. Les tests et la validation (unitaires, intégration, système, performance),
5. La mise en production (déploiement, livraison à l’utilisateur final),
6. L’exploitation et la maintenance (corrective, adaptative, perfective, préventive),
7. L’évolution à long terme (refactoring, migration technologique, documentation vivante, transmission du savoir).

Selon les méthodes (cascade, agile, itérative, DevOps), ces étapes peuvent s’enchaîner de manière séquentielle ou se répéter en cycles courts. Mais dans tous les cas, un logiciel n’est jamais figé : c’est un système vivant qui évolue avec son environnement technique, ses utilisateurs, ses dépendances et ses contraintes industrielles.

Un “cycle de vie” ne s’arrête pas à la livraison

La plupart des schémas de cycle de vie logiciel, qu’ils soient en cascade, en spirale ou itératifs, s’arrêtent à la mise en production, voire à la maintenance immédiate post-livraison. Mais ce sont des schémas conçus pour gérer des projets, pas des produits vivants. Dans la réalité industrielle, le cycle de vie d’un logiciel se poursuit bien après la phase projet : il s’inscrit dans la durée, dans l’usure, dans les changements d’équipes, dans les contraintes liées aux systèmes d'exploitation qui évoluent, dans les librairies qui ne sont plus maintenues, dans les matériels qui changent.

Cette phase post-projet, souvent mal nommée "maintenance", est en réalité un cycle en soi, non-linéaire et souvent non planifiée mais stratégique.Si elle n’est pas pensée dès le départ, elle peut devenir une zone grise où le risque augmente lentement mais sûrement. Et c’est précisément là que réside l’enjeu : penser ce cycle de vie dans son intégralité, y compris au-delà de la livraison initiale, dans une logique de continuité à long terme. Car la recherche confirme que la maintenance et l’évolution représentent jusqu’à 80–90 % des coûts du cycle de vie et conditionnent la survie d’un logiciel face à l’« usure logicielle » ou "software aging". Des études montrent aussi que la maintenabilité (architecture stable, documentation claire, processus de build reproductibles) est la clé pour réduire les coûts, améliorer la qualité et assurer la durabilité sur des décennies.

Un logiciel peut continuer à vivre sans personne pour le maintenir

Ce constat n'est pas une situation rare : un logiciel industriel est mis en production, fonctionne. Les années passent, l'équipe à l'initiative de sa conception n'est plus présente et la nouvelle équipe ne dispose que d'une documentation lacunaire (qui requiert elle-même parfois une certaine connaissance du projet pour être comprise).

Le projet n’a plus de référent identifié. Personne n’est vraiment capable de dire comment faire évoluer ou modifier le code logiciel sans casser les fonctionnalités existantes (parfois nécessitant des ressources très coûteuses à mobiliser, comme des machines en production). Des entreprises se retrouvent alors avec un outil en production, stable mais critique, sans aucune personne disposant du savoir et savoir-faire pour redéployer l'application, corriger un bug ou déployer les nouvelles bonnes versions des bibliothèques.

Sans préservation du savoir et du savoir-faire, des risques éminents

L'absence de préservation de savoir et de savoir-faire est un vrai facteur de risque à moyen et long terme.

Les builds deviennent difficiles à reproduire

Une des causes majeures de cette perte de contrôle, c’est la non-reproductibilité des builds. Aujourd’hui, beaucoup de logiciels dépendent d’un écosystème de librairies, de paquets, de gestionnaires de dépendances, de versions précises et de ressources disponibles sur internet.

Sources : ISO/IEC 14764 (Software Maintenance), ISO/IEC 29119 (Software Testing), Reproducible Builds Initiative, CISA Secure Software Development Framework (SSDF).

Les dépendances risquent de ne plus être connues

On s'expose à une perte des versions exactes et une non-maintenance des scripts de compilation (s’ils existent). Node, Python, CMake, Gradle, Maven, Conan… Peu importe l’outillage : si les versions sont perdues, si le dépôt de paquets a disparu ou si la build dépendait de ressources en ligne aujourd’hui indisponibles, on se retrouve face à un logiciel difficile à maintenir. Il devient difficile de corriger un bug ou de livrer une évolution de manière fiable.

Les tests d’intégration nécessaires difficilement réalisables (car non documentés et absence de matériel nécessaire)

C’est l’autre face du problème : les tests. Les scénarios de test ne sont pas décrits, le matériel nécessaire (caméras, sondes, API, etc.) n’est plus disponible, le banc de test est hors service, les données sont corrompues ou perdues. Les tests d’intégration ne peuvent pas être relancés. Ni le scénario, ni les données, ni le matériel requis ne sont documentés. On se retrouve avec un banc de tests inutilisable. Les tests unitaires deviennent absents ou obsolètes.

Résultat : un projet presque figé

Dans des environnements à support long terme (projets industriels, systèmes embarqués, applicatifs techniques, etc.), une situation de blocage risque de se mettre en place :

➡️ Difficile de builder votre logiciel. ➡️ Difficile de livrer des correctifs. ➡️ Difficile même d'installer le logiciel sur une nouvelle machine.

La dette technique risque de s’installer et se fossiliser. Sans référent pour porter la vision technique ni documentation pour expliquer les choix, la compréhension globale du projet peut alors s’effacer.

Sources : ISO/IEC/IEEE 12207 (Software Life Cycle Processes), ISO/IEC/IEEE 14764 (Software Maintenance), IEEE Software Aging studies.

Comment gérer le cycle de vie d'un projet logiciel pour éviter la dette technique ?

Plusieurs comportements permettent de réduire ces risques :

1. Documenter sérieusement. Une documentation construite avec minutie, placée au bon endroit, facilement accessible, justifiant les choix de l’architecture, les points de dépendance les cas d'usage cibles, des contraintes connues du développement, etc.

2. Essayer de rendre répétable Autant que raisonnablement possible en temps et en argent, en priant pour qu'un facteur externe auquel on n'avait pas pensé vienne tout bousiller. Cela afin de pouvoir builder offline, sans requêtes HTTP vers des serveurs externes, figer les versions de dépendances et d'intégrer le build dans une CI/CD robuste pour être en capacité de le relancer à l’identique, sans dépendre d’URLs externes volatiles.

3. Penser l’après dès la livraison Même si le projet est “terminé”. Surtout s’il est industriel. Car le besoin de maintenance, parfois dix ans plus tard, arrivera. Cela implique de rédiger une documentation de long terme (pas juste pour le sprint), de désigner un “gardien du projet” même après livraison et d'anticiper la portabilité future (OS, plateformes, matériels).

Et pour les projets web ?

Les projets web sont souvent plus vivants, avec un cycle de mise à jour régulier, un hébergement évolutif, des équipes DevOps en veille constante. Mais même les projets web ne sont pas protégés : mises à jour fréquentes, hébergement cloud, équipes DevOps tournantes... Ils peuvent mal vieillir : projets figés avec une stack technique obsolète, avec des dépendances périmées, sans CI ni de compétences internes pour faire les déploiements. Et là aussi, les mêmes réflexes doivent s’appliquer.

Envisager une solution radicale mais vertueuse : le passage en open-source

Quand un projet logiciel arrive en fin de vie, que l’on ne souhaite ou l'on ne peut plus l’entretenir en interne, il existe une alternative responsable et durable : le passage en open source.

Cela consiste à :

• Publier le code source sous licence libre,
• Rendre accessibles la documentation, les scripts de build, les dépendances, etc. pour permettre à une communauté de prendre le relais pour corriger, sécuriser, améliorer le projet.

En fait, à nos yeux, c’est une démarche de transmission, presque éthique : laisser vivre le projet, même si l’entreprise se retire.

Le parallèle avec l’industrie du jeu vidéo : l’initiative Stop Killing Games

Ce sujet fait écho à une actualité très vive : celle des jeux vidéo rendus inaccessibles car les éditeurs ne les jugent plus “rentables”. La campagne Stop Killing Games s’inscrit dans ce contexte : des jeux que les joueurs ont légalement achetés deviennent inaccessibles car les serveurs sont coupés ou le logiciel n’est plus compatible avec les OS récents. Les éditeurs refusent de patcher ou de libérer le code, ce qui entraîne une perte patrimoniale numérique irréversible. Mais si ces jeux sont alors publiés en open source, des passionnés pourraient assurer leur compatibilité, maintenir les serveurs, les adapter aux plateformes modernes.

Le raisonnement est le même pour les logiciels industriels, les outils métiers ou les projets internes. Un projet logiciel est rarement “fini” quand il est livré et faire appel à une communauté en ligne en migrant le projet en open-source peut être salutaire.

Conclusion : Un logiciel bien conçu vit longtemps et plus encore grâce à l'open-source

Un projet logiciel ne se termine pas à la livraison. Il entre simplement dans une nouvelle phase : celle de la maintenance, de la transmission, du changement et parfois de la réinvention. L’ignorer, c’est risquer qu’il se dégrade, devienne inutilisable, avec le risque qu'il se transforme en futur cauchemar. D'où l'importance de le préparer à survivre, en le développant tel un logiciel durable, éthique, accessible, au-delà de la durée de vie d’un projet ou d’un budget.

Et pourquoi pas lui donner une seconde vie grâce à l’open source, pour qu’il continue d’évoluer, même sans nous. Car ce qui n’est plus rentable pour une entreprise peut être essentiel pour des collaborateurs, des utilisateurs, des chercheurs de des communautés.