Le retour d'expérience du mois
La gestion de l’obsolescence par les risques de sécurité à la Caisse des Dépôts
Retour
Lors de la matinale Cybersécurité et Cyber Résilience du 2 octobre 2025, François RENOU, Responsable Gestion de l’obsolescence & RSSI ACN chez CDC Informatique, a présenté comment une démarche opérationnelle abordée sous l’angle de la sécurité a permis une réduction durable de l’obsolescence du SI au sein de la Caisse des Dépôts et Consignations.
C’est de 2021 à 2023 que nous avons lancé une phase exploratoire de la réduction de la Dette Technique. Nous nous étions fixés un périmètre principalement axé autour des OS et des Bases de Données. Cette phase exploratoire nous a permis de mettre en place une gouvernance nouvelle pour assurer le suivi de notre feuille de route, et en même temps d’acculturer les utilisateurs et les intervenants à cette notion de dette technique. Par ailleurs, le terme « dette technique » tend à faire oublier la nécessaire implication de tous les acteurs. Notamment du côté des métiers, qui procédaient parfois à des arbitrages budgétaires au profit d’évolutions fonctionnelles d’une application donnée, et donc au détriment du règlement d’une dette technologique qui la concernait au premier chef...
Au bout de ces 2 années, les collaborateurs avaient pris conscience de l’importance du sujet et avaient une vision plus claire de l’objectif à atteindre. La réponse à la question du « comment s’y prendre » restait encore un peu plus compliquée à s’approprier. Et comme, durant cette phase, la dette technique n’a cessé de s’alourdir chaque jour un peu plus, c’est le passage à l’échelle qui semblait difficile à réaliser.
Les 3 premiers mois ont été consacrés à :
Avec un parc de plus de 10.000 serveurs, et plus de 500 applications majeures, nous avons réalisé un état des lieux détaillé le plus objectif possible. Nous avons ensuite fait valider tous ces éléments au plus haut niveau.
Pour faire simple, auprès des populations non-IT, nous avons défini l’obsolescence comme l’état qui ne permettait plus de disposer des correctifs de sécurité et donc, qui induisait nécessairement des vulnérabilités sans solution, avec un impact potentiellement fort. De par notre culture commune, l’approche sécurité parle davantage plutôt que parler d’applications qui se rigidifient ou qu’il est plus compliqué de faire évoluer. Avec ce message, nous avons eu un soutien plus massif des collaborateurs autour de la réduction de l’obsolescence.
Avec un diagnostic partagé, des objectifs clairs, un outil de pilotage efficace et une gouvernance résolument tournés vers l’opérationnel nous avons donné un nouvel élan et une nouvelle dimension à ce vaste projet.
Nous avons fait la distinction entre les composants impactant les applications et les composants purement techniques (plus nombreux, avec des cycles de vie courts mais plus faciles à upgrader). Enfin, nous avons répertorié les applications en fonction de leur degré d’exposition sur le web ou sur l’intranet, et selon la criticité des données qu’elles manipulaient.
Nous nous sommes dotés d’une vision à 18 mois (2 ans maintenant) qui nous permet d’anticiper les obsolescences à venir à court/moyen terme, et de les traiter avant qu’il ne soit trop tard, tout en réduisant les obsolescences déjà atteintes. Le diagramme ci-dessous évalue l’évolution du taux d’obsolescence, selon qu’on agisse, ou que l’on laisse les choses en l’état. Au-delà de 24 à 30 mois, les prévisions sont moins nettes, dans la mesure où des dates réelles d’End Of Life n’ont souvent pas encore été communiquées par les éditeurs ou constructeurs.
Nous avons mis en place un suivi industrialisé (production automatique des KPI, projection à 12 ou 18 mois….). Des comités opérationnels se tiennent tous les 2 mois, et nous regardons par périmètre métier où on en est, ce qui dérape, ce que l’on doit corriger, et nous définissons les plans d’actions en regard.
Il y a 4 personnes à temps plein sur ce pilotage, sans compter les centaines de personnes qui travaillent avec nous pour mener les actions au quotidien de réduction de l’obsolescence. Il y a également d’autres comités de pilotage plus classiques, plus managériaux, qui se tiennent tous les 4 ou 6 mois.
Nous avons pris une décision forte dès le départ : tout ce qui arrive à obsolescence à horizon de 6 à 12 mois ne sera plus livré par les équipes IT. Ce message a été bien compris par tout le monde et cela n’a finalement pas eu trop d’impact sur les équipes opérationnelles.
Durant tout le projet, nous avons communiqué de façon large sur :
Tout cela a nécessité un engagement fort de la part des Métiers, des MOA, des équipes techniques, des architectes…
En l’espace de 18 mois, pour les composants applicatifs, le taux d’obsolescence a baissé de 25% et les 50% en 3 ans sont dans la ligne de mire. Les obsolescences à horizon 12 et 18 mois ont déjà baissé de plus de 80%. Enfin, les 2/3 des composants ont une phase d’obsolescence qui démarre au plus tôt d’ici 3 ans. Pour les composants techniques purs, le taux d’obsolescence est déjà en dessous de la cible.
Tous ces éléments nous laissent penser que la cible sera atteinte, ce qui n’était pas évident au départ, ni même il y a 6 mois.
Au-delà des résultats à date et à horizon 12 mois, la confiance est établie : le traitement de l’obsolescence a vraiment été intégré dans le fonctionnement de l’entreprise, c’est devenu un sujet sur lequel il n’est plus nécessaire de convaincre et qui est de plus devenu durable !
François, à quand remonte la prise de conscience d’une dette technique ?
C’est de 2021 à 2023 que nous avons lancé une phase exploratoire de la réduction de la Dette Technique. Nous nous étions fixés un périmètre principalement axé autour des OS et des Bases de Données. Cette phase exploratoire nous a permis de mettre en place une gouvernance nouvelle pour assurer le suivi de notre feuille de route, et en même temps d’acculturer les utilisateurs et les intervenants à cette notion de dette technique. Par ailleurs, le terme « dette technique » tend à faire oublier la nécessaire implication de tous les acteurs. Notamment du côté des métiers, qui procédaient parfois à des arbitrages budgétaires au profit d’évolutions fonctionnelles d’une application donnée, et donc au détriment du règlement d’une dette technologique qui la concernait au premier chef... Au bout de ces 2 années, les collaborateurs avaient pris conscience de l’importance du sujet et avaient une vision plus claire de l’objectif à atteindre. La réponse à la question du « comment s’y prendre » restait encore un peu plus compliquée à s’approprier. Et comme, durant cette phase, la dette technique n’a cessé de s’alourdir chaque jour un peu plus, c’est le passage à l’échelle qui semblait difficile à réaliser.
Pour passer à l’action, quel angle avec-vous choisi ?
En prenant conscience des risques sécuritaires que faisait courir une dette technologique non maîtrisée, le ComEx de la Caisse des Dépôts a décidé fin 2023 d’engager un chantier « Gestion de la Dette Technique » sur une durée de 3 ans. Ce programme sponsorisé par le Top Management est également suivi par les corps de contrôle, et mené sous la responsabilité de la Direction Sécurité, Architecture et Stratégie Technologique nouvellement créée.Les 3 premiers mois ont été consacrés à :
- Définir le périmètre à couvrir et la cible,
- Définir les métriques et indicateurs : que mesure-t-on ? Comment juger du bon avancement ?
- Définir et commencer à construire l’outillage, notamment un référentiel des End Of Life, et identifier de quelles informations pertinentes notre CMDB disposait,
- Adapter la gouvernance existante et dresser un état des lieux objectivé.
Avec un parc de plus de 10.000 serveurs, et plus de 500 applications majeures, nous avons réalisé un état des lieux détaillé le plus objectif possible. Nous avons ensuite fait valider tous ces éléments au plus haut niveau.
Pour faire simple, auprès des populations non-IT, nous avons défini l’obsolescence comme l’état qui ne permettait plus de disposer des correctifs de sécurité et donc, qui induisait nécessairement des vulnérabilités sans solution, avec un impact potentiellement fort. De par notre culture commune, l’approche sécurité parle davantage plutôt que parler d’applications qui se rigidifient ou qu’il est plus compliqué de faire évoluer. Avec ce message, nous avons eu un soutien plus massif des collaborateurs autour de la réduction de l’obsolescence.
Avec un diagnostic partagé, des objectifs clairs, un outil de pilotage efficace et une gouvernance résolument tournés vers l’opérationnel nous avons donné un nouvel élan et une nouvelle dimension à ce vaste projet.
Quel a été le périmètre d’action ?
Nous nous sommes concentrés sur tous les composants de notre SI, plus exactement ceux qui ont plus de 10 instances. Nous avons exclu les postes de travail, les infrastructures de sécurité et le réseau pour lesquels nous savions que l’obsolescence était déjà bien gérée.Nous avons fait la distinction entre les composants impactant les applications et les composants purement techniques (plus nombreux, avec des cycles de vie courts mais plus faciles à upgrader). Enfin, nous avons répertorié les applications en fonction de leur degré d’exposition sur le web ou sur l’intranet, et selon la criticité des données qu’elles manipulaient.
Nous nous sommes dotés d’une vision à 18 mois (2 ans maintenant) qui nous permet d’anticiper les obsolescences à venir à court/moyen terme, et de les traiter avant qu’il ne soit trop tard, tout en réduisant les obsolescences déjà atteintes. Le diagramme ci-dessous évalue l’évolution du taux d’obsolescence, selon qu’on agisse, ou que l’on laisse les choses en l’état. Au-delà de 24 à 30 mois, les prévisions sont moins nettes, dans la mesure où des dates réelles d’End Of Life n’ont souvent pas encore été communiquées par les éditeurs ou constructeurs.
Avez-vous mis en place une organisation spécifique pour suivre ce chantier ?
Oui, nous nous sommes organisés de façon très opérationnelle avec les équipes de développement, d’intégration, de production, Maitrise d’oeuvre Maitrise d’ouvrage, Product Owners… de façon à coller aux attentes du terrain en nous appuyant sur notre CMDB qui donne vraiment une image détaillée, précise et à jour en permanence de notre SI.Nous avons mis en place un suivi industrialisé (production automatique des KPI, projection à 12 ou 18 mois….). Des comités opérationnels se tiennent tous les 2 mois, et nous regardons par périmètre métier où on en est, ce qui dérape, ce que l’on doit corriger, et nous définissons les plans d’actions en regard.
Il y a 4 personnes à temps plein sur ce pilotage, sans compter les centaines de personnes qui travaillent avec nous pour mener les actions au quotidien de réduction de l’obsolescence. Il y a également d’autres comités de pilotage plus classiques, plus managériaux, qui se tiennent tous les 4 ou 6 mois.
Nous avons pris une décision forte dès le départ : tout ce qui arrive à obsolescence à horizon de 6 à 12 mois ne sera plus livré par les équipes IT. Ce message a été bien compris par tout le monde et cela n’a finalement pas eu trop d’impact sur les équipes opérationnelles.
Durant tout le projet, nous avons communiqué de façon large sur :
- l’impossibilité de patcher des composants obsolètes. C’est un argument simple, et bien accepté par tout le monde,
- l’exploitabilité des vulnérabilités de composants obsolètes (mode RedTeam). Le risque de compromission est un argument qui porte,
- la démarche, les objectifs, les solutions ;
- le référentiel des versions supportées et des EOL,
- les calendriers des migrations…
Tout cela a nécessité un engagement fort de la part des Métiers, des MOA, des équipes techniques, des architectes…
Quels résultats avez-vous obtenus ?
En l’espace de 18 mois, pour les composants applicatifs, le taux d’obsolescence a baissé de 25% et les 50% en 3 ans sont dans la ligne de mire. Les obsolescences à horizon 12 et 18 mois ont déjà baissé de plus de 80%. Enfin, les 2/3 des composants ont une phase d’obsolescence qui démarre au plus tôt d’ici 3 ans. Pour les composants techniques purs, le taux d’obsolescence est déjà en dessous de la cible.Tous ces éléments nous laissent penser que la cible sera atteinte, ce qui n’était pas évident au départ, ni même il y a 6 mois.
Au-delà des résultats à date et à horizon 12 mois, la confiance est établie : le traitement de l’obsolescence a vraiment été intégré dans le fonctionnement de l’entreprise, c’est devenu un sujet sur lequel il n’est plus nécessaire de convaincre et qui est de plus devenu durable !
Autres articles sur le même thème
Le retour d'expérience du mois
Déploiement d'une communauté Citizen Development à la Société Générale
Dorian Gougeon, Chapter Manager Citizen Dev et AI Officer - Société Générale Securities Services
Dorian Gougeon, Chapter Manager Citizen Dev et AI Officer - Société Générale Securities Services
Mag #26
Lire l'article
