Les points de défaillance uniques échouent. La couche SaaS ne fait pas exception

L’enseignement supérieur a regroupé l’ensemble de ses opérations académiques dans une poignée de plateformes SaaS massives. Le LMS gère l’enseignement, la notation et la communication. Le SIS est propriétaire des inscriptions, des dossiers et de l’aide financière. L’identité et la productivité résident dans un petit nombre de fournisseurs de cloud. Ce ne sont pas des outils périphériques : ils constituent l’infrastructure opérationnelle de l’institution. En tant que gestionnaires informatiques, nous gérons des plates-formes que nous ne possédons pas, que nous ne pouvons pas restaurer nous-mêmes et que nous ne pouvons pas contrôler directement, ce qui rend la planification d’urgence non facultative, mais fondamentale à notre rôle.

Les contrats sont en place. Les SLA sont signés. Les certifications de conformité sont à jour. Rien de tout cela n’a d’importance pour un étudiant qui ne peut pas joindre son professeur trois jours avant les examens. Rien de tout cela n’a d’importance pour un membre du corps professoral qui n’a pas de liste, pas de carnet de notes et aucun moyen de documenter les travaux soumis par ses étudiants avant que la plateforme ne s’éteigne. Les SLA régissent les délais de réponse des fournisseurs. Il est de la responsabilité du service informatique de maintenir les opérations académiques en cours pendant cette fenêtre de réponse.

La perturbation a frappé au cours de la semaine des examens 2026, et je faisais ce que faisait tous les DSI de l’enseignement supérieur : la surveillance. Un important système de gestion de l’apprentissage avait été piraté. La perturbation s’est propagée rapidement. Les finales ont été annulées. Les examens ont été reportés. Les étudiants et le personnel se sont retrouvés bloqués sans accès aux cours, aux listes ou aux cahiers de notes. Les coûts – en perturbations académiques, contrats prolongés, interventions d’urgence – ont été considérables et largement signalés. Mon institution n’a pas été directement impactée. Mais voir les institutions homologues de mon propre État s’éteindre au moment où les enjeux sont les plus élevés du calendrier universitaire n’était pas rassurant. C’était la confirmation de quelque chose auquel je pensais depuis longtemps.

Cette perturbation a prouvé que les professionnels de l’informatique ont réappris au cours de chaque décennie de leur carrière. Mark Twain a observé que l’histoire ne se répète pas, mais qu’elle rime. C’est un verset que nous avons déjà entendu : la dépendance à un point de défaillance unique, sans un plan d’urgence testé, n’est pas une stratégie – c’est un risque qui n’a tout simplement pas encore été identifié. Que la panne provienne d’une cyberattaque, d’une panne d’un fournisseur, d’un effondrement de l’infrastructure ou d’un mauvais déploiement d’un fournisseur cloud, le résultat est le même. L’institution s’arrête. Et aucun SLA, contrat ou certification de conformité n’empêche ce moment d’arriver.

La vigilance n’est pas facultative. Les technologies évoluent plus rapidement qu’aucune équipe informatique ne peut l’anticiper. De nouvelles plates-formes, de nouvelles intégrations, de nouvelles dépendances émergent constamment – ​​et chacune d’elles entraîne un nouveau point de défaillance potentiel. Ce n’est pas un argument contre l’adoption de nouvelles technologies. C’est un argument en faveur d’un principe qui ne devient jamais obsolète : le recours à un seul système critique, qu’il s’agisse d’un fournisseur de connectivité, d’une plateforme d’identité ou d’une solution SaaS, est une stratégie d’échec éprouvée. La question n’est jamais de savoir si ce système échouera. La question est de savoir si l’institution est prête à le faire.

Les points de défaillance uniques échouent – ​​inévitablement et au pire moment possible. Les professionnels de l’informatique le savent depuis trente ans. La couche SaaS n’est pas exemptée.

Ce n’est pas une nouvelle leçon. Azure est en panne. AWS a échoué. Google Workspace a connu des pannes qui ont plongé les organisations dans le noir à l’échelle mondiale. Aucun campus ne gère une seule connexion FAI : nous fournissons des circuits redondants, de préférence auprès de fournisseurs indépendants, car nous avons appris depuis longtemps que la connexion échoue parfois et que l’établissement ne peut pas se permettre de s’arrêter lorsque cela se produit. Les services financiers, les gouvernements et les entreprises multinationales ont appliqué la même logique à chaque dépendance de leur pile. Leur réponse au risque lié à la plateforme n’a pas été d’exiger de meilleurs SLA. Il s’agissait d’architecter autour de la dépendance. Redondance. Basculement. Capacité de continuité indépendante. Les perturbations massives causées par Canvas démontrent que les solutions d’urgence efficaces pour ces plates-formes critiques n’ont pas suivi le rythme de notre dépendance à leur égard. Nous ne pouvons plus nous laisser berner.

C’est cette omission qui a rendu l’attaque de 2026 si dommageable. Il ne s’agit pas de la sophistication de la faille : le point d’entrée était un environnement périphérique libre qui n’entrait même pas dans le cadre de certification principal du fournisseur. Les dégâts ont été catastrophiques car les institutions n’avaient aucun recours. Les professeurs n’avaient pas de listes. Les administrateurs ne disposaient d’aucune donnée d’inscription. Il n’y avait pas de couche de continuité. Un point de défaillance unique, à l’échelle institutionnelle, sans aucun plan en cas de défaillance.

Et maintenant, la situation économique a évolué dans la pire direction possible. PowerSchool a payé une rançon en décembre 2024 après que des attaquants ont volé des données sur 60 millions d’élèves – et a quand même été de nouveau extorquée, chaque district scolaire recevant des demandes distinctes des mois plus tard en utilisant les mêmes données volées. Le PDG d’Instructure a publiquement confirmé le paiement de l’extorsion. Quiconque a payé une rançon pour ensuite être frappé une seconde fois au double du prix peut vous le dire : payer les attaquants ne résout rien et invite à de nouvelles attaques. Le secteur a désormais prouvé à deux reprises, publiquement et à grande échelle, qu’il paierait. Cela change complètement le calcul de la menace. L’enseignement supérieur cesse d’être une cible d’opportunités et devient une cible de stratégie. Les groupes criminels partagent ces renseignements. Banner dessert plus de 1 400 institutions. Blackboard touche des dizaines de millions d’utilisateurs sur des milliers de campus. Toutes les grandes plateformes SaaS d’enseignement supérieur figurent désormais sur la liste des priorités actives des acteurs de la menace – non pas parce qu’elles sont nouvellement vulnérables, mais parce que le secteur a prouvé qu’il paierait, que la pression du calendrier universitaire crée un effet de levier maximal et que l’informatique n’a pas encore construit l’alternative opérationnelle qu’exige notre dépendance à l’égard de ces plateformes – et par conséquent, l’échec nous appartient, surtout si nous permettons que cela se produise une seconde fois.

Le secteur a prouvé qu’il paierait. Tous les groupes de ransomwares en activité aujourd’hui viennent de recevoir le même signal du marché. Ce qui suit n’est pas imprévisible : il est documenté, en cours et destiné directement aux plateformes portant les opérations académiques de votre établissement.

En tant que DSI, mon approche ne consiste pas à utiliser une feuille de calcul ou une pile de rapports imprimés. Le service informatique est chargé d’identifier les points de défaillance critiques et de les contrer – ce n’est pas facultatif ; c’est le travail. Accepter l’échec comme inévitable sans une stratégie d’atténuation n’est pas viable. Les solutions de redondance et de continuité sont une pratique courante partout ailleurs dans notre infrastructure. Il n’y avait aucune raison pour que la couche SaaS soit différente.

Le premier travail d’un leader n’est pas d’avoir raison, c’est d’être responsable.

La solution que j’ai mise en œuvre est un référentiel sécurisé, en lecture seule et centralisé – une stratégie de continuité qui garantit que les étudiants, le personnel et les professeurs peuvent continuer à fonctionner, qu’il s’agisse d’une panne de courant, d’une cyberattaque ou d’une plate-forme SaaS qui s’éteint. Il ne remplace pas Canvas ou Banner. C’est le repli indépendant qui permet à l’institution de continuer à fonctionner pendant que le système primaire est rétabli. J’ai appris à mes dépens qu’accepter l’échec sans plan n’est pas une posture qu’un DSI ne peut défendre.

En voyant la frustration au sein du secteur pendant et après l’attaque de 2026 – institutions paralysées, collègues DSI improvisant, professeurs travaillant à partir de feuilles de calcul personnelles, conseils d’administration posant des questions auxquelles personne ne pouvait répondre – la logique d’étendre cette capacité à d’autres institutions est devenue inévitable. La solution n’est pas complexe. L’architecture est simple. La discipline derrière cela a trente ans. La discipline est établie. La responsabilité de l’appliquer est notre domaine d’expertise en informatique.

Pour être précis sur la portée : un ACR n’empêche pas les violations des fournisseurs, ne remplace pas la cyber-assurance et ne supprime pas les obligations de notification. Lorsqu’un incident survient, les conseillers juridiques, les équipes de sécurité et les dirigeants institutionnels continuent de gérer la réponse. Ce que l’ACR change, c’est ce avec quoi ils doivent travailler : un enregistrement régi et vérifiable des données consultées, des actions manuelles entreprises et de la manière dont les opérations se sont poursuivies pendant que le fournisseur s’efforçait de restaurer le service.

Redondance, reprise après sinistre, continuité des opérations : la discipline n’est pas nouvelle. Les plates-formes SaaS portant sur des opérations académiques méritent le même niveau de qualité que celui que nous appliquons partout ailleurs.

La solution à ce problème existe. Une stratégie de continuité des opérations SaaS tierce nécessite une couche de données indépendante – une couche de données contrôlée par l’institution, synchronisée selon un cycle planifié régulier à partir des systèmes sources et accessible lorsque ces systèmes ne le sont pas. Indépendant de la plate-forme sur Canvas, Banner, Blackboard et PowerSchool. Lecture seule par conception. Auditable par exigence. Indépendant par l’architecture. Ce dernier mot est celui qui compte, indépendamment des plateformes dont vous ne pouvez garantir la disponibilité.

Chaque DSI de l’enseignement supérieur sait à quoi ressemble un point de défaillance unique. Chacun d’entre nous a construit autour d’eux à chaque autre niveau. Serveurs, réseaux, centres de données : nous n’acceptons pas le risque ponctuel et nous n’attendons pas l’échec pour justifier une solution. La couche SaaS ne fait pas exception.

La question n’est pas de savoir si votre institution y fera face. La question est de savoir si vous aurez mis en place une stratégie de continuité lorsqu’elle sera mise en place – ou si vous expliquerez à votre conseil d’administration pourquoi vous ne l’avez pas fait.

Les dirigeants ne louent pas la responsabilité : ils la possèdent entièrement.

Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?