Pourquoi changer la production de logiciels et les modèles économiques

Le PNRR met en lumière toutes les limites d’un marché en « cycle fermé » où les entreprises produisent elles-mêmes les logiciels et services nécessaires, notamment avec des logiques inefficaces (logiciels à faire soi-même).

Le marché de la santé numérique se caractérise par deux aspects fondamentaux : le modèle économique et le modèle de production de logiciels. La première voit, à quelques exceptions près, une approche de «cycle fermé» où la personne qui crée le logiciel est la seule à pouvoir fournir les services professionnels. C’est une logique”captif» dans lequel le fournisseur crée un fort verrouillage avec le client qui, de cette manière, en est totalement dépendant. La complexité des logiciels d’aujourd’hui, ainsi que l’absence voire l’absence totale de documentation, rendent cette pratique très résistante à toute tentative de limiter ses effets par le transfert du code source ou de la licence d’utilisation. Cependant, cette approche a également des conséquences désagréables pour les producteurs. La nécessité de fournir soi-même des services professionnels rend le modèle économique peu évolutif. À mesure que le nombre de clients augmente, je dois augmenter le nombre de personnes pour la livraison dans un marché où trouver des ressources professionnelles n’est pas facile. Une mauvaise documentation rend alors le processus de formation long et coûteux. L’avantage d’opérer sur un marché captif s’avère être une cage dont il est difficile de sortir.

Le modèle de production de logiciels est le même qu’il y a 20 à 30 ans. Les architectures et les technologies ont naturellement évolué au fil du temps mais, à quelques exceptions près, ceux qui produisent des logiciels créent ou sont responsables de l’ensemble de la pile d’applications en utilisant des langages et des méthodes traditionnels, éventuellement en utilisant des composants open source. Cependant, par rapport au passé, la complexité des applications a considérablement augmenté et il est de plus en plus difficile de maintenir le code à jour. Un changement de navigateur nécessite l’adaptation du front-end ainsi que celle de l’un quelconque des composants back-end. Ce qui se passe généralement, c’est que les candidatures restent”congelé” sur les technologies au moment de leur développement. En quelques années, celles-ci évoluent et l’application, d’un point de vue technologique, vieillit inexorablement. Suivre le rythme de mise à jour/évolution des technologies et des langages de développement est un défi même pour les entreprises les plus structurées.

Les modèles économiques et de développement pèsent sur les comptes et la rentabilité des éditeurs de logiciels, en particulier sur des marchés comme celui de la santé, où les ventes, même pour les leaders du marché, sont peu nombreuses (de l’ordre de dizaines), où la variabilité d’un client à l’autre est importante, les délais sont souvent courts (voir projets PNRR). Les investissements ne rapportent pas, la qualité en souffre, les clients sont souvent insatisfaits. Même les entreprises qui opèrent dans plusieurs pays ont du mal, en raison des limites des modèles que j’ai décrits et des spécificités des marchés, à récupérer leurs investissements et à développer leurs activités.

Si nous regardons les entreprises qui ont réussi et sont devenues grandes et rentables, nous pouvons voir que toutes ont construit leur succès grâce à un écosystème de partenaires qui ont développé le marché pour et avec elles. Le modèle économique en cycle fermé ne fonctionne pas, il ne conduit pas à la croissance.

Concernant les méthodes de développement du code, il est également nécessaire d’opérer ici un changement de paradigme. Plutôt que de tout faire soi-même, il vaut mieux utiliser des plateformes.”low-code» qui leur permettent de laisser l’honneur de la mise à jour technologique à leurs producteurs afin de se concentrer sur la logique et les besoins du domaine. Plutôt que d’essayer de développer des plateformes de développement similaires chez soi, il vaut mieux laisser ce travail à ceux qui le font professionnellement et se concentrer sur la logique du domaine dans lequel l’expérience et l’expertise que l’on possède peuvent faire la différence. Les plateformes »low-code” sont généralement bien documentés, sont accompagnés de cours et de matériel de formation, de sorte que l’inclusion de nouveaux développeurs est beaucoup plus facile que lorsqu’il existe des logiciels et des composants faits maison.

Prototypage, flexibilité, délais de développement sont quelques-uns des avantages qu’assurent les plateformes « low code », surtout lorsqu’elles sont spécialisées pour un domaine précis. Les Plateformes Digitales de Santé permettent de créer des écosystèmes partenaires et d’opérer sur le marché avec une logique efficiente et efficace d’un point de vue business.

Je comprends bien que ce changement n’est pas facile à accepter pour ceux qui sont peut-être habitués à “contrôler” e “tarif“le tout en autarcie totale, peut-être sans calculer le “coûts réels» que de cette façon ils subviennent à eux-mêmes et aux opportunités perdues, mais continuer à faire les mêmes choses en espérant des résultats différents est vraiment stupide.