Résumé

  • Dans son audit du 28 octobre 2026, l’inspecteur général constate que le Conseil des gouverneurs de la Réserve fédérale teste périodiquement ses plans de continuité et conserve des plans par division, mais n’a pas établi de plans de reprise informatique complets pour chaque système.
  • Les analyses d’impact sur l’activité relèvent du service Intelligence, Insider Risk, and National Security Programs; la préparation technique dépend de la Division of IT. Aucune politique commune ne fixe leur coordination ou leur calendrier de mise à jour. La plupart des analyses d’impact datent de 2023 ou d’avant.
  • Le programme de sécurité du Conseil atteint le niveau 2 sur 5 selon la méthode fédérale, sous le niveau 4 jugé efficace. Une modification de la méthode de notation et l’ajout du domaine gouvernance compliquent la comparaison historique. Treize recommandations antérieures sur dix-sept restent ouvertes; huit nouvelles ont été acceptées.

Deux dossiers, un système à redémarrer

Le rapport officiel de l’inspecteur général du 28 octobre 2026 porte sur le Conseil des gouverneurs, une agence qui utilise des données financières et de supervision sensibles. Il ne mesure pas l’état de toutes les banques fédérales de réserve. Son constat le plus concret concerne la reprise après interruption. Le Conseil procède à des tests de continuité semestriels et garde des plans de continuité pour ses divisions. Il n’a pas rédigé les plans complets exigés pour chacun de ses systèmes d’information.

Une division peut déclarer qu’une fonction doit revenir rapidement. Encore faut-il dire quel système la porte, quel état des données restaurer, quelle solution de remplacement utiliser, quelles étapes techniques suivre et comment éprouver le résultat. L’audit énumère précisément ces éléments manquants: procédures de reprise détaillées, priorités par système, objectifs de point de reprise, traitement alternatif, exigences de test et activités de restauration. Un responsable a expliqué que les informations utiles figuraient dans les plans de sécurité des systèmes.

Les auditeurs y ont trouvé une description insuffisante des opérations de reprise propres à chaque système.

Le Conseil n’est donc pas immobile. Il teste et il documente. Mais une répétition à l’échelle d’une division n’inscrit pas automatiquement dans le dossier technique la séquence qui remet une application en marche. Une interruption oblige à choisir vite le service prioritaire et le point auquel ses données peuvent être ramenées. Une case «plan existant» n’effectue aucun de ces choix à la place d’une équipe de nuit.

L’urgence métier et l’ordre technique vivent séparément

L’architecture des responsabilités explique le trou. Le service chargé du renseignement, du risque interne et des programmes de sécurité nationale, IINS, produit les analyses d’impact sur l’activité et de processus et dirige la continuité. La Division of IT prépare les mesures techniques. L’inspecteur général n’a pas trouvé de politique qui fixe leur dialogue, la personne responsable de rapprocher les priorités, ni la fréquence à laquelle les dossiers doivent être revus ensemble.

Cette absence a une date. La plupart des analyses d’impact n’avaient pas été mises à jour depuis 2023 ou avant; plus de la moitié des analyses de processus dataient de 2024 ou avant. Plusieurs mises à jour des processus en 2025 n’avaient pas été répercutées dans les analyses d’impact correspondantes. Les deux services peuvent ainsi travailler sérieusement sur des versions différentes de la même activité. Une priorité métier ancienne peut orienter un exercice récent; une priorité nouvelle peut concerner un système dont la procédure de restauration reste générale.

L’inspecteur général en tire une conclusion opérationnelle: le Conseil dispose d’une assurance limitée quant à la reprise régulière et rapide de ses systèmes critiques lors d’une perturbation. Il décrit un risque et des documents qui ne s’accordent pas, pas la panne d’un système nommé. Le coût immédiat de la gouvernance dispersée est de reporter la négociation entre métiers et informatique au moment où le temps manquera le plus.

Même la liste des systèmes complique la conversation. L’inventaire ne renseigne pas 10 des 32 champs requis par la propre norme du Conseil, notamment le type d’information, le périmètre d’autorisation, le responsable du système et le type de service cloud. Certains systèmes contenant des données personnelles ou assurant des fonctions essentielles sont mal classés; d’autres, présents dans un outil de conformité distinct, manquent à l’inventaire. Il s’agit de dix champs absents, pas de dix systèmes disparus. Une reprise ordonnée commence par une liste exacte de ce qu’il faut remettre en service.

Le niveau 2 ne remplace pas la preuve de reprise

La synthèse officielle de l’audit attribue au programme de sécurité du Conseil le niveau de maturité 2 sur 5: les règles sont définies mais leur application n’est pas constante. La référence fédérale situe l’efficacité au niveau 4, lorsque les contrôles sont gérés et mesurés. Les résultats précédents étaient 4 en 2024 et 3 en 2025. Cette suite ne forme pourtant pas une mesure simple de dégradation. La notation est passée de la valeur la plus fréquente à une moyenne calculée, la gouvernance est devenue un domaine évalué à part et de nouvelles faiblesses ont été relevées. Le résultat actuel est clair; l’interprétation mécanique de la pente ne l’est pas.

Treize des dix-sept recommandations héritées des audits annuels précédents demeurent ouvertes; quatre sont closes après des actions du Conseil. Le rapport ajoute huit recommandations. Elles couvrent la gouvernance informatique, l’inventaire, les exceptions à l’authentification, les vulnérabilités, la surveillance, la continuité et les clauses des prestataires cloud. Le directeur informatique et le directeur financier du Conseil ont approuvé les constats et annoncé des mesures. Une réponse écrite assigne du travail; elle ne restaure encore aucun système.

Une recommandation vise le raccordement manquant: faire coordonner par IINS et l’informatique les analyses métier et les plans techniques, puis exiger des plans de secours pour chaque système. Le reçu décisif serait un ensemble daté d’analyses concordantes, d’un inventaire avec responsables et d’étapes de restauration testées. Le Conseil dispose déjà d’outils de sécurité et d’un calendrier d’exercices. L’audit dit ce qu’il faut désormais relier à ces acquis: le nom de la fonction, le nom du système et l’ordre pour le récupérer.

Sources