En avril 2018, la Banque du BST a tenté de transférer 1,3 milliard de dossiers clients d'une plateforme de traitement existante vers un nouveau système construit par sa société mère espagnole. La migration ne tient pas compte des interdépendances sans papiers entre les structures de données. En quelques heures, 1,9 million de clients ont été radiés de leurs comptes. Certains ont vu les soldes des autres clients. Les cas de fraude ont augmenté. La panne a duré des semaines.
Le coût total: 330 millions de livres en réhabilitation, compensation et perte de recettes (Les indépendants) . Le PDG Paul Pester démissionne sous pression (Nouvelles BBC) . La commission spéciale du Trésor britannique a lancé une enquête parlementaire. L'Autorité de conduite financière a perçu 48,65 millions de livres d'amendes (Reuters) . Quatre-vingt mille clients ont quitté la banque.
Le conseil d'administration du BST n'a pas pleinement saisi le risque avant qu'il ne devienne un titre. C'est le scénario que ce guide vous aide à prévenir. Votre conseil d'administration n'a pas besoin de comprendre comment fonctionne l'infrastructure de transaction existante. Ils doivent comprendre ce qui se passe quand il échoue, ce que cela coûte de ne rien faire et à quoi ressemble un investissement structuré. Cet article vous donne la langue, les données et un modèle de présentation prêt à l'emploi pour faire ce cas.
Ce que le conseil d'administration s'inquiète réellement
Les conseils d'administration ne pensent pas aux langues de programmation. Ils pensent en trois catégories : responsabilité, résilience et agilité. Chaque argument que vous faites doit atterrir dans un de ces seaux.
Responsabilité et exposition réglementaire
Les organismes de réglementation traitent de plus en plus les défaillances du système comme des défaillances de la gouvernance. L'amende de 48,65 millions de livres du BST n'est pas venue à cause d'un bug logiciel, mais parce que la FCA a constaté que la banque « n'avait pas planifié correctement la migration des TI » et manquait de « systèmes de gestion des risques adéquats » (Nouvelles BBC) . Dans des cadres tels que la DORA dans l'UE et les règles de résilience opérationnelle de la FCA au Royaume-Uni, les conseils d'administration sont responsables personnellement du risque technologique. Un système qui fonctionne sur code que personne ne peut maintenir n'est pas un problème technologique. C'est une responsabilité fiduciaire.
Les normes modernes de déclaration des risques des conseils d'administration renforcent ce changement. SelonVComply analyse 2025 des attentes du conseil d'administration, les administrateurs s'attendent maintenant à ce que les rapports sur les risques soient « clairs, prospectifs et directement liés à l'impact opérationnel ». Si vos anciens systèmes n'apparaissent pas dans votre registre des risques d'entreprise avec une exposition financière quantifiée, vous avez un déficit de gouvernance.
Résilience opérationnelle et risque de revenus
Les systèmes de traitement de base traitent les transactions qui génèrent des revenus. Quand ils échouent, les revenus s'arrêtent. AGuide d'évaluation des risques des CTOdocumente qu'une augmentation de 100 millisecondes de la latence des plateformes de commerce électronique peut réduire les taux de conversion de 7 %. Pour les systèmes traitant des milliers de transactions par heure, même une dégradation mineure entraîne un coût mesurable. Une panne complète est catastrophique.
La charge d'entretien aggrave le problème. Les organismes qui exploitent l'infrastructure de transaction existante dépensent jusqu'à 80 % de leur budget informatique pour maintenir les systèmes existants en service, ce qui laisse une capacité minimale pour de nouvelles capacités (Guide des risques hérités des CTO) . Ce n'est pas une plainte technologique. C'est un problème d'allocation de capital que le conseil d'administration peut voir au bilan.
Agilité compétitive
Chaque fonction que votre équipe d'ingénieurs ne peut pas construire parce qu'ils maintiennent le code de traitement des transactions vieux de 40 ans est une fonctionnalité que votre concurrent expédie d'abord. Selonle Guide des risques hérités des CTO, 62 % des organisations continuent d'exploiter des logiciels périmés malgré les risques connus. La principale raison du retard ? « Il fonctionne toujours » (cité par 50 % des organisations). Cette phrase est la phrase la plus chère dans l'informatique d'entreprise. Le système fonctionne jusqu'à ce qu'il ne fonctionne pas, et le coût de l'échec augmente chaque trimestre les retards de l'organisation.
Les données dont vous avez besoin avant d'entrer
Une présentation de tableau sans nombre dur est une conversation. Une présentation du conseil avec des nombres difficiles est une décision. Avant de demander une réunion, rassemblez ces six points de données :
| métrique | Pourquoi le conseil s'inquiète |
|---|---|
| Âge du système (années de production) | Établit l'échelle du passif. Les systèmes fédéraux signalés par le GAO vont de 23 à 59 ans. |
| Dernière date de changement majeur | Indique combien de temps le système a été en mode maintenance seulement. Aucun changement = personne ne veut le toucher. |
| Le personnel qui peut le maintenir | 71 % des équipes de l'ordinateur central manquent déjà de personnel. Si votre numéro est un seul chiffre, la carte doit le savoir. |
| Calendrier des départs à la retraite | L'AGO a constaté que certains experts qui maintenaient des systèmes fédéraux critiques étaient « à la retraite ou décédés ». Cartez votre propre chronologie. |
| Coût par incident (trois dernières années) | Convertit le risque abstrait en un chiffre en dollars que le DPF peut valider. |
| Coût estimatif des temps d ' arrêt par heure | Ancre la matrice de risque. Si le système traite 1,2 M$ par heure, une panne de 4 heures est de 4,8 M$. |
Si vous ne pouvez pas rassembler les six, commencez par ce que vous avez. Les données incomplètes présentées honnêtement sont plus crédibles que les estimations épurées. Le but est de faire passer la conversation de « nous pensons que c'est risqué » à « voilà ce que cela nous coûte ».
Que ne pas dire (et que dire à la place)
La langue que vous utilisez détermine si le conseil entend une demande de technologie ou un risque commercial. Chaque terme de la colonne de gauche déclenche le filtre de la carte "c'est un problème informatique". La colonne de droite recadre chaque concept dans un langage qui se connecte à la responsabilité, aux revenus et à la position concurrentielle.
| Au lieu de dire... | Dis ça. |
|---|---|
| "COBOL" | "Systèmes principaux de traitement des transactions (de 40 à 60 ans)" |
| Dette technique | «Responsabilité opérationnelle différée» |
| "Couverture d'essai unitaire" | "Détection des défaillances validées" |
| "État partagé" | "Interdépendances non documentées" |
| "Modernisation" | "Investissement de résilience opérationnelle" |
| "Refactoring" | "Réduire les points de défaillance" |
| "Migration de la légaté" | "Transition contrôlée vers une infrastructure soutenue" |
| "Code gel" | "Système qui ne peut accepter les changements en toute sécurité" |
| "Fin de vie" | "Operation au-delà de l'aide aux fournisseurs sans filet de sécurité" |
| Vitesse d'impression | "Vitesse de livraison du produit" |
Pratiquez ce vocabulaire avant la réunion. Une seule glissade dans le jargon donne au conseil l'autorisation de catégoriser votre demande comme « IT veut plus d'argent » plutôt que « l'entreprise a une responsabilité non couverte ».
La diapositive de la matrice de risque
Si votre présentation a une diapositive qui conduit à une décision, c'est elle. La matrice de risque trace chaque système de base sur deux axes : probabilité de défaillance (faible à élevé) et impact commercial en cas de défaillance (faible à catastrophique). Le résultat est une grille à quatre quadrants.
Comment marquer la probabilité d'échec. Attribuer à chaque système une note basée sur : l'âge de la base de codes, le nombre de personnes qui peuvent la maintenir, la fréquence des incidents récents et la vulnérabilité à la sécurité. L'AGO a constaté que 7 des 11 systèmes fédéraux critiques présentaient des vulnérabilités en matière de sécurité (FedGov aujourd'hui) . Si vos systèmes partagent ces caractéristiques, la probabilité n'est pas théorique.
Comment marquer l'impact des affaires. Utiliser le chiffre de recettes par heure pour chaque système. Coucher sur l'exposition à des amendes réglementaires, les coûts de notification des infractions et les estimations des dommages à la réputation. Un système qui traite la paye de 50 000 employés a un profil d'impact différent de celui d'un tableau de bord.
Ce qui atterrit dans le quadrant supérieur droit. Les systèmes à forte probabilité d'échec et d'impact catastrophique sur l'entreprise nécessitent une action immédiate. Ce sont les systèmes que le conseil doit d'abord financer. Tout le reste peut être séquencé dans des phases ultérieures. Ce quadrant est votre demande.
Présentez cette diapositive en couleur. Rouge pour le quadrant supérieur droit (action immédiate), jaune-auto pour les quadrants adjacents (action planifiée), vert pour les systèmes à faible probabilité/faible impact (moniteur). Les membres du conseil traitent intuitivement le risque visuel.
La matrice des risques visuels guide les priorités d'action du conseil.
Traitement des objections
Chaque conseil soulève les mêmes trois objections. Préparez-vous pour tous.
"Ça marche toujours."
C'est l'objection la plus courante et la plus dangereuse. Selon lesGuide des risques hérités des CTO, 50% des organisations retardent l'action parce que « le système fonctionne toujours ». La réponse: "Le système fonctionne, mais il ne peut pas être changé en toute sécurité, il ne peut pas être doté de personnel, et il ne peut pas être assuré contre l'échec. Un bâtiment avec une fondation fissurée est toujours debout. Cela ne signifie pas qu'il est sûr d'occuper."
Sauvegardez ceci avec vos données d'incident. Combien de quasi-passes au cours des 24 derniers mois ? Combien de temps la dernière panne imprévue a-t-elle duré ? Quelle était la cause profonde et a-t-elle été corrigée? Si les réponses sont inconfortables, elles sont exactement ce que le conseil doit entendre. En ce qui concerne le contexte de la crise de l'offre en matière de personnel à l'origine de ce risque, les données sur la main-d'œuvre sont sans ambiguïté.
"C'est trop cher."
Cette objection suppose que l'alternative aux dépenses est l'épargne. Ça ne l'est pas. La solution consiste à dépenser plus, lentement, sans réduire les risques. Les organisations consomment déjà jusqu'à 80 % de leurs budgets de TI pour la maintenance de l'héritage (Guide des risques hérités des CTO) . Les sept systèmes historiques essentiels non fixés du gouvernement fédéral américain consomment 337 millions de dollars par année en coûts opérationnels (FedScoop) .
Diriger l'investissement comme une réduction nette des coûts sur 3 à 5 ans, et non comme une dépense supplémentaire. Montrez à l'Office une comparaison : coûts d'entretien annuels actuels plus coûts d'incident projetés par rapport au coût amorti de l'investissement de résilience plus la réduction de l'entretien continu. Les chiffres favorisent presque toujours l'action.
"Nous avons essayé avant et avons échoué."
C'est une préoccupation légitime. Les données le confirment : 74 % des projets de modernisation de l'héritage sont lancés mais jamais achevés (Guide des risques hérités des CTO) . La réponse n'est pas de rejeter l'inquiétude, mais d'expliquer ce qui sera différent. Les échecs antérieurs ont généralement des causes communes : ils ont essayé de tout remplacer à la fois, ils n'avaient pas de parrainage exécutif, ou ils n'ont pas défini d'étapes mesurables.
Votre proposition porte sur les trois. La phase 1 ne vise que les systèmes à risque élevé (le quadrant supérieur droit). Le conseil lui-même assure la surveillance de la gouvernance au moyen d'examens trimestriels. Chaque étape a un résultat mesurable. Ce n'est pas une répétition des efforts du passé. C'est un investissement structuré et limité. Pour un aperçu technique de ce qu'une migration implique réellement, y compris l'approche progressive qui réduit le risque de livraison, voir notre guide technique.
Ce que vous demandez
N'entrez pas dans la salle de conférence pour demander « le budget pour réparer l'ancien code ». Ce cadre garantit le rejet. Au lieu de cela, cadrez la demande en trois parties:
- Réduction des risques. « Nous demandons un investissement de X $ pour réduire un passif opérationnel annuel actuellement estimé à Y $. Ce passif comprend les coûts prévus des temps d'arrêt, l'exposition aux amendes réglementaires, l'augmentation des dépenses d'entretien et le coût d'opportunité de la capacité d'ingénierie enfermée dans l'entretien antérieur.
- Déverrouillage des capacités. « Cet investissement libérera Z% de notre capacité d'ingénierie actuellement consommée par l'entretien ancien, nous permettant de fournir [des capacités ou des intégrations spécifiques de produits] qui sont actuellement bloqués. »
- L'analogie des primes d'assurance. Les conseils comprennent l'assurance. Vous n'achetez pas d'assurance incendie parce que votre immeuble est en feu. Vous l'achetez parce que le coût de la prime est une fraction du coût de la perte. Un investissement de résilience opérationnelle fonctionne de la même manière. L'investissement annuel est une fraction de l'exposition qu'il élimine. Si le conseil d'administration ne fonctionne pas sans assurance immobilière, il ne devrait pas fonctionner sans couverture de résilience pour les systèmes qui génèrent leurs revenus.
Soyez précis. « Nous demandons 2,4 millions de dollars sur 18 mois pour réduire le risque annuel de 12 millions de dollars et débloquer 3 millions de dollars en capacité de développement de produits » est une proposition qui peut être financée. "Nous devons moderniser nos systèmes" n'est pas.
Votre conseil n'a pas besoin de comprendre l'architecture. Ils doivent comprendre l'exposition. Donnez-leur les données, parlez leur langue et montrez-leur un chemin qui est échelonné, financé et mesurable. Le risque d'inaction n'est plus théorique. La seule question est de savoir si votre organisation s'en occupe selon son propre calendrier ou selon le calendrier dicté par la prochaine panne, la prochaine vérification ou la prochaine lettre de retraite.