Récemment, nous avons accompagné la définition du Schéma Directeur des Systèmes d’Information de la BU Santé Prévoyance d’un grand courtier, confrontée à une situation que beaucoup d’acteurs du secteur assuranciel reconnaîtront immédiatement.
D’un côté, les attentes business continuent de croître : accélérer les parcours de gestion, améliorer la qualité de service, exploiter davantage la donnée, préparer les usages liés à l’IA, réduire le TTM, accompagner les ambitions de croissance… De l’autre, le SI porte les stigmates de décennies d’empilements successifs : les incidents se multiplient, les équipes usent leur énergie à maintenir l’existant, chaque changement devient plus complexe que prévu, certaines compétences critiques reposent sur un nombre très limité de sachants. Comme souvent dans ce secteur, le problème ne se limite plus à la performance de la DSI ; lorsque les incidents affectent actes de gestion, parcours clients ou opérations métier, c’est directement la qualité de service, la performance opérationnelle et même la croissance qui en pâtissent.
À cela s’ajoute un contexte que beaucoup connaissent aujourd’hui : un nouvel actionnaire financier et l’ouverture d’un nouveau cycle de création de valeur, avec son cortège d’exigences renforcées de maîtrise des coûts, de performance opérationnelle, de capacité d’intégration, de qualité de pilotage et de scalabilité du modèle. En bref, les attentes vis-à-vis du système d’information augmentent précisément au moment où les ressources disponibles pour le transformer sont plus contraintes.
Le réflexe naturel consisterait à faire ce que les métiers demandent, mais dans un tel contexte, répondre à toutes les priorités métier, c’est dégrader davantage la capacité de transformation. C’est le paradoxe, auquel sont aujourd’hui confrontés de nombreux assureurs, qui amène une question rarement posée explicitement : le plan d’évolution du SI doit-il suivre les priorités métier… ou les contraindre ?
Le vrai coût de l’obsolescence, c’est la perte de liberté stratégique
En matière d’obsolescence, les discussions tournent généralement autour des technologies : versions logicielles anciennes, architectures historiques, dette technique, failles de sécurité, mauvaise « maintenabilité… Tout cela est réel, mais ce n’est au fond pas le sujet ; le véritable coût de l’obsolescence n’est pas technique, il est stratégique.
Un SI vieillissant génère progressivement des effets que toutes les directions finissent par ressentir : hausse de l’incidentologie, accaparement des équipes par le run, inflation des coûts de maintenance, mauvaise maîtrise des délais, dépendance à des experts historiques, difficulté croissante à intégrer de nouveaux usages…
Vu sous cet angle, l’obsolescence se mesure non pas à l’âge des applications, mais au nombre de décisions que l’entreprise n’est plus capable de prendre. Lorsqu’une évolution métier pertinente est repoussée parce qu’elle nécessiterait six mois d’analyse d’impact, des développements complexes ou des tests interminables, c’est un sujet de liberté d’action, pas d’urbanisme. Si l’entreprise conserve ses ambitions, le SI, lui, n’a plus la capacité à les soutenir.
Quand une bonne idée métier devient une mauvaise décision collective
Dans un environnement sain, la logique semble simple : les métiers expriment des besoins, la DSI les priorise, les projets les plus créateurs de valeur sont réalisés et tout le monde avance. Mais tout cela peut vite se dérègler.
Quand le SI est fragilisé, toutes les demandes métier ne se valent plus (attention, ce n’est pas que certaines seraient légitimes et d’autres non, chaque demande répond généralement à un vrai besoin) : certaines initiatives créent davantage de valeur qu’elles ne consomment de capacité de transformation et d’autres font exactement l’inverse :
- Une fonctionnalité très attendue peut générer une nouvelle couche de complexité.
- Un développement urgent peut renforcer une dépendance technologique déjà problématique.
- Un besoin parfaitement justifié peut éloigner encore un peu plus l’entreprise de sa trajectoire cible.
C’est à ce moment-là que les tensions apparaissent : les métiers voient une opportunité et la DSI voit une fragilité supplémentaire. Et les deux ont raison ! Aucun arbitrage sérieux ne peut être réalisé si l’on ne regarde que la valeur immédiate. Dans un SI fortement contraint, il devient indispensable d’évaluer également les répercussions sur la dette technique, la consommation de ressources rares, la compatibilité avec le futur socle, la réutilisabilité des composants, le risque de créer de nouveaux contournements… Une initiative peut être excellente pour un métier et néfaste pour l’entreprise. C’est une réalité difficile à accepter, mais l’ignorer coûte (beaucoup) plus cher.
Choisir, c’est renoncer : le SDSI, contrat de lucidité
Pendant longtemps, le Schéma Directeur des Systèmes d’Information a été perçu comme un exercice assez prévisible : cible –> trajectoire –> liste de projets –> calendrier.
Cette approche reste vraie lorsque l’organisation dispose de marges de manœuvre suffisantes, mais lorsque les ressources deviennent rares et que l’obsolescence pèse lourdement sur la capacité d’exécution, le SDSI change de nature. Il cesse d’être un catalogue d’initiatives et devient un outil d’arbitrage. Au-delà de seulement dire ce qu’il faut faire, il doit permettre de décider tout ce que l’on accepte d’abandonner, de reporter, de simplifier, traiter transitoirement et ce que l’on investit prioritairement pour restaurer le socle. Autrement dit, le SDSI organise les renoncements nécessaires. Le mot n’est pas populaire, mais toute stratégie repose sur des choix, donc des renoncements : certaines propositions de court terme doivent être refusées pour préserver la capacité de transformation future.
Et l’IA révèle impitoyablement ce que l’on refusait de voir
L’arrivée massive des sujets Data et IA ajoute une tension supplémentaire car les attentes sont considérables : automatisation des actes de gestion, amélioration de l’expérience client, pilotage prédictif, détection des anomalies et de la fraude, optimisation des parcours, personnalisation des services. Les opportunités sont réelles, mais reposent sur une hypothèse implicite : il existe un socle pour les supporter : des données accessibles, des référentiels fiables, des processus homogènes, des flux maîtrisés, une architecture cohérente… Dans la réalité , beaucoup de systèmes d’information en sont loin : données dispersées, traitements manuels, fichiers parallèles, règles de gestion dupliquées, traçabilité incomplète. Ces fragilités, l’IA ne les compensera pas elle les rend encore plus visibles, plus vite, plus brutalement.
Restaurer la capacité de transformation
Le débat n’oppose pas les métiers à la DSI mais deux visions du temps ; la première cherche à maximiser la réponse aux besoins immédiats, la seconde cherche à préserver la capacité future de l’entreprise à se transformer. Les deux sont légitimes et la difficulté consiste à les réconcilier. C’est précisément là que le SDSI retrouve toute sa valeur : en tant qu’outil de gouvernance offrant un cadre d’arbitrage collectif. La question n’est pas de savoir si le SDSI doit suivre les priorités métier ou les contraindre mais d’identifier quelles contraintes accepter aujourd’hui pour retrouver demain la liberté de transformer l’entreprise. Comment faire émerger une vision partagée lorsque chacun observe le problème à travers son propre prisme ? C’est précisément sur ce terrain que se joue la réussite d’un SDSI.
Chez Talisker, nous savons que l’exercice n’a de valeur qu’en tant qu’outil de décision, de dialogue et de mobilisation. La qualité de la cible n’est rien sans la capacité du collectif à la comprendre, à l’assumer et à la porter. C’est là que commence le vrai travail de transformation, le sujet dont nous aimons le plus débattre avec les dirigeants, les DSI et les métiers confrontés à ces défis. Parlons-en !
