Ma collègue Mathilde a eu la bonne idée de rédiger une série d’articles (la série est par ailleurs toujours en cours sur notre chaine Netflix) sur le concept de dette technique (Dette technique ou pas dette technique ? Telle n’est pas la question (1/5) ; Interprétations de la métaphore de la dette technique (2/5) ; Apparition et emballement de la dette technique (3/5) ; Pourquoi gérer la dette technique ? Pour ne pas la subir… (4/5) ) Il se trouve que j’ai, encore récemment, été confronté chez des clients à des difficultés à suivre les montées de version de la roadmap d’un éditeur de logiciel, alors même que cette roadmap est plutôt intéressante et performante tant sur la réduction de la dette technique que sur les nouvelles fonctionnalités métiers.
Le standard, rien que le standard
standards
J’ai toujours milité sur mes projets pour la plus stricte limitation des développements spécifiques autour de solutions progicielles du marché. Je sais de quoi je parle puisque mes racines bretonnes m’ont déjà permis de réussir des projets où j’ai patiemment et résolument éliminé tout développement spécifique pour couvrir 100% des besoins avec 100% de standard. Dans les cas où ça n’a vraiment pas été possible, j’ai également tout aussi fortement milité pour que ces fonctions spécifiques soient réalisées en respectant les préconisations des architectes (cf nos articles précédents sur le sujet : Des silos bien étanches, des API de merde ; 5 principes d’architecture pour un SI moderne ; Le bon architecte informatique ).
Ayant eu à travailler avec de petits éditeurs ou des startups j’ai aussi toujours œuvré pour l’intégration dans leur roadmap produit, de fonctionnalités intéressantes pour mes clients et qui me paraissaient également porteuses d’intérêt pour le marché. Généralement tant qu’ils ont des clients qui financent et que l’on peut montrer la cohérence avec la roadmap, « ça passe crème », comme disent les jeunes.
L’intérêt de rester dans le standard du produit ou de découpler correctement un progiciel des autres briques du patrimoine SI de l’entreprise est de permettre de suivre les montées de version proposées par la roadmap de l’éditeur et les évolutions ultérieures du produit sans engager de coûts importants.
Cela est fondamental car vous pourrez bénéficier des bonnes idées des autres entreprises et de l’amélioration technique du produit (diminution de la dette technique)
Oui mais c’est pas toujours automatique… loin de là
Avec les solutions SaaS publiques, vous n’avez même plus le choix, l’éditeur vous impose des mises à jour et à vous de les digérer. Lorsque des risques de régression existent vous êtes prévenus 3 mois avant (allez 6 mois si c’est vraiment impactant) et « demerden sie sich » ! C’est assez violent mais il faut le dire… redoutablement efficace.
Lorsqu’on parle de progiciels métiers, le cloud public n’est pas encore le mode le plus répandu d’hébergement et d’exploitation de la solution, on est plutôt sur des cloud privés voire du on-premise pour les entreprises les plus conservatrices.
Et là nos clients sont souvent confrontés à de grandes difficultés dans le suivi des montées de version de leurs logiciels.
Première difficulté de la montée de version : le syndrome du « on ne change pas une équipe qui gagne »
On ne change pas une équipe qui gagne
Il serait plus approprié de dire que malheureusement c’est dans 80% des cas le syndrome du « on ne change pas une équipe qui n’est pas encore éliminée ».
- Réserver du temps à l’étude de la roadmap des éditeurs et évaluer l’apport métier des nouvelles fonctionnalités pour convaincre les décideurs métiers de faire ces investissements généralement modiques.
- Valider les paramètres d’une fonction d’obsolescence, éventuellement SI par SI, qui calcule le coût futur du Maintien en Conditions Opérationnelles et des futures montées de version. Grosso modo : on peut faire des économies en sautant une ou deux versions, mais jamais plus. Au delà, la montée de version va coûter très cher et en tout cas beaucoup plus cher que si l’on avait fait les mises à jour plus régulièrement (pour des raisons notamment de compétences et de disponibilité des sachants sur ces anciennes versions)
Seconde difficulté : Croire votre DSI quand il vous dit que la montée de version 100% automatisée est suffisante et/ou donne toujours un bon résultat
Confiance, Believe, Croyance
Bien sûr que la montée de version doit être automatisée au maximum sur le plan technique. Ces scripts de migration techniques sont faits par les éditeurs et rendent le process automatique. Vous en connaissez certains, notamment ceux qui se lancent automatiquement sur vos PC pour mettre à jour Windows, ou pour mette à jour votre navigateur internet préféré. Lorsque ces scripts sont faits par des acteurs mondiaux généralement ça se passe plutôt bien. Lorsqu’ils sont faits par des petits éditeurs c’est déjà beaucoup plus rudimentaire.
Mais surtout ces migrations techniques doivent s’accompagner d’évolutions de paramétrage métier pour permette de profiter des nouvelles fonctionnalités. Souvent ces modifications ne sont pas automatiques.
Bref, même ces petits projets de montée de version nécessitent, en complément des automatismes de migration, de la réflexion en amont et en aval, éventuellement même un peu de conduite du changement. Cela est généralement peu couteux, mais jamais nul, et par contre parfois absolument nécessaire pour tirer parti des évolutions du produit. En tout cas il faut se méfier du 100% automatique vers quoi a tendance à vouloir vous ramener votre DSI dans le seul but de limiter au maximum les changements.
A noter que ces évolutions peuvent concerner également les API et c’est encore plus fondamental pour limiter la dette technique. Par exemple : chez un de mes clients, l’éditeur a, il y a quelques années converti toutes ses API SOAP XML vers des API REST JSON. Le changement de version devait nécessairement s’accompagner chez les clients d’un projet significatif de mise à jour des architectures. Mais cela a eu un retour sur investissement très rapide.
