Laurent Tréluyer, Cnaf : « La souveraineté compte pour 15% dans nos choix de solutions »
Le DSI de la Caisse nationale des allocations familiales doit jongler avec un agenda réglementaire chargé. Un programme imposé qui ne l'empêche pas d'impulser quelques orientations majeures, en particulier en matière de choix de solutions « souveraines ».
PublicitéDSI de l'AP-HP pendant près 9 ans, Laurent Tréluyer a rejoint la Caisse nationale des allocations familiales (Cnaf) en septembre 2023, en tant que directeur général délégué en charge des systèmes d'information. Il y dirige un service d'environ 880 personnes réparties sur 11 sites, auxquelles s'ajoutent les techniciens de proximité dans les 101 CAF de France.
L'effectif de la DSI est réparti dans trois directions des études (back-office, front-office, support), une direction technique, une direction des opérations (gérant la production, en particulier les calculs en batch), une direction de la sécurité et du contrôle interne (créée en 2024), une direction faisant le lien avec les MOA et une direction de la validation. Sans oublier des missions d'appui (sur l'architecture, le budget, la gestion des compétences).
Comme l'ensemble de la Cnaf, la DSI évolue dans le cadre d'une convention d'objectifs et de gestion (COG), passée avec l'Etat et qui court sur 5 ans (2023 à 2027 pour l'actuelle). Sur la période, la DSI de la Cnaf bénéficie d'un budget de 760 M€, hors masse salariale, avec quelques compléments en fonction des projets menés.
CIO : Depuis votre prise de fonctions, il y a deux ans et demi environ, quelle stratégie avez-vous voulu impulser ?
Laurent Tréluyer : J'ai rejoint la Cnaf en début de COG, avec un schéma directeur qui était très porté par le réglementaire du fait d'importantes réformes à mettre en place. En particulier la solidarité à la source qui touche tous les allocataires bénéficiant du RSA ou de la prime d'activité, et qui facilite leurs démarches avec des déclarations trimestrielles pré-remplies indiquant leurs ressources issues du Dispositif de ressources mensuelles (DRM). Sans oublier la réforme du complément de mode de garde (CMG). Trois autres réformes sont venues s'ajouter au cours des années 2023-2024, dont deux qui n'étaient pas inscrites au schéma directeur : la déconjugalisation des allocations pour les personnes handicapées - avec un calcul des ressources par personne et non plus par foyer -, l'aide d'urgence pour les victimes de violences conjugales - mise en place en moins d'un an -, et une collaboration avec France Travail pour assurer l'inscription automatique des personnes bénéficiant du RSA. Aujourd'hui, toujours avec France Travail, nous travaillons sur la partie sanctions, qui se matérialise par une modulation du RSA. Cette modification, qui permet tant à France Travail qu'aux conseils départementaux de prendre ce type de décision, est implantée depuis début 2026.
Tracer un schéma directeur IT dans un contexte dépendant du calendrier législatif doit être un exercice complexe...
Ça fait partie du travail ! Par exemple, le gouvernement actuel vient de décider d'augmenter de 50 € la prime d'activité. Même s'il s'agit de paramétrages, il faut retester pour vérifier la validité des règles pour tous les cas. Chaque année, le PLFSS (projet de loi de financement de la sécurité sociale) et le PLF (projet de loi de finances) peuvent porter des évolutions de nos SI. Nous entretenons un dialogue avec les directions d'administrations centrales pour définir leur niveau d'impact sur nos systèmes. Si on parle uniquement de paramétrages, les modifications sont envisageables en moins de 8 semaines, tests compris. Si on commence à toucher à la nature des prestations, les évolutions peuvent être plus importantes et demander 9 mois ou un an, même si les CAF peuvent assurer un traitement manuel pendant une période tampon. Ce dialogue permanent vise donc à partager les limites de nos SI, car il ne faut pas qu'une réforme nous empêche de verser l'ensemble des allocations. Par exemple, nous avons des échanges aujourd'hui sur l'ASU (Allocation sociale unique, pour laquelle un projet de loi est annoncé par le gouvernement, NDLR), une réforme qui aura des conséquences importantes puisqu'elle modifie profondément les règles d'attribution de 3 allocations très structurantes pour nous : allocation logement, RSA et prime d'activité. Notre capacité à l'implémenter dans les SI rentre en ligne de compte. Le dialogue sur ces sujets est essentiel ; en 2021 et 2022, une sous-estimation des travaux IT à mener avait retardé la mise en oeuvre de la réforme de l'allocation logement.
PublicitéLa deuxième réflexion consiste à adapter le système d'information à ces changements permanents, en le rendant plus modulaire. Mais tout en gardant un système intégré, permettant aux allocataires de ne déclarer qu'une fois leur situation et aux CAF de bien visualiser les dépendances entre allocations. On parle donc plutôt d'un équilibre à trouver. Notre système et notre base de données sont centralisés, les silos se situent dans les départements où opèrent les 101 CAF. Nous voulons garder cette force, cette efficacité, mais en y injectant un peu de modularité. D'où un débat que nous avons en interne sur le mode produit. Depuis le début de la COG actuelle, la DSI s'est déjà réorganisée par domaine dans le dialogue avec les métiers, pour prendre les décisions de façon commune, arbitrages budgétaires y compris.

« Nous migrons vers un moteur de règles unique, Catala développé en Open Source par l'Inria. » (Photo : Bruno Lévy)
Est-ce que l'introduction de ce mode produit fait partie de vos priorités pour le futur ?
Oui, c'est un des axes de la future COG démarrant en 2028, couplé aux réflexions portant sur les frontières entre back-office et front-office, de plus en plus de traitements étant effectués dans ces derniers. Nous prenons également quelques grandes orientations techniques, en particulier sur la modernisation de notre moteur de règles, un élément central de notre SI. La plupart de nos règles sont portées par un moteur développé en interne, basé sur du Cobol, et par un moteur Oracle pour la partie logement. Nous avons fait le choix de migrer vers un outil unique, Catala, développé en Open Source par l'Inria, dans le cadre du programme Apollo de construction de systèmes d'information pour les administrations. Un benchmark d'un an des solutions disponibles montre que ce choix nous permettra de modulariser les moteurs par prestations, renforçant ainsi notre agilité et notre capacité à répondre plus rapidement aux réformes et évolutions réglementaires. La souveraineté faisait également partie de nos critères de choix lors de cette sélection.
Dans la perspective de l'ASU, nous avons ainsi prévu de basculer les trois prestations concernées par cette réforme vers ce nouveau moteur. Nous serons également contributeur du projet Open Source de l'Inria et examinons les facteurs permettant de conforter ce projet, en construisant un écosystème permettant à d'autres administrations de le rejoindre.
Avez-vous formalisé une politique de l'Open Source ?
Sur Catala, oui. Il s'agit d'ailleurs d'un arbitrage pris par la direction générale. Nous allons dédier deux personnes cette année, et deux autres en 2027, qui contribueront au projet, aux côtés d'une équipe spécialisée dans l'implémentation et l'utilisation du moteur. C'est une manière de réduire le risque lié à l'investissement sur cette solution, dont nous sommes les premiers utilisateurs.

« Nous amorçons désormais un virage vers la conteneurisation. Toute nouvelle application est ainsi développée en cloud-natif. » (Photo : Bruno Lévy)
Quelles sont les architectures techniques supportant le SI et comment prévoyez-vous de les faire évoluer ?
Nous travaillons en majorité sur des architectures virtualisées - la sortie du mainframe datant de plusieurs années déjà -, nous avons depuis mis en oeuvre des architectures modulaires fondées sur des micro-services orientés événements et nous amorçons désormais un virage vers la conteneurisation. Toute nouvelle application est ainsi développée en cloud-natif. Concernant les bases de données relationnelles, nous avons fait le choix de converger majoritairement vers PostgreSQL, après un Legacy très orienté DB2.
L'ensemble du coeur de métier est hébergé dans nos datacenters, à l'exception du moteur de règles Oracle, qui est déployé dans le cloud de l'éditeur.
Les exemples que vous avez cités - remplacement du moteur de règles d'Oracle, réduction du patrimoine virtualisé VMware, migration vers PostgreSQL - témoignent-ils d'une volonté affirmée de vous éloigner des grands éditeurs ?
L'objectif est de travailler sur la résilience numérique, autrement dit d'être moins sensible aux variations de stratégie de ces grands éditeurs. En effet, tout dépend du degré de verrouillage vis-à-vis de ces acteurs : leur politique d'inflation des prix ne fonctionne réellement que lorsque la capacité de négociation est limitée. Éviter tout verrouillage n'est toutefois pas simple, car il s'agit de trouver un équilibre avec la performance du système d'information. Il convient d'abord de mesurer ce niveau de dépendance, raison pour laquelle nous nous intéressons à l'Indice de résilience numérique. Il est en effet difficile de ne pas s'appuyer sur de grands éditeurs pour disposer d'un SI performant, sécurisé et résilient. L'enjeu est donc d'objectiver cette dépendance afin d'instaurer un dialogue éclairé sur ce sujet avec les métiers.
Par ailleurs, nous poursuivons également un objectif de souveraineté, consistant à veiller à ce que nos données ne soient pas dépendantes de législations extra-européennes. Ce facteur est d'ores et déjà intégré à la note technique des soumissionnaires à nos marchés publics, à hauteur de 15%. L'inclusion de critères de souveraineté dans nos choix reste un chemin à construire, mais cette première décision nous permet d'affirmer une position claire vis-à-vis des métiers, des acheteurs et du marché. Dans le cadre du choix du moteur de règles, ces 15% ont ainsi été pris en compte, comme ils l'ont été pour la solution de rendez-vous et pour la signature électronique, solutions pour lesquelles nous avons retenu Oodrive.

« Le premier intérêt de l'IA générative est interne à la DSI. Pour les activités de développement, nous venons d'acheter 100 licences Codestral. » (Photo : Bruno Lévy)
Un cloud commun à la sphère sociale est en cours de construction, porté par l'Urssaf, la Cnam et la MSA. Y participez-vous ?
Notre empreinte datacenter étant réduite, nous ne pouvions pas être contributeur à ce projet, n'ayant pas grand-chose à y apporter. Notre datacenter à Sophia-Antipolis ne dispose pas de capacités d'extension suffisantes. Et notre second datacenter est loué à l'Agirc-Arcco. Mais nous étudions le potentiel de ce cloud communautaire, d'autant plus que nous avons une bonne expérience des cloud commerciaux, que nous avons élargie récemment à OVH, pour la partie LLM.
Quel intérêt présentent les IA génératives pour les métiers de la CNAF ?
Le premier intérêt concerne la DSI elle-même. Pour les activités de développement, nous venons d'acheter 100 licences Codestral (la solution dédiée de Mistral, NDLR) en mode SaaS. Nous allons également mettre en production une solution de RPA intégrant des capacités d'intelligence artificielle, afin d'offrir à nos collaborateurs un assistant et des fonctionnalités avancées telles que le RAG. Là encore, en nous basant sur Mistral. Nous testons aussi une solution se greffant à notre outil de Knowledge Management autour de notre base réglementaire. Pour renforcer l'outil de recherche existant, nous avons développé avec la CAF du Var un outil de GenAI fournissant directement une réponse aux questions des gestionnaires. Nous sommes en train d'élargir le test à cinq CAF avant d'envisager une généralisation à partir du second trimestre de cette année. Cela suppose un gros travail sur la qualité des documents, par exemple si la date d'applicabilité d'un texte n'est pas explicitement formulée. Mais nous commençons à obtenir des taux de réponse correcte suffisamment intéressants pour fournir une réelle aide à nos métiers, qui évoluent dans un contexte réglementaire complexe.
Par ailleurs, concernant le chatbot proposé aux allocataires, nous avons choisi une solution intégrant l'IA de Mistral, conçue par l'éditeur français Polaria. L'IA ne va pas dialoguer directement avec les allocataires, mais choisira, dans une base de réponses préformatées, celle qui est la plus adaptée à la question posée. Les déploiements doivent s'effectuer au second trimestre 2026. Sur les déclarations de grossesse, nous avons encore amélioré la reconnaissance des déclarations pour dépasser les résultats de la seule OCR et assurer une automatisation de la saisie des données. Bien-sûr, nous réfléchissons, avec les métiers, sur les endroits où déployer l'IA - et en particulier des agents - au coeur même des processus, en évaluant à chaque fois les coûts et l'impact environnemental.
Enfin, nous avons beaucoup de robots effectuant des tâches d'intégration de données, d'interrogations de portails, etc. Ils supplantent des processus auparavant effectués manuellement. Nous étudions l'ajout de l'IA à ces opérations pour aller encore plus loin dans ces automatisations.

« Avec 100 M€ de run, si vous subissez une inflation annuelle moyenne de 3% par an, cela signifie qu'il faut trouver 3 M€ tous les ans. » (Photo : Bruno Lévy)
Avez-vous un objectif chiffré sur les bénéfices pour les allocataires, ou sur les économies possibles ?
Nous avons plutôt abordé le sujet par un travail sur l'éthique, avec un comité dédié au sein duquel ces projets sont présentés. Toute hallucination dans le chatbot, par exemple, pourrait avoir des conséquences pour les allocataires et impacter les traitements liés au calcul des droits. Nous avons donc établi une charte d'utilisation de l'IA, identifié des cas d'usage et instauré des débats en interne, y compris avec les représentants du personnel, avant de lancer tout projet. Et nous avons construit, au sein de la DSI, une IA Factory regroupant une dizaine de personnes pour maîtriser ces technologies évoluant très rapidement.
De quels leviers disposez-vous pour maîtriser votre budget IT ?
En 2026, notre budget, hors masse salariale, s'élève à 160 M€. L'essentiel est consommé par le run, avec un volume d'investissement limité à entre 10 et 12 M€ par an sur la durée de la COG. Faire baisser cette part de run demande une attention particulière aux contrats, un recours plus fréquent aux centrales d'achat, une rigueur sur le décommissionnement, une réaffirmation de la stratégie Open Source - même si Open Source ne signifie pas gratuité -, une discipline sur les ratios d'externalisation et le recours à l'IA sur le développement. Malgré tout, ces efforts sont contrariés par l'augmentation des prix. Avec 100 M€ de run, si vous subissez une inflation annuelle moyenne de 3% par an, cela signifie qu'il faut trouver 3 M€ tous les ans. Par exemple, actuellement, le prix des PC est en train d'exploser, avec une multiplication des tarifs par un facteur proche de deux. Sur un budget d'achat de 4 M€ par an, cela pèse lourd.
Article rédigé par
Reynald Fléchaux, Rédacteur en chef CIO
Suivez l'auteur sur Twitter
Commentaire
INFORMATION
Vous devez être connecté à votre compte CIO pour poster un commentaire.
Cliquez ici pour vous connecter
Pas encore inscrit ? s'inscrire