Les produits qui arrivent aujourd’hui sur le marché sont rarement purement mécaniques. Voitures, machines industrielles, dispositifs médicaux — le logiciel est partout. C’est plutôt une bonne nouvelle. Le logiciel peut être mis à jour, des bugs corrigés, des fonctions ajoutées, sans que le client doive rapporter physiquement l’appareil.
Mais cette promesse tient-elle vraiment dans la pratique ? Quiconque a déjà eu entre les mains un appareil plus ancien qui ne reçoit plus de mises à jour connaît la réponse : pas tout seul.
Les mises à jour logicielles sur le long terme ne sont pas une loi naturelle de la technique. Elles sont le résultat de décisions conscientes — dans l’architecture produit, dans le modèle économique et dans les processus qui gèrent les exigences et les tests sur tout le cycle de vie.
C’est exactement le sujet de ma conférence « Leveraging Long Term Software Update Strategies » à la SIEMENS Realize LIVE 2024 à Las Vegas (vous trouverez le compte-rendu de la conférence ici). Le thème central du salon était la durabilité — et l’argument derrière est en fait simple : un produit est vraiment durable quand il a une longue durée de vie. Et il vit longtemps s’il peut aussi recevoir des mises à jour logicielles sur le long terme.
Trois éléments doivent s’articuler pour cela.
1. Le modèle économique doit permettre les mises à jour
Cela paraît évident — ça ne l’est pourtant pas. Historiquement, de nombreuses entreprises ont gagné leur argent avec le matériel. Le support était un à-côté qui devait coûter le moins possible. Dans cette logique, des mises à jour logicielles gratuites à vie représentent un poste de coût sans retour.
La question est donc : qui va payer pour cela ? Si la réponse est « personne », alors personne ne veillera non plus à ce que les mises à jour soient de qualité — ou même qu’elles arrivent.
Cela peut être un contrat de service, un modèle d’abonnement, des niveaux de support échelonnés. Le modèle en lui-même n’a qu’une importance secondaire. Ce qui compte, c’est que fournir de bonnes mises à jour logicielles soit économiquement viable. Sinon, la durabilité reste un discours.
2. L’architecture produit doit le permettre
Le deuxième problème est technique : de nombreux produits ont évolué de telle manière qu’une mise à jour logicielle pour une génération de produit donnée équivaudrait à un développement complet. Qui a étroitement lié mécanique, électronique et logiciel — parce qu’à l’époque, il fallait aller vite — se retrouve en difficulté quand il s’agit, cinq ans plus tard, de mettre à jour un composant logiciel.
La modularisation et la standardisation sont ici les maîtres mots. Quand les composants logiciels disposent d’interfaces clairement définies et que le plus grand nombre possible de générations de produits partagent la même base logicielle, une mise à jour devient planifiable et économiquement sensée.
C’est plus facile à dire qu’à faire. Mais c’est une décision qu’on peut prendre consciemment — et plus elle est prise tôt, moins elle coûte.
3. L’ALM crée la transparence nécessaire
Supposons que le modèle économique soit bon et que l’architecture soit modulaire. Vient alors le troisième défi : comment garder une vue d’ensemble sur les exigences qui sont intégrées dans quel composant logiciel ? Quels tests existent pour cela ? Quelles dépendances entre composants pourraient bloquer une mise à jour ?
C’est exactement là que les outils ALM entrent en jeu. L’Application Lifecycle Management — avec des outils comme Polarion, Codebeamer ou Jira — crée un lien continu entre exigences, développement, tests et livraison. Dans l’idéal, le système sait :
- Quelle exigence a déclenché quelle fonctionnalité ?
- Quels tests vérifient cette fonctionnalité ?
- Quels autres composants en dépendent ?
Cette transparence est la condition d’un haut niveau d’automatisation. Quand l’impact d’une mise à jour prévue est visible en un clic, les cycles de développement peuvent être considérablement raccourcis — et le risque de casser quelque chose diminue.
- Le modèle économique doit prévoir les mises à jour logicielles comme source de revenus — sans base économique, les mises à jour ne sont pas livrées de manière durable
- L’architecture produit a besoin de modularisation et d’interfaces claires, afin que le plus grand nombre possible de générations de produits puisse bénéficier des mêmes mises à jour
- Les outils ALM, bien utilisés, créent la transparence sur les exigences, les tests et les dépendances — la base de l’automatisation et de mises à jour sécurisées
Voir la conférence
Pour voir l’ensemble sous forme de conférence : la vidéo est disponible sur YouTube.
Une remarque sur le sujet de la durabilité et des vols vers Las Vegas : la question est légitime. Je ne veux pas m’accorder une absolution avec ça — mais j’ai compensé de ma poche les émissions de CO2 de mon vol auprès d’un prestataire certifié.
