Des pannes majeures de l’IA entraînent l’adoption de règles de résilience

Les pannes majeures de l’IA suscitent des règles de résilience, car les organisations ne considèrent plus les modèles avancés comme de simples outils facultatifs de productivité. Lorsqu’un service d’IA soutient les opérations clients, le développement logiciel, l’analyse de la fraude, les activités de sécurité ou la surveillance d’infrastructures critiques, une perte de disponibilité peut interrompre de véritables processus métier. Début septembre 2026, la presse spécialisée a décrit une « triple panne de l’IA » comme un signal d’alarme et plaidé en faveur de procédures de secours, de stratégies multimodèles et de plans de continuité.

La réponse réglementaire va au-delà de la seule disponibilité. Les autorités européennes établissent des liens entre la disponibilité de l’IA, la cybersécurité, la continuité opérationnelle, la déclaration des incidents, le comportement des modèles et le risque systémique. Aux États-Unis, les législateurs et les entreprises d’IA débattent de mesures de protection contraignantes pour les systèmes hautement performants. En pratique, il ne s’agit plus de se demander si un modèle est impressionnant, mais si l’ensemble du service dépendant de l’IA peut tomber en panne sans danger, se rétablir de manière prévisible et rester soumis à une obligation de rendre des comptes lorsque les fournisseurs, les modèles, les intégrations ou les contrôles connaissent une défaillance.

Pourquoi les pannes répétées de l’IA ont modifié l’évaluation des risques

Une interruption isolée peut être traitée comme un incident technique. Des perturbations répétées soulèvent une autre question : l’organisation a-t-elle construit un processus critique autour d’un service qu’elle ne contrôle pas ? Cette question devient plus urgente lorsque le service est accessible par l’intermédiaire d’une interface de programmation d’application externe, intégré à un logiciel tiers ou dépendant d’un fournisseur de modèles de pointe.

Des commentaires et articles récents laissent entendre que les perturbations répétées des services d’IA font passer l’IA de la catégorie des « outils complémentaires de productivité » à celle des infrastructures opérationnelles. Cela ne signifie pas que chaque chatbot nécessite les mêmes contrôles qu’un réseau de paiement. Cela signifie que les mesures de résilience doivent refléter ce qui se produit si le composant d’IA devient indisponible, peu fiable, dangereux ou inaccessible à un moment critique.

La disponibilité n’est qu’un mode de défaillance parmi d’autres

La résilience de l’IA doit être envisagée sous un angle plus large que la disponibilité conventionnelle des services. Un point de terminaison de modèle peut répondre tout en produisant un comportement qui rend un processus inutilisable. Un fournisseur peut rester en ligne alors qu’une fonctionnalité dépendante, une couche de sécurité, un service de récupération d’informations, un système d’authentification ou une intégration régionale est défaillante.

La publication par OpenAI, le 17 septembre 2026, de six signalements concernant un comportement de modèle « inattendu ou préoccupant » renforce cette distinction. Ces signalements plaident en faveur d’une surveillance des incidents liés au comportement des modèles, en plus des pannes complètes de service. Une organisation peut donc être confrontée à plusieurs formes de perturbation :

• Indisponibilité du fournisseur : Le service de modèle externe est inaccessible ou ne peut pas traiter les demandes de manière fiable.
• Défaillance de l’application : Le modèle reste disponible, mais l’application d’entreprise, l’intégration, la couche d’identité ou la connexion aux données connaît une défaillance.
• Dégradation comportementale : Le modèle répond, mais ses résultats ne satisfont plus aux exigences de sécurité, de qualité ou de prévisibilité du processus.
• Perturbation de la sécurité : Les capacités ou les intégrations du modèle contribuent à un incident de sécurité opérationnelle.
• Défaillance des contrôles : La journalisation, le filtrage, la vérification, la remontée d’alerte ou d’autres mesures de protection cessent de fonctionner, même si le service principal semble opérationnel.

Cette définition élargie est importante pour la gouvernance. Une équipe qui ne surveille que la disponibilité des points de terminaison risque de ne pas détecter un incident au cours duquel les résultats deviennent impropres à l’utilisation. À l’inverse, une entreprise ne doit pas qualifier chaque réponse inexacte de panne systémique. Elle doit disposer de seuils documentés permettant de distinguer un défaut de qualité ordinaire d’un incident grave lié au service, à la sécurité ou à la sûreté.

La continuité de l’IA ne consiste pas simplement à pouvoir envoyer une nouvelle requête. Elle consiste à maintenir un résultat métier essentiel dans des limites opérationnelles et de sécurité acceptables lorsque le modèle privilégié ou ses contrôles sont indisponibles.

Ce principe conduit à une approche de conception plus pragmatique. Les organisations doivent cartographier l’ensemble de la chaîne de services, déterminer quelles dépendances peuvent interrompre le processus et décider à l’avance si la réponse sûre consiste à changer de fournisseur, à réduire les fonctionnalités, à revenir à un processus manuel, à mettre le travail en attente ou à suspendre l’activité.

L’UE passe de la sécurité des modèles à la résilience des systèmes

Le plan d’action de la Commission européenne de juillet 2026 sur la cybersécurité et l’IA marque une nette évolution réglementaire. Ce plan vise à aider les États membres, les entreprises et les autorités publiques à relever les défis de cybersécurité et de résilience posés par les modèles d’IA les plus avancés. Son orientation inscrit les risques liés aux modèles de pointe dans un programme plus large de résilience numérique, au lieu de les traiter uniquement comme des questions relevant des laboratoires d’évaluation des modèles.

La Commission indique que le plan complète le règlement sur l’IA, le règlement sur la cyberrésilience, la directive NIS 2, le règlement sur la résilience opérationnelle numérique et le règlement sur la cybersolidarité. Cet ensemble réglementaire est important, car les organisations vivent rarement un incident d’IA comme un « problème d’IA » parfaitement isolé. Un même événement peut concerner la gestion des fournisseurs, la sécurité logicielle, la continuité des services, les opérations critiques, les déclarations réglementaires et la coordination avec les autorités publiques.

Ce que cet ensemble réglementaire signifie en pratique

Les entreprises doivent résister à la tentation de créer un programme de gouvernance de l’IA fonctionnant séparément de la cybersécurité et de la continuité des activités. Une répartition distincte des responsabilités peut entraîner des évaluations redondantes, des classifications d’incidents contradictoires et des lacunes entre la supervision des modèles et la réponse opérationnelle.

Une structure plus résiliente relie les disciplines concernées :

• La gouvernance de l’IA recense les cas d’usage, les limites des modèles, les utilisations interdites, les conditions d’approbation et les exigences de supervision humaine.
• La cybersécurité examine les accès, les intégrations, l’exposition des données, les usages malveillants, les dépendances logicielles et la détection des menaces.
• Les équipes chargées de la résilience opérationnelle évaluent la criticité des services, les objectifs de rétablissement, les procédures de secours, le risque de concentration et les communications de crise.
• Les équipes chargées des achats et les équipes juridiques examinent les engagements des fournisseurs, les informations d’audit, le traitement des données, les notifications d’incidents, les sous-traitants et les possibilités de sortie.
• Les responsables métier déterminent si un processus dégradé ou manuel peut encore produire un résultat acceptable.

L’approche de l’UE souligne également la différence entre la résilience d’un modèle et celle d’une organisation qui utilise ce modèle. Un fournisseur peut améliorer les mesures de protection du modèle, la réponse aux incidents et la redondance de l’infrastructure. Le client doit néanmoins décider comment son propre service fonctionnera si le fournisseur est indisponible ou si l’accès doit être suspendu en raison d’un problème de sécurité ou de comportement.

Ce problème de responsabilité partagée devient plus aigu avec les modèles de pointe. Le client peut ne pas avoir de visibilité sur l’infrastructure sous-jacente du fournisseur, son processus d’entraînement, ses évaluations internes ou sa réponse à une capacité nouvellement découverte. De son côté, le fournisseur peut ignorer comment un client a intégré le modèle à un processus critique. Les contrôles de résilience doivent tenir compte de ce déficit d’information plutôt que de supposer qu’une seule partie peut gérer l’intégralité du risque.

La sécurité et la continuité convergent

Les discussions traditionnelles sur la sécurité de l’IA mettent souvent l’accent sur les capacités dangereuses, les usages abusifs, la perte de contrôle ou les résultats dangereux. La planification des pannes met l’accent sur la disponibilité, le rétablissement et la continuité. L’orientation réglementaire de 2026 montre pourquoi ces préoccupations se recoupent de plus en plus.

Il peut être nécessaire de restreindre ou de déconnecter un modèle après un incident de sécurité ou de cybersécurité. Un modèle de secours peut se comporter différemment du système principal. Des modifications d’urgence peuvent affaiblir les contrôles de vérification ou créer de nouveaux risques liés au traitement des données. Un plan de continuité qui rétablit les résultats sans rétablir les mesures de protection est donc incomplet.

La norme pratique doit être une continuité sûre, et non une continuité à tout prix. Si un cas d’usage ne peut pas fonctionner dans les limites approuvées en situation dégradée, une suspension peut être préférable à une solution de secours incontrôlée.

Le calendrier du règlement sur l’IA ouvre une période de planification de la résilience

La majorité des dispositions du règlement européen sur l’IA ont commencé à s’appliquer le 2 août 2026. Le paquet de simplification de l’UE a maintenu les dates d’application différée pour les règles relatives aux systèmes à haut risque : le 2 décembre 2027 et le 2 août 2028. Ces dates accordent aux entreprises concernées davantage de temps pour mettre en place des contrôles de résilience, mais elles ne doivent pas être interprétées comme une raison de reporter les travaux fondamentaux de continuité.

La mise en œuvre prend du temps, car le travail nécessaire va au-delà de la rédaction d’une politique. Une organisation peut devoir inventorier ses systèmes d’IA, classer leur incidence sur l’activité, renégocier les conditions des fournisseurs, améliorer les journaux, définir des seuils d’incident, créer des solutions de secours, former les employés et mener des exercices opérationnels. Les dépendances dissimulées dans les produits logiciels peuvent rendre cet inventaire particulièrement difficile.

Une séquence de préparation pratique

1. Recenser les services soutenus par l’IA. Documenter les intégrations directes de modèles ainsi que les fonctionnalités d’IA fournies par des logiciels d’entreprise. Consigner le fournisseur, le modèle, les connexions aux données, le responsable métier, les utilisateurs et les clients ou opérations concernés.
2. Évaluer la criticité. Déterminer l’effet opérationnel de la perte du composant d’IA pendant quelques minutes, quelques heures ou plus longtemps. Examiner si le processus a une incidence sur la santé, la sécurité, l’accès aux services financiers, les infrastructures, les droits juridiques ou d’autres résultats importants.
3. Cartographier les exigences applicables. Déterminer si le système peut faire l’objet d’un examen au titre des systèmes à haut risque et recenser les autres obligations pertinentes en matière de résilience, de cybersécurité ou propres au secteur. Les conclusions juridiques doivent reposer sur l’utilisation et le contexte réels, et non uniquement sur la qualification commerciale du fournisseur.
4. Définir les conditions de défaillance. Inclure l’indisponibilité, les réponses lentes, les résultats inutilisables, les défaillances des contrôles de sécurité, les identifiants compromis, les problèmes de connexion aux données et les restrictions imposées par le fournisseur.
5. Concevoir des modes de secours. Choisir des procédures manuelles, un traitement différé, des fonctionnalités réduites ou d’autres services techniques en fonction du risque associé à l’activité.
6. Tester et documenter. Mener des exercices, conserver les éléments de preuve, attribuer le pouvoir de décision et consigner les mesures correctives prises après chaque test ou incident réel.

Cette séquence aide également à distinguer les déclarations de conformité des preuves opérationnelles. Une déclaration écrite indiquant qu’un service dispose d’une solution de secours constitue une garantie limitée si celle-ci n’a pas été testée avec des données représentatives, une demande réaliste, des contrôles de sécurité approuvés et du personnel formé.

Les dates différées applicables aux systèmes à haut risque peuvent être mises à profit pour constituer méthodiquement ces preuves. Les entreprises peuvent commencer par leurs utilisations les plus lourdes de conséquences, tester un processus de bout en bout, puis étendre ce modèle de contrôle à d’autres systèmes. Cette approche est plus crédible que la création précipitée d’une politique générale peu avant une date limite d’application, sans vérifier si les équipes sont capables de la mettre en œuvre.

Les fonctions critiques font l’objet d’une attention accrue

Le service d’assistance relatif au règlement sur l’IA cite la surveillance des réseaux électriques, la prévention des pannes et d’autres fonctions critiques comme exemples dans lesquels les systèmes d’IA peuvent faire l’objet d’un examen au titre des systèmes à haut risque. Les orientations de l’UE sur la résilience publiées en 2026 indiquent également que les entités critiques qui utilisent l’IA dans le cadre de mesures de résilience doivent garder à l’esprit que les systèmes d’IA à haut risque doivent respecter les exigences de sécurité du règlement sur l’IA.

Cela crée un principe de contrôle important : une IA introduite pour améliorer la résilience peut elle-même devenir une dépendance en matière de résilience. Un modèle utilisé pour détecter des anomalies, hiérarchiser les opérations de maintenance ou prévenir une panne peut apporter une valeur opérationnelle, mais les opérateurs doivent tout de même prévoir les résultats incorrects, les réponses tardives, les pertes d’accès et les changements de comportement du modèle.

Pour les fonctions critiques, une dégradation progressive est souvent plus crédible qu’un remplacement instantané. Un mode de fonctionnement moins automatisé, doté d’une autorité humaine clairement définie, peut être plus sûr qu’un basculement automatique vers un modèle dont les performances, les intégrations ou les limites diffèrent de celles du système principal.

Les régulateurs financiers se concentrent sur la concentration des modèles de pointe et les risques liés aux TIC

Le 7 juillet 2026, le Comité européen du risque systémique a averti que les modèles d’IA de pointe modifiaient le paysage des cybermenaces pour le système financier de l’UE. Le CERS a appelé à une atténuation coordonnée des risques entre les fournisseurs, les éditeurs de logiciels, les équipes de sécurité et les autorités. L’accent mis sur la coordination reflète la manière dont les risques liés aux modèles peuvent franchir les frontières organisationnelles.

L’Autorité bancaire européenne, l’Autorité européenne des assurances et des pensions professionnelles et l’Autorité européenne des marchés financiers ont également appelé à un renforcement de la gouvernance et à une supervision cohérente afin de réduire les risques liés aux technologies de l’information et de la communication découlant des modèles d’IA de pointe dans le secteur financier de l’UE.

Pourquoi la coordination est importante

Un établissement financier peut gérer les contrôles de ses propres applications sans contrôler le modèle de pointe sur lequel celles-ci reposent. Un fournisseur de logiciels peut intégrer le même modèle à des produits utilisés par de nombreux établissements. Les équipes de sécurité peuvent observer des activités suspectes, tandis que les autorités de surveillance peuvent déceler des tendances plus générales qu’aucune entreprise ne pourrait repérer à partir de ses seuls incidents.

Cette structure soulève plusieurs questions opérationnelles auxquelles les entreprises réglementées doivent être prêtes à répondre :

• Quels services importants dépendent directement ou indirectement du même fournisseur de modèles ?
• Deux fournisseurs apparemment distincts pourraient-ils dépendre d’un même modèle ou d’une même couche d’infrastructure sous-jacente ?
• Quelles informations l’établissement recevrait-il si un fournisseur observait un comportement préoccupant du modèle ?
• L’établissement peut-il désactiver une fonctionnalité d’IA sans désactiver l’intégralité de l’application métier ?
• Qui peut autoriser le passage à un traitement manuel ou à un mode de service restreint ?
• Comment l’entreprise conservera-t-elle les documents nécessaires à un examen interne, aux échanges avec les autorités de surveillance ou à la déclaration d’un incident ?

Une affirmation générique selon laquelle un fournisseur dispose de centres de données redondants ne suffit pas à répondre à ces questions. La redondance de l’infrastructure peut être utile face à certaines pannes techniques, mais elle ne traite pas nécessairement la concentration autour d’un modèle commun, les restrictions de sécurité, les incidents comportementaux, les défauts logiciels ou le retrait d’urgence d’une capacité.

Une architecture multimodèle est utile, mais ne garantit pas automatiquement la résilience

Début septembre 2026, la presse spécialisée a recommandé des stratégies multimodèles comme réponse possible aux pannes majeures de l’IA. Cette approche peut réduire la dépendance envers un seul service, mais uniquement lorsque les solutions de remplacement sont suffisamment indépendantes et prêtes sur le plan opérationnel.

Deux interfaces de modèles peuvent en définitive dépendre du même composant infonuagique, du même mécanisme d’authentification, du même entrepôt de données, de la même couche d’orchestration ou du même fournisseur de logiciels. Même des modèles véritablement distincts peuvent avoir des exigences différentes en matière d’instructions, de formats de sortie, de limites de contexte, de comportement de sécurité et de caractéristiques d’intégration. Un basculement techniquement réussi peut malgré tout produire un résultat métier inacceptable.

Avant de qualifier un modèle secondaire de solution de secours, les équipes doivent valider son utilisation pour la tâche concernée. Elles doivent vérifier le traitement des résultats, les contrôles d’accès, les conditions de confidentialité, la journalisation, la vérification humaine et les conditions dans lesquelles le trafic peut être redirigé. Si ces contrôles ne peuvent pas être maintenus, un mode manuel ou à fonctionnalités réduites peut constituer une option de continuité plus sûre.

La déclaration des incidents devient un contrôle essentiel de la résilience

Le règlement européen sur l’IA exige de prêter attention aux incidents graves impliquant des modèles d’IA à usage général présentant un risque systémique. Si un tel modèle provoque un incident grave, le fournisseur doit en assurer le suivi et communiquer sans retard injustifié les informations pertinentes ainsi que les mesures correctives. La gestion des incidents devient ainsi plus qu’une simple pratique interne de fiabilité.

Une déclaration efficace dépend de la détection. Un fournisseur ne peut pas suivre un incident grave qui n’a jamais été identifié, et un client ne peut pas faire remonter un problème si les employés ne disposent d’aucun moyen de distinguer un événement grave d’une variation ordinaire du modèle. La surveillance doit donc relier les signaux techniques, les signalements des utilisateurs, les alertes de sécurité et les conséquences sur l’activité.

Constituer une seule piste de preuves, de la détection à la correction

Un dossier d’incident fiable doit aider les personnes chargées de l’examiner à comprendre ce qui s’est produit sans exagérer le degré de certitude. Le dossier peut inclure le modèle ou le service concerné, le comportement observé, la chronologie, le processus affecté, les journaux disponibles, les mesures immédiates d’endiguement, les conséquences sur l’activité, les notifications et les mesures correctives. Lorsque la cause est inconnue, le dossier doit l’indiquer plutôt que de remplacer l’incertitude par une supposition.

Les organisations peuvent structurer leur réponse autour des étapes suivantes :

1. Détecter : Recueillir les erreurs de service, les schémas de résultats inhabituels, les défaillances de contrôle, les préoccupations des utilisateurs, les signaux de sécurité et les notifications des fournisseurs.
2. Évaluer : Évaluer la gravité, l’étendue, les décisions concernées, l’exposition des données, les implications en matière de sécurité et la nécessité de maintenir ou non le système disponible.
3. Endiguer : Restreindre des fonctionnalités, révoquer des accès, isoler des intégrations, basculer vers une solution de secours approuvée ou suspendre le processus.
4. Faire remonter : Informer les responsables métier, de la sécurité, des affaires juridiques, de la conformité, des communications et de la direction conformément aux seuils documentés.
5. Préserver : Conserver les requêtes, les résultats, les événements système, les détails de configuration et les dossiers de décision pertinents, sous réserve des exigences de traitement applicables.
6. Corriger : Mettre en œuvre des changements techniques, procéduraux, contractuels ou de gouvernance et vérifier leur efficacité.
7. Tirer des enseignements : Actualiser les scénarios, la formation, les seuils, les évaluations des fournisseurs et les plans de continuité.

La publication par OpenAI de six signalements de comportements préoccupants le 17 septembre 2026 montre pourquoi des canaux de signalement des comportements inattendus des modèles sont nécessaires. Elle n’établit pas que chaque comportement signalé constituait une panne et ne supprime pas la nécessité d’évaluer chaque événement dans son contexte. Elle montre toutefois que les programmes de gestion des incidents doivent pouvoir recevoir et évaluer des préoccupations comportementales, et pas uniquement des alertes d’infrastructure.

Les déclarations des fournisseurs et des clients doivent être reliées

Les clients professionnels doivent savoir comment signaler au fournisseur un incident présumé lié au modèle et quelles informations celui-ci peut leur communiquer en retour. Les contrats et les procédures opérationnelles peuvent préciser les canaux de notification, les contacts chargés des remontées d’alerte, la conservation des preuves, les informations sur l’état du service et la coopération après un incident grave.

Les clients ont également besoin d’un canal de signalement interne qui reste disponible lorsque le service d’IA est en panne. Si les employés soumettent habituellement leurs demandes d’assistance par l’intermédiaire d’un outil assisté par l’IA dépendant du fournisseur concerné, le processus de signalement risque de tomber en panne au moment où il est le plus nécessaire. Des canaux indépendants de communication et de gestion des incidents réduisent cette dépendance circulaire.

Les bouleversements liés aux capacités relient la sécurité de l’IA à la sécurité opérationnelle

Les règles relatives aux pannes apparaissent parallèlement aux inquiétudes concernant la progression rapide des capacités des modèles. Axios a rapporté le 18 août 2026 qu’OpenAI réécrivait son cadre de préparation, car les modèles approchaient des seuils envisagés dans le document élaboré en 2023. Un cadre conçu à partir d’attentes antérieures peut devoir être révisé lorsque les capacités approchent de ses seuils de déclenchement initiaux.

Axios a également rapporté à la fin du mois de juillet 2026 que des modèles d’OpenAI avaient été associés à un autre piratage impliquant une entreprise externe. Cet épisode illustre la manière dont les évolutions des capacités peuvent contribuer à des incidents de sécurité en dehors d’un environnement de laboratoire contrôlé. Pour les équipes chargées de la résilience des entreprises, la leçon consiste à ne pas supposer que les risques liés aux modèles restent confinés à l’environnement d’évaluation du fournisseur.

La préparation doit couvrir les changements soudains

Les organisations gèrent généralement les logiciels selon des cycles de publication planifiés. L’IA de pointe peut compliquer ce schéma lorsque les fournisseurs mettent à jour les modèles, révisent les mesures de protection, retirent certaines versions, introduisent des fonctions agentiques ou découvrent une capacité qui modifie l’évaluation de la menace. Le processus du client peut être affecté même lorsque le code de sa propre application ne change pas.

Un processus pratique de gestion du changement doit examiner :

• si une mise à jour du modèle modifie l’utilisation approuvée, la classification des risques ou le niveau nécessaire de supervision humaine ;
• si de nouvelles capacités d’utilisation d’outils ou de fonctionnement agentique modifient l’accès aux données, aux logiciels ou aux systèmes externes ;
• si le retrait d’une version du modèle impose une migration accélérée ;
• si un comportement nouvellement observé nécessite des restrictions temporaires ;
• si la surveillance de la sécurité reste suffisante après une évolution des capacités ; et
• si les modèles de secours créent des risques sensiblement différents.

C’est à cet endroit que la gouvernance de la sécurité et la cyberrésilience se rejoignent. Un modèle plus puissant peut améliorer la détection, l’analyse et la réponse, mais cette même capacité peut modifier le potentiel d’utilisation abusive ou accroître les conséquences d’autorisations excessives. La planification de la résilience doit donc inclure la possibilité qu’une organisation désactive volontairement une fonctionnalité d’IA pourtant opérationnelle parce que le risque a changé.

Un service peut être techniquement disponible tout en étant indisponible sur le plan opérationnel s’il ne peut pas être utilisé dans les limites approuvées en matière de cybersécurité, de sécurité ou de gouvernance.

Cette distinction aide les dirigeants à prendre de meilleures décisions de suspension. Les équipes ne doivent pas se sentir obligées de continuer à utiliser un modèle simplement parce que le point de terminaison répond. Si la surveillance, les mesures de protection ou les garanties ne permettent plus de soutenir le cas d’usage, un retrait contrôlé constitue une action légitime de résilience.

Les propositions américaines témoignent d’un soutien croissant à des mesures de protection contraignantes pour l’IA de pointe

Les règles européennes sont actuellement plus développées en tant que structure réglementaire transversale, mais les États-Unis envisagent également des exigences plus strictes. Selon des informations de septembre 2026 rapportées par Reuters, OpenAI a exhorté les États-Unis à adopter des règles nationales obligatoires de sécurité de l’IA, fondées sur les capacités, après que des agents expérimentaux se sont comportés de manière imprévisible pendant des tests.

Des informations rapportées par Reuters et datées des 11 et 14 septembre 2026 indiquaient également que les négociateurs du Sénat envisageaient d’exiger des entreprises d’IA qu’elles atténuent les risques majeurs connus et s’engagent à prévenir les catastrophes. Ces discussions doivent être décrites avec exactitude comme des propositions et des négociations, et non comme des obligations adoptées.

Des règles fondées sur les capacités pourraient influer sur la planification opérationnelle

Une approche fondée sur les capacités porte l’attention sur ce qu’un système peut faire, plutôt que de s’appuyer uniquement sur sa marque, sa famille de modèles ou son objectif déclaré. Du point de vue de la résilience, cela pourrait rendre nécessaire une réévaluation lorsqu’un modèle mis à jour franchit un seuil de capacité pertinent ou accède à de nouveaux outils.

Les organisations qui utilisent des systèmes de pointe n’ont pas besoin d’attendre que chaque détail réglementaire soit fixé avant d’améliorer leurs contrôles. De nombreuses mesures utiles sont indépendantes de la réglementation : tenir un inventaire, limiter les autorisations, tester les procédures de secours, consigner les incidents, surveiller les changements chez les fournisseurs et désigner des décideurs responsables.

Dans le même temps, les entreprises doivent éviter de présenter des pratiques volontaires comme une preuve de conformité à des règles encore en discussion. Une gouvernance digne de confiance distingue le droit contraignant, les orientations réglementaires, les cadres des fournisseurs, les propositions législatives et les politiques internes. Chacun de ces éléments peut influencer la gestion des risques, mais ils n’ont pas le même statut juridique.

Une orientation transatlantique se dessine malgré les différences juridiques

Les évolutions de l’UE et le débat américain partagent une même préoccupation pratique : les modèles hautement performants peuvent avoir des conséquences qui dépassent un utilisateur ou une application. Les deux discussions mettent de plus en plus l’accent sur les risques majeurs connus, la réponse aux incidents, la gouvernance et la préparation aux conséquences graves.

Pour les organisations multinationales, un socle opérationnel commun peut être plus facile à gérer que des procédures régionales déconnectées. Ce socle peut prendre en charge des exigences locales plus strictes sans prétendre que les législations sont identiques. Il peut inclure un inventaire centralisé des modèles, un examen juridique local, une coordination mondiale des incidents, des modes de secours testés et un pouvoir clairement défini de restreindre un système.

Comment les entreprises peuvent mettre en place dès maintenant un programme de continuité de l’IA

Un programme crédible de continuité de l’IA commence par les résultats métier, et non par les noms des fournisseurs. La première question consiste à déterminer quel service doit être maintenu, à quel niveau et sous quelles contraintes de sécurité. Ce n’est qu’ensuite que l’organisation doit décider si la redondance, le traitement manuel, le report du travail ou la suspension constitue la solution appropriée.

Établir les priorités en fonction des conséquences

Tous les cas d’usage ne nécessitent pas une redondance technique coûteuse. Un assistant de rédaction destiné à des documents internes non urgents peut tolérer une longue interruption. Un composant d’IA impliqué dans une décision opérationnelle critique peut nécessiter une détection rapide, une autorité humaine documentée et un mode dégradé testé.

La hiérarchisation doit tenir compte aussi bien du préjudice causé par l’absence du service que de celui causé par une réponse incorrecte ou dangereuse. Cela évite une erreur fréquente : optimiser la disponibilité pour un processus dans lequel une solution de remplacement incontrôlée serait plus dangereuse que l’attente.

Définir des conditions explicites de recours aux solutions de secours

Les décisions de basculement ne doivent pas dépendre entièrement de l’improvisation pendant un incident. Les équipes peuvent définir des déclencheurs pour changer de fournisseur, passer à une vérification manuelle, réduire l’automatisation, mettre les demandes en attente ou suspendre complètement le service. Les déclencheurs peuvent inclure une indisponibilité prolongée, la défaillance d’un contrôle de sécurité, une alerte de sécurité, une dégradation inexpliquée des résultats ou la perte de la journalisation requise.

Pour chaque mode, il faut documenter qui peut l’activer, comment les utilisateurs sont informés, quelles données peuvent être traitées, quelles approbations restent nécessaires et comment le service normal est rétabli. Une solution de secours doit également comporter une condition de sortie ; les processus d’urgence temporaires peuvent créer des risques durables s’ils restent actifs sans réexamen.

Tester des scénarios réalistes

Les exercices doivent aller au-delà d’une panne franche annoncée sur une page publique d’état des services. Les incidents réels peuvent être ambigus. Les réponses peuvent être lentes plutôt qu’absentes, une seule fonctionnalité peut tomber en panne ou des utilisateurs peuvent signaler un comportement préoccupant avant que le fournisseur ne confirme le problème.

• Simuler la perte du modèle principal au plus fort de l’activité.
• Vérifier si le service de remplacement peut prendre en charge la tâche requise et les données approuvées.
• S’entraîner à fonctionner sans IA tout en conservant les documents et les approbations essentiels.
• Exécuter un scénario dans lequel le modèle fonctionne, mais où un contrôle de sécurité ou de journalisation est défaillant.
• Simuler une notification de sécurité du fournisseur exigeant la restriction immédiate d’une fonctionnalité.
• Vérifier que les communications destinées aux clients, aux employés, aux régulateurs et aux dirigeants peuvent se poursuivre sans l’outil d’IA concerné.

Les exercices doivent déboucher sur des mesures correctives, des responsables désignés et des preuves d’exécution. Un test qui révèle une faiblesse est utile ; un test dont les conclusions ne font jamais l’objet d’un suivi ne crée qu’une apparence de préparation.

Exiger des fournisseurs des informations utiles à la prise de décision

Les examens menés dans le cadre des achats doivent se concentrer sur les informations permettant de prendre des décisions de continuité. Les sujets pertinents comprennent les dépendances des services, les processus de notification des incidents, les pratiques de modification des modèles, le retrait des versions, l’accès aux informations sur l’état des services, la portabilité des données, la journalisation, la coopération en matière de sécurité et l’assistance à la résiliation.

Aucun contrat ne peut éliminer une panne majeure d’un fournisseur ou un comportement inattendu d’un modèle. Les dispositions contractuelles peuvent toutefois clarifier les communications et les responsabilités. Elles peuvent également révéler les situations dans lesquelles le client ne dispose pas des informations ou des droits nécessaires pour exploiter en toute sécurité un cas d’usage lourd de conséquences.

Maintenir les capacités humaines nécessaires aux opérations dégradées

Une solution de secours manuelle n’existe que si les personnes conservent les connaissances, les accès, les capacités et l’autorité nécessaires pour la mettre en œuvre. À mesure que les équipes automatisent davantage de tâches, ces capacités peuvent s’affaiblir. Des exercices périodiques permettent de déterminer si le processus manuel prévu reste viable.

La supervision humaine doit également être précise. Demander à un employé de « vérifier le résultat » ne suffit pas pour un processus lourd de conséquences, sauf si cette personne sait ce qu’elle doit contrôler, possède l’expertise nécessaire, peut accéder aux informations justificatives et a le pouvoir de rejeter ou d’arrêter le processus.

Enfin, les rapports destinés à la direction doivent associer fiabilité et risque. Des rapports utiles peuvent décrire les dépendances critiques à l’IA, les points uniques de défaillance non résolus, les incidents récents, les conclusions des exercices, les mesures correctives en retard et les évolutions à venir des modèles ou de la réglementation. Ils offrent aux dirigeants une base d’investissement plus claire qu’un simple taux de disponibilité.

Les pannes majeures de l’IA suscitent des règles de résilience, car les enjeux opérationnels sont devenus visibles. Le plan de l’UE de juillet 2026 sur la cybersécurité et l’IA, le calendrier du règlement sur l’IA, les orientations relatives aux entités critiques, les avertissements du secteur financier et les exigences de déclaration des incidents graves indiquent tous une évolution vers une supervision intégrée des modèles, de la cybersécurité et de la continuité. Les discussions américaines sur des mesures de protection obligatoires fondées sur les capacités et sur l’atténuation des risques catastrophiques renforcent cette évolution générale vers une responsabilité plus formelle, même si ces propositions ne doivent pas être confondues avec des lois adoptées.

Les organisations peuvent réagir sans exagérer ni la technologie ni la réglementation. Elles doivent recenser les dépendances lourdes de conséquences, définir des modes dégradés sûrs, tester des solutions de secours indépendantes, surveiller les incidents comportementaux et de sécurité, conserver les preuves et relier la gouvernance de l’IA aux fonctions de résilience existantes. L’objectif n’est pas de maintenir l’IA sans interruption à tout prix, mais de disposer d’un service métier fiable, capable de tomber en panne sans danger, de se rétablir de manière contrôlée et de démontrer ce qui a été fait avant, pendant et après un incident.