Notre plateforme ASSIA est un service délivré en mode SaaS. Le cycle de version est unique pour l’ensemble de nos clients et chacun d’eux le suit. Autrement dit : il n’y a qu’une seule version d’ASSIA plateforme santé et assurance en production qui porte tous nos clients. Il s’agit bien de SaaS et pas d’un hébergement dédié par client. Explications
Le mode de distribution de notre solution ASSIA plateforme santé et assurance nous conduit à être extrêmement rigoureux dans la délivrance des versions, car chaque évolution concerne potentiellement tous nos clients. Si la promesse est facile à énoncer, elle n’est pas si facile à tenir. En effet, la version de notre plateforme ASSIA est unique en production, mais les clients qui l’utilisent ne le sont pas. Chacun d’entre eux se développe selon sa propre stratégie ce qui se traduit par des différences de paramétrage dans ASSIA (entre autres choses, bien entendu). Nous avons donc une version en production, mais autant de paramétrages que de clients. Notre enjeu est de garantir que chaque version fonctionne pour tous les contextes avant de les porter en production.
Très tôt, nous avons donc dû automatiser et industrialiser nos processus de recette. En premier lieu, nous avons créé des outils pour faciliter la gestion de version, leur déploiement sur les environnements dédiés au cycle de version. Depuis 10 ans, nous avons une équipe DevOps en charge de ces points. Nous avons également fait en sorte de donner de l’autonomie aux équipes pour accélérer les cycles de développement. Ainsi, un développeur peut livrer ses éléments sur un environnement de tests unitaire, au moment qui lui semble opportun, de façon automatisée au-travers d’une application. Il ne le pourra plus sur les phases de recette intégrée où notre équipe dédiée reprend la main afin de garantir le niveau de version et la qualité de la recette.
Prise en compte du contexte client
Mais cela ne suffit pas pour résoudre la problématique de prise en compte du contexte client. Nous avons donc mis au point un outillage spécifique. À chaque version, nous injectons automatiquement un jeu de tests sur deux environnements : un environnement à l’image de la production, un environnement en version cible, chacun sur un même jeu de données. Dans le même procédé, nous jouons les traitements consommant le jeu de tests, nous produisons (toujours automatiquement) les résultats d’exécution (vue des données en base, bordereaux, fichiers de sortie) et nous éditons un rapport comparant les résultats sur chacun des environnements et présentant les écarts entre environnement. Ce document est transmis automatiquement aux acteurs de la recette. En cas d’écart, le responsable du livrable doit le justifier : l’écart peut être normal, car lié à l’évolution ou signaler une régression. La justification est obligatoire pour l’acceptation du livrable en production. Pour plus de transparence, les environnements, les résultats sont accessibles au client. Les jeux de tests peuvent également être enrichis à leur demande.
Ce jeu de test est joué sur le paramétrage des clients. Ainsi, par la complétude du jeu de tests et de paramétrages, par l’automatisation de la recette permettant une réalisation dans des délais très courts, nous balayons un très large panel de nos fonctionnalités et nos équipes de recette peuvent se concentrer sur les évolutions plutôt que sur la non-régression.
Pour reprendre les termes de Boris Janvier, responsable de la cellule DevOps chez ASSIA , (ancien CIMUT), dans une récente interview publiée dans la rubrique actualités de notre site : « La force de notre approche réside dans notre capacité à travailler depuis de nombreuses années sur de la donnée réelle et massive et ceci de manière automatisée ». Comme il le souligne très justement, c’est un process qui n’est pas si courant dans le monde de l’édition logicielle et particulièrement dans le métier de l’assurance de personnes.
Pour (re) découvrir l’interview de Boris JANVIER : bit.ly/31xbnpm