ALM, PLM, SE, MBSE, Digital Thread — quiconque s’occupe de développement produit avance dans un maquis de sigles. Le plus perfide : la plupart de ces termes sont tout à fait légitimes dans leur contexte respectif. Mais pour qui ne connaît pas les liens entre eux, ce qui se rapporte à quoi et comment, tout cela devient vite déroutant. Du pur bullshit bingo.
ALM en est l’exemple parfait : Application Lifecycle Management. Tantôt il s’agit d’une approche de gestion, tantôt d’un outil, tantôt de quelque chose de tout autre. Il est temps d’y voir plus clair.
ALM en tant qu’approche de gestion
D’un côté, ALM désigne une approche de gestion globale : il s’agit d’accompagner tout le cycle de vie d’une application ou d’un logiciel : de la première idée au développement et à l’exploitation, jusqu’à la maintenance et à la « fin de vie » (end of life). Dans l’idéal, toutes les disciplines et parties prenantes y sont associées : développement, test, exploitation, gestion de la qualité, product owner, etc.
ALM constitue alors le cadre de gestion global, sous lequel les processus sont clairement définis, les transmissions fluides et les informations transparentes.
ALM en tant que catégorie d’outils
Dans la pratique, ALM est pourtant utilisé au moins aussi souvent comme synonyme d’une certaine catégorie d’outils logiciels. Des noms comme Polarion, Codebeamer, Jira, Azure DevOps ou IBM Engineering Lifecycle Management sont depuis longtemps des valeurs sûres dans de nombreuses entreprises. Ces outils proposent généralement toute une palette de fonctions :
-
Gestion des exigences
-
Gestion des tests
-
Suivi des tâches et des bugs
-
Gestion des modifications et de la configuration
-
Traçabilité (Traceability)
-
Reporting et automatisation
L’objectif : regrouper autant que possible les étapes du processus de développement sur une seule plateforme, pour éviter les ressaisies manuelles entre systèmes et faciliter la collaboration. Souvent avec des interfaces vers des gestionnaires de sources comme Git ou équivalents.
Au passage, un marché en mouvement : Polarion appartient désormais à Siemens, Codebeamer à PTC. Les grands éditeurs de PLM ont délibérément intégré des outils ALM à leur portefeuille. On voit déjà que les frontières entre ces catégories sont tout sauf figées. On y revient plus loin.
ALM au-delà du développement logiciel
Beaucoup de ces « outils ALM » ne sont plus utilisés depuis longtemps uniquement pour des projets logiciels. Certaines entreprises s’en servent comme plateforme centrale pour le Systems Engineering, c’est-à-dire la gestion de produits complexes dans lesquels le logiciel n’est qu’un composant parmi d’autres.
Il m’est aussi arrivé de voir ALM utilisé simplement comme synonyme d’outils de gestion des exigences. Ce n’est pas totalement faux : la gestion des exigences est bien l’un des points forts des outils ALM courants. Mais ils représentent bien plus que cela. Réduire ALM à la gestion des exigences, c’est laisser de côté une grande partie de son potentiel.
Dans les secteurs réglementés comme l’automobile, les technologies médicales ou l’aéronautique, on observe un autre schéma : les outils ALM y sont souvent utilisés avant tout pour leurs capacités de documentation et de preuve (mot-clé : traceability), et pas seulement pour leurs fonctions classiques de développement logiciel.
ALM, PLM et Systems Engineering : qui se situe où ?
Combien de fois avons-nous « débattu » en interne pour savoir si ALM se situe à côté de PLM ou en fait partie : j’ai arrêté de compter. La réponse est à la fois décevante et rassurante : les deux sont vraies. Tout dépend de l’angle sous lequel on regarde.
Pour les produits purement logiciels, ALM est l’équivalent du PLM (Product Lifecycle Management) : il couvre toutes les tâches de gestion du cycle de vie, mais appliquées au logiciel. ALM se situe alors à côté de PLM.
Pour les produits mécatroniques (produits physiques comportant une part logicielle), ALM est en revanche typiquement un sous-domaine au sein du PLM, plus large : le PLM pilote le produit dans son ensemble, de l’idée à la fabrication jusqu’à la mise hors service, tandis qu’ALM s’occupe des composants logiciels. Si tant est que l’on veuille vraiment faire cette distinction, car dans l’idéal les deux mondes sont étroitement imbriqués, tant techniquement qu’organisationnellement. Par exemple via des interfaces et une traçabilité de bout en bout, pour que les exigences, les modifications et les preuves restent cohérentes entre toutes les disciplines.
PLM et ALM décrivent le ‘Quoi’, Systems Engineering le ‘Comment’ et les outils sont le ‘Avec quoi’
Et comment Systems Engineering s’intègre-t-il dans ce tableau ? Là aussi, la distinction du début aide :
Si l’on considère ALM comme une catégorie d’outils, les choses sont claires : l’outil ALM est un instrument, Systems Engineering la boîte à outils méthodologique. Dans la pratique, les outils ALM sont donc volontiers utilisés comme plateforme pour le Systems Engineering : ils soutiennent exactement ce que la SE exige méthodologiquement : la collaboration entre disciplines et une traçabilité continue de l’exigence jusqu’au test.
Si l’on considère en revanche ALM comme une approche de gestion, cela se complique. ALM (tout comme PLM) devient alors plutôt un terme générique abstrait pour le Quoi : quel cycle de vie, quels artefacts, quelles responsabilités sont gérés. Systems Engineering décrit le Comment : avec quelles méthodes on développe. Mais seulement pour une partie de ce qui relève d’ALM — le bugtracking, le DevOps et le support, par exemple, ne sont classiquement pas le terrain de la SE.
Si l’on veut résumer cela en une formule : PLM et ALM décrivent le Quoi, Systems Engineering le Comment, et les outils sont le Avec quoi. Comme toute formule, elle simplifie, mais elle fait très bien l’affaire comme boussole dans ce maquis de termes.
Conclusion : ALM est ce qu’on en fait
Qui parle d’ALM devrait donc toujours marquer une pause et clarifier ce qui est précisément visé :
-
S’agit-il de l’approche de gestion globale ?
-
Des méthodes de développement logiciel ?
-
D’un outil précis ou d’une catégorie d’outils ?
-
D’un cas d’usage bien spécifique, comme le Requirements Engineering, ou du soutien à d’autres capacités de Systems Engineering ?
-
Ou du rôle d’ALM en interaction avec PLM pour le produit dans son ensemble ?
La réponse est le plus souvent : « ça dépend ». Et c’est tout à fait normal, pour autant que toutes les parties prenantes partagent la même compréhension. Le bullshit bingo du début ne vient pas du fait que les termes seraient faux, mais du fait qu’ils sont utilisés sans contexte.
Encore une chose : ALM n’est pas un projet qu’on mène une fois puis qu’on coche. C’est un domaine qui évolue avec les produits, les méthodes de développement et les exigences réglementaires. C’est ce qui le rend exigeant et durablement pertinent.
ALM est polysémique — et c’est normal. L’important, c’est que toutes les parties prenantes entendent la même chose. Et que les outils, processus et méthodes choisis correspondent aux besoins réels, et non à une image générique d’ALM tirée d’un manuel.
Vous préparez une initiative ALM ou êtes en plein dans l’un de ces sujets ? N’hésitez pas à me contacter — j’accompagne chez BHC et PROSTEP des entreprises sur la stratégie, le choix des outils et la mise en œuvre. De manière neutre vis-à-vis des éditeurs et ancrée dans la pratique.
Questions fréquentes
Que signifie ALM (Application Lifecycle Management) ?
ALM signifie Application Lifecycle Management et est utilisé en pratique de deux façons : d’une part comme approche de gestion globale qui accompagne un logiciel de la première idée au développement et à l’exploitation jusqu’à la fin de vie, et d’autre part comme désignation d’une catégorie d’outils comme Polarion, Codebeamer ou Azure DevOps. Le sens visé ne ressort que du contexte.
ALM est-il la même chose que PLM ?
Pas tout à fait, cela dépend du produit. Pour les produits purement logiciels, ALM est l’équivalent de PLM et se situe à égalité à ses côtés. Pour les produits mécatroniques avec une part logicielle, ALM est en revanche généralement un sous-domaine au sein du PLM, plus large, qui pilote alors le produit dans son ensemble, matériel et logiciel compris.
Quels outils comptent parmi les outils ALM classiques ?
Parmi les outils ALM les plus connus figurent Polarion (Siemens), Codebeamer (PTC), Jira, Azure DevOps et IBM Engineering Lifecycle Management. Ils couvrent typiquement, au sein d’une même plateforme, la gestion des exigences, la gestion des tests, le suivi des tâches et des bugs, la gestion des modifications et de la configuration, ainsi que la traçabilité et le reporting.
Quel est le lien entre ALM et Systems Engineering ?
Systems Engineering est la boîte à outils méthodologique, et les outils ALM en sont souvent la plateforme. Si l’on considère ALM comme une catégorie d’outils, les outils ALM soutiennent exactement ce que la SE exige méthodologiquement : la collaboration entre disciplines et une traçabilité continue de l’exigence jusqu’au test. Si l’on considère ALM comme une approche de gestion, la SE décrit plutôt le ‘Comment’ pour une partie de ce qu’ALM couvre comme ‘Quoi’.
