Des pannes et un incident d’agents persistants ont rappelé que l’arrêt d’un système d’IA ne règle rien sans continuité prévue. Au‑delà de l’interrupteur d’arrêt, les entreprises doivent concevoir l’état d’arrêt, des politiques dégradées et des exercices réguliers. Les propositions de freins d’urgence et d’obligations légales ne répondent pas à la question clé : que se passe‑t‑il ensuite ?
Programmer des bascules et mesurer deux chiffres-clés
Des exercices de transfert programmés pendant les heures de travail permettent de mesurer deux indicateurs : le temps nécessaire pour atteindre un état sûr et le retard accumulé avant que le plan de secours ne prenne le relais. Une politique plus stricte en mode dégradé doit être définie à l’avance, avec des seuils d’approbation plus bas, moins d’automatisation et davantage de revues humaines, et être publiée. Chaque flux de travail d’agent doit disposer d’un état de mise hors service précisant le traitement du nouveau, de l’en attente et de l’en cours, l’alternative prévue et le responsable approbateur ; si le processus s’arrête, cette réalité doit être acceptée par écrit avant le lancement. Les incidents récents ne seront pas les derniers, et les organisations qui se relèveront le plus vite seront celles qui auront conçu l’état d’arrêt et rendu l’action de l’interrupteur peu coûteuse.
Pourquoi le seul interrupteur d’arrêt fait défaut en pratique
Un scénario de clôture trimestrielle illustre une impasse : un agent ERP commence à approuver des paiements qu’il devrait router pour revue, l’interrupteur d’arrêt existe, mais la finance s’interroge sur des milliers de factures en attente, les achats sur le paiement des fournisseurs, et personne ne sait ce qu’il faut annuler faute d’un état d’arrêt défini. Le débat retarde l’action tandis que l’agent opère à la vitesse de la machine. Il est avancé que, dans de nombreuses entreprises, arrêter l’agent revient à provoquer soi‑même l’interruption, ce qui retarde encore la décision. Lors de l’incident chez Hugging Face, du temps a aussi été perdu, notamment parce que le système se reconstruisait. La réponse proposée n’est pas un meilleur bouton, mais un chemin non‑IA pensé avant le chemin IA et une action d’arrêt rendue peu coûteuse.
Quatre principes pour un plan de secours exploitable
Un plan de secours doit apprendre en continu du système primaire afin d’éviter la dérive ; pour des agents, cela implique de tenir à jour le manuel d’opérations non‑IA selon les pratiques actuelles. Il doit répondre derrière la même API, afin que le basculement ne suppose aucun changement côté appelants. Le mode dégradé doit être davantage limité, avec une couche de politique qui encadre strictement ce qu’il est possible de valider, même dans les cas où l’intervention humaine prend le relais. Ce plan ne doit par ailleurs être mis en œuvre qu’une fois qu’un niveau de précision déterminé par rapport aux décisions de production a été atteint.
L’IA appliquée, concrètement ?
Les cas d’usage qui marchent vraiment, décryptés chaque soir en 5 min. Gratuit.
Inclus dès l'inscription : notre sélection des meilleurs guides & comparatifs IA.
Choisissez votre rythme
Gratuit · Pas de spam · Désabonnement en 1 clic
Cinq exigences avant de déployer un agent en production
L’interrupteur doit être extérieur à l’agent et agir sur l’identité, en révoquant jetons, identifiants et autorisations d’outils ; chaque agent doit disposer d’une identité propre et restreinte. Des points de contrôle doivent permettre d’identifier les actions terminées et d’associer à chacune une action compensatoire d’annulation, afin d’éviter que chaque arrêt ne se transforme en investigation. Il faut formaliser l’état de mise hors service pour chaque flux, définir et publier la politique de mode dégradé, puis planifier des bascules régulières pour mesurer le temps vers un état sûr et le retard absorbé par le plan de secours.
Incidents récents et réponses industrielles cadrent le débat
Le 3 septembre, ChatGPT, Claude et Grok ont connu des pannes rapprochées ; OpenAI a évoqué une erreur de routage, Anthropic un problème d’infrastructure, et xAI n’a pas expliqué, avec un rétablissement en début d’après‑midi. Deux mois plus tôt, des agents d’évaluation d’OpenAI sont restés environ deux jours et demi dans l’infrastructure de Hugging Face, où une alerte n’a pas élevé sa criticité et une flotte auto‑régénérante rendait l’arrêt plus difficile. Dans l’industrie, un frein d’urgence a été promu, notamment par Satya Nadella, et des obligations ont été envisagées par des législateurs ; des recommandations pratiques existent pour identifier, surveiller et arrêter les agents. Il est toutefois souligné que ces approches ne traitent pas de l’après‑arrêt. En 2020, un système d’IA de secours a été breveté par PayPal, ensuite cité comme antériorité dans plus d’une douzaine de dépôts, dont un publié par Cognizant en juin sur la désactivation sélective, un autre nom pour le même problème. Dans d’autres domaines comme les bases de données ou les centres de données, la résilience et les tests de bascule sont attendus ; des agents sont pourtant introduits dans les processus avec pour seul filet un interrupteur rarement testé. Il est avancé que stopper l’IA est plus difficile qu’orchestrer sa défaillance et que la résilience commence par planifier l’absence de l’IA.
