Interviews

Bintou Boïté, Cnam : « l'indépendance technologique est un enjeu de survie »

---

Pour répondre aux risques d'interruption d'un service, mais aussi endiguer l'inflation imposée par les grands éditeurs, la DSI de la Cnam a lancé une politique d'indépendance technologique. Avec, dès 2025, de premiers choix d'alternatives à Microsoft Office, OpenShift ou VMware. Pour Bintou Boïté, directrice déléguée des systèmes d'information, le plus dur reste à faire : assurer l'appropriation par les équipes.

PublicitéDirectrice déléguée des systèmes d'information de la Caisse nationale de l'Assurance Maladie depuis mai 2023, après avoir réalisé une grande partie de sa carrière à la CPAM des Hauts-de-Seine et avoir rejoint la caisse nationale en 2017 sur un poste de maîtrise d'ouvrage, Bintou Boîté est à la tête d'une DSI de 1300 personnes environ. Soit un budget inscrit dans la convention d'objectifs et de gestion (COG) de 280 M€, auquel s'ajoutent, en 2025, plusieurs dizaines de millions d'euros permettant de tenir les objectifs de cette convention.

Pilotant un système d'information très étendu, dont un cinquième évolue chaque année du fait de la réglementation, Bintou Boïté s'est attachée à accélérer la mise en production des projets, notamment via un PaaS interne à base de conteneurs. La DSI de l'Assurance Maladie s'est aussi lancée dans une trajectoire d'indépendance technologique, pour ne pas finir étranglée par la politique tarifaire des grands fournisseurs de technologies. Selon elle, la facture logicielle théorique de la Cnam - avant négociations - aurait dû s'envoler de 40% entre 2024 et 2025 !

Vous êtes arrivée à la tête de la DSI de la Cnam il y a tout juste trois ans. Quelles principales impulsions avez-vous souhaité donner ?

Bintou Boïté : Nous avons d'abord travaillé sur la maîtrise de notre système d'information, notamment via une cartographie de nos sous-systèmes applicatifs et de tous nos composants techniques. Nous disposons désormais d'une vraie base de données de gestion des configurations (CMDB) au sein de laquelle tous les composants du SI de l'Assurance maladie sont actualisés à J+1, de façon automatique. Dans un SI imposant comme le nôtre - composé d'environ 700 sous-systèmes applicatifs et d'un total de 4500 composants techniques -, savoir quelle technologie est déployée, dans quelle version et à quel endroit constitue une force importante, surtout dans une DSI très répartie sur le territoire.

Dans le même esprit, nous avons travaillé sur la relation avec les MOA [maîtres d'ouvrage, NDLR], autour de principes directeurs, centrés sur l'urbanisation et l'architecture d'entreprise. Dès la conception, nous nous posons des questions métiers autour des processus et des modes de fonctionnement pour que la déclinaison en architecture fonctionnelle puis technique soit la plus cohérente possible.

Un des objectifs principaux de ma prise de poste consistait, en effet, à améliorer le time-to-market (TTM) sur nos projets. Car notre SI est non seulement imposant, mais il évolue beaucoup : nous modifions chaque année environ 20% de notre parc applicatif - soit 240 000 jours homme par an -, via surtout des évolutions réglementaires que nous devons mettre en oeuvre. Le fait d'avoir cartographié tous les sous-systèmes applicatifs permet de comprendre les dépendances, et le fait de demander aux directions métiers de se coordonner en amont de programmes souvent transverses permet d'aller plus rapidement sur la solution cible. L'objectif est d'éviter d'aboutir à une solution non mutualisable, ce qui arrivait encore fréquemment par le passé. Il est également essentiel que nous n'ayons pas à retravailler les solutions que nous concevons parce qu'un pan du projet aurait été oublié. Compte tenu de notre taille et de la volumétrie de nos projets, nous n'avons pas les moyens de recommencer les développements.

Publicité
« Dans la fabrication logicielle, une direction unique permet d'accentuer les mutualisations et de commencer à harmoniser les pratiques entre pôles, tout en gérant une roadmap plus collective qu'auparavant. » (Photo : Bruno Lévy)

Est-ce que c'est allé de pair avec une réorganisation de la DSI ?

Nous avons d'abord commencé par sanctuariser la production, soit le paiement des prestations aux assurés sociaux. C'est notre métier de base qui doit être assuré de façon continue, avec des SLA extrêmement élevés. On parle ici de 60 millions d'assurés, d'un million et demi de connexions par jour au compte Ameli, de 6 millions de feuilles de soins par jour... Cet aspect récurrent sur des volumétries très importantes est très contraignant.

La partie fabrication logicielle a, elle, largement évolué. Nous partions de pôles indépendants et géographiquement dispersés, chacun ayant son domaine de compétence privilégié, sans direction commune. D'où des processus un peu différents d'un pôle à l'autre. Dans mon précédent poste, à la maîtrise d'ouvrage, j'ai pu me rendre compte de ces écarts. Cette dispersion créait aussi des discussions sur l'allocation des budgets. Le principal changement a consisté à rattacher toutes ces équipes à une seule direction. Nous n'avons pas supprimé les pôles, mais cette direction unique permet d'accentuer les mutualisations et de commencer à harmoniser les pratiques entre pôles, tout en gérant une roadmap plus collective qu'auparavant.

Sur la fabrication logicielle, avez-vous réinternalisé des compétences, la Cour des comptes avait notamment pointé le trop important recours aux prestataires dans un rapport de 2024 ?

Oui, et nous avons pris des engagements à ce sujet dans la Convention d'objectifs et de gestion (COG) 2023-2027. Nous avons eu le droit à un recrutement de 450 postes sur la période, maîtrises d'ouvrage y compris. Pour la DSI seule, cela représente entre 360 à 370 postes, la moitié étant consacrée à l'augmentation de nos capacités et l'autre moitié à des réinternalisations. Nous en mesurons les effets : notre roadmap sur 2026 prévoit 240 000 jours homme de développement, contre 195 000 en 2022. Sur la durée du la COG, nous avions pour objectif de passer de plus de 50% d'externalisation à 41%. Nous devrions atteindre ce ratio dès cette année.

Un cinquième de votre SI est modifié chaque année, avant tout du fait des évolutions réglementaires. Subsiste-t-il une place pour la réduction de la dette technique ?

Dans mon poste précédent, en tant que maîtrise d'ouvrage, j'ai vécu des situations où, sur certains projets, je devais choisir entre développer les évolutions fonctionnelles et résorber la dette technique. C'est pourquoi j'ai décidé de sanctuariser environ 20 000 jours par an sur la dette. Tous les projets partagent ainsi le coût de celle-ci. Et, au sein de la direction de l'architecture, nous avons créé il y a 3 ans un département de gestion de la dette, qui l'a cartographiée et pilote les actions de rattrapage. Nous commençons également à examiner les possibilités offertes par l'IA dans la réécriture de codes assez anciens.


« Sur notre PaaS, nous allons sortir la première version de deux applicatifs back-office en moins de deux ans, contre 3 à 4 ans auparavant. » (Photo : Bruno Lévy)

Dans cet objectif de réduction du TTM, la Cnam construit aussi sa propre plateforme cloud de niveau PaaS, sur OpenShift 4. Où en êtes-vous de ce développement ?

En mobilisant essentiellement des compétences internes, nous avons effectivement construit, en un an environ, une plateforme d'hébergement en conteneurs. Sans attendre qu'elle soit pleinement finalisée, nous y avons lancé le développement de deux applicatifs de back-office. Sur des projets de refonte touchant à ce type de systèmes, nous constations habituellement des délais de 3 à 4 ans. Sur notre PaaS, nous allons sortir la première version de ces applicatifs en moins de deux ans.

Pour construire cette plateforme, nous avons bâti une organisation matricielle, regroupant une quarantaine profils différents issus de la DSI : des exploitants, mais aussi des profils issus de la filière digitale, qui avait mené la première expérience de plateforme cloud au sein de la Cnam, sur une technologie aujourd'hui dépassée.

Si cette équipe a monté le coeur de la plateforme PaaS, elle est aussi compétente pour l'onboarding des projets, qu'ils soient hébergés sur celle-ci ou sur le Legacy ! Cette équipe assure également toute la partie aval - intégration et déploiements - que ce soit sur des conteneurs ou sur des technologies de virtualisation plus classiques. J'ai aussi demandé que les composants techniques que nous construisons soit adressables tant sur le cloud que sur le Legacy.

Autrement dit, afin d'étendre ses usages en interne, le cloud est désormais considéré comme une technique pleinement intégrée à notre fonctionnement, et non plus comme un Ovni évoluant en dehors du système, comme ce fut le cas avec notre première construite sur OpenShift 3, en dehors du SI.

Y-a-t-il un lien avec le cloud communautaire de la sphère sociale, dont la Cnam est un des contributeurs ?

Le projet de cloud communautaire préexistait à la construction de cette plateforme interne. Mais cette dernière est appelée à y jouer un rôle. Plutôt que de développer une troisième plateforme pour ce cloud communautaire, nous avons décidé de mettre à disposition de la sphère sociale nos capacités existantes - donc notre PaaS -, mais aussi de l'hébergement plus classique.

Est-ce que la disponibilité de ce PaaS interne s'accompagne d'une doctrine voulant que tout nouveau projet aille par défaut sur ce cloud ? Et allez-vous migrer des systèmes existants sur cette plateforme ?

Nous n'allons pas migrer massivement l'existant, sauf ce qui était hébergé sur la première plateforme cloud, soit les téléservices notamment à destination des professions de santé. Par ailleurs, chaque équipe projet conserve le choix de son hébergement. J'observe qu'elles demandent de plus en plus à être hébergées sur la plateforme cloud, car elles ont pris conscience que cela leur permettait d'accélérer leurs développements.


« Quitter A pour aller chez B reviendrait à déplacer notre dépendance, pas à la maitriser. Il faudra donc gérer la cohabitation de plusieurs technologies, ce qui suppose d'adapter l'organisation de la DSI. » (Photo : Bruno Lévy)

Si vous ne prévoyez pas de migrer votre Legacy virtualisé sur le cloud interne, quel avenir auront les technologies VMware au sein de la Cnam ?

Avec cet éditeur, nous avons commencé par faire respecter nos droits, en demandant l'accès aux licences perpétuelles que nous avions déjà payées fin 2022. Nous avons pu ainsi éviter de passer en souscription. Ensuite, nous avons trouvé des licences sur le marché de l'occasion, permettant de combler nos besoins pour les 18 mois qui viennent. Enfin, nous avons réalisé que de nombreuses sociétés proposent aujourd'hui des services de support sur les technologies VMware et avons contractualisé avec l'une d'elles (Rimini Street, NDLR). La conséquence de toutes cas actions ? Nous n'avons pas versé un centime à VMware cette année, sans le quitter pour autant. On peut donc décorréler l'intérêt financier des grands éditeurs de notre obligation de travailler avec eux !

Cette approche nous donne 12 à 18 mois pour engager une stratégie de sortie. Nous sommes ainsi en train de choisir l'alternative à cette technologie. Nous avons un patrimoine de 25 000 VM ; les migrer demandera donc du temps. Nous continuerons de toute façon à avoir un hébergement virtualisé, en complément de notre PaaS. Car nous n'avons absolument pas intérêt à mettre tous nos oeufs dans le même panier. Quitter A pour aller chez B reviendrait à déplacer notre dépendance, pas à la maitriser. Il faudra donc gérer la cohabitation de plusieurs technologies, ce qui suppose d'adapter l'organisation de la DSI à cette gestion nouvelle de la diversité technique.

Au sein de la Cnam, y-a-t-il eu un élément déclencheur vous faisant prendre conscience de votre trop grande dépendance à certains acteurs ?

Me concernant, c'était juste avant les J.O. de Paris, à l'été 2024, lors de la panne Microsoft provoquée par une mise à jour d'un éditeur tiers (Crowdstrike, NDLR). En tant qu'opérateur chargé d'un service public, la continuité de services fait partie de nos règles cardinales. Ce premier constat a été amplifié par les évolutions géostratégiques : si quelqu'un quelque part décide, pour une raison ou une autre, que les entreprises de son pays ne peuvent plus travailler avec nous, pourrons-nous continuer à traiter nos prestations ? Ces réflexions nous ont amené à prendre des décisions en termes de PCA - pour être prêts à faire face à ce type d'événement - et de recherche d'alternatives, même si leur mise en place demande du temps. Nous avons ainsi ajouté un risque à couvrir dans notre PCA : le risque de rupture numérique de long terme. Nous avons aussi effectué un état des lieux des empreintes des différents éditeurs en interne. Notre situation actuelle voit un tiers d'Open Source cohabiter avec un tiers de licences perpétuelles et un tiers de souscriptions. Ce qui permet aussi de prioriser notre plan de continuité, les licences perpétuelles donnant plus de latitude que les souscriptions pour peu qu'on sache fonctionner en circuit fermé.

A ce sujet du maintien de la continuité du service public, s'ajoute une question financière. Entre 2024 et 2025, notre facture logicielle théorique aurait dû grimper de 40%, augmentation s'effectuant aux quatre cinquièmes à périmètre constant. Or, plus cette facture-là augmente - après négociation, elle progresse tout de même de 10 à 15% -, plus nous sommes obligés d'abaisser les investissements matériels. Est-ce cela signifie que d'ici trois ou quatre ans, l'Assurance maladie ne pourra plus moderniser ses équipements ? L'indépendance technologique est donc aussi un enjeu de survie de nos SI.


« Jamais nous ne trouverons un équivalent strict de Microsoft Office ! Mais une bonne partie des effectifs de l'Assurance maladie ne font ni macro Excel ni tableau croisé dynamique au quotidien, moi y compris. » (Photo : Bruno Lévy)

Dans cette quête d'indépendance, allez-vous renforcer votre politique Open Source ?

Nous avons historiquement un marché d'assistance Open Source que nous avons renouvelé cette année en y intégrant, pour la première fois, des unités d'oeuvre de fabrication. Je souhaite en effet que nous devenions contributeur Open Source, et non plus de simples utilisateurs. Cette année, nous avons aussi créé une mission chargée de l'indépendance numérique, composée de 5 personnes et chargée de piloter la feuille de route sur ce sujet, l'Open Source étant un des leviers possibles. Par ailleurs, dans les choix de la direction technique chargée du socle de notre SI, l'aspect relatif à la souveraineté est devenu un des principaux critères de choix.

Mais le plus facile dans la mise en place d'alternatives, c'est de choisir l'outil de remplacement ; négliger la partie transition, migration et accompagnement revient à prendre des décisions qui ne sont jamais appliquées !

La Cnam a annoncé le basculement de ses postes de travail vers une alternative Open Source à Microsoft Office, LaSuite, via un partenariat avec la Dinum (Direction interministérielle du numérique) ? Où en êtes-vous de ce projet ?

Nous lançons, avec des utilisateurs de la Cnam et des caisses primaires, un pilote en juin, sur deux premiers composants : Visio (visioconférence) et Tchap (messagerie instantanée). Nous visons un démarrage de pré-série à la rentrée et une généralisation en 2027, afin de nous désengager progressivement de Zoom, notre solution actuelle de visioconférence. Même si certaines fonctionnalités de Zoom resteront certainement indispensables pour quelques usages, comme des webinaires, et si nous devons conserver quelques licences auprès de cet éditeur, cela ne nous empêchera pas de basculer largement sur Visio sans attendre qu'il offre un service équivalent.

De la même manière, jamais nous ne trouverons un équivalent strict de Microsoft Office ! Mais une bonne partie des effectifs de l'Assurance maladie ne font ni macro Excel ni tableau croisé dynamique au quotidien, moi y compris. Nous ne sommes pas dans une optique consistant à affirmer que nous quittons totalement Office et que plus personne ne l'utilisera, d'autant qu'une partie de nos logiciels Legacy de production s'appuie encore sur des versions lourdes de Word. Mais la relation de dépendance n'est pas la même si vous avez 10 000 licences, plutôt que 80 000, soit le nombre d'agents de la Sécurité sociale. Cette approche différenciée permet aussi d'apporter une réponse sur la souveraineté des données, car Office s'exécute sur le cloud et on sait bien que, même localisé en France, tout cloud américain est sujet à caution quant à la sécurité des informations qui y sont hébergées.

Quelles sont vos priorités pour les 18 mois qui viennent ?

Elles prolongent celles déjà mise en oeuvre. A savoir finir d'industrialiser la production de projets. Par ailleurs, nous voulons continuer à sécuriser nos hébergements et la politique d'investissement associée, pour absorber les augmentations de volume mais aussi les évolutions technologiques. Tout en réfléchissant à, éventuellement, ouvrir nos hébergements à des tiers, de la sphère sociale ou du secteur public. Le cloud communautaire que nous construisons avec les autres acteurs de la sphère sociale pointe déjà dans cette direction.

Nous voulons aussi poursuivre la montée en compétences de la DSI sur les technologies clefs -cloud, data et IA -, sinon le décalage entre nos pratiques et l'état de l'art risque de devenir trop important. Enfin, nous devrons réussir les premières actions de transition améliorant notre indépendance numérique. En 2025, nous avons effectué de premiers choix de technologies alternatives - à Microsoft Office, à OpenShift, à Citrix, à VMware ou à Dollar Universe (un ordonnanceur appartenant à Broadcom, NDLR) -, il faut maintenant qu'elles trouvent leur place et que les équipes se les approprient.

Article rédigé par

Reynald Fléchaux, Rédacteur en chef CIO
Suivez l'auteur sur Twitter

Partager cet article