Une automatisation branchée sur un seul fournisseur d'IA s'arrête en même temps que lui : le plan de continuité prévoit le relais avant que la panne se propage.
Ce qui a changé récemment
Le 16 août 2026, une panne d'authentification a rendu claude.ai, Claude Code et Cowork inaccessibles une quarantaine de minutes, et l'API d'Anthropic a connu des performances dégradées. Quelques jours plus tôt, le 10 août, Anthropic avait renoncé à la hausse de prix prévue sur Claude Sonnet 5. Et OpenAI a annoncé en juin l'arrêt de plusieurs versions de GPT-5 et o3 pour le 11 décembre 2026.
Les quatre risques d'un fournisseur unique
La panne
Le 16 août 2026, vers 22 h UTC, l'authentification a commencé à échouer chez Anthropic. Pendant une quarantaine de minutes, claude.ai, Claude Code et l'application Cowork sont restés inaccessibles, et la page de statut d’Anthropic a aussi signalé des performances dégradées sur l'API et la console. BleepingComputer a relevé 42 minutes d'interruption. À l'échelle d'une soirée, l'incident est anecdotique. Ce qu'il révèle l'est moins : quand le fournisseur tombe, tout ce qui repose sur lui s’arrête.
Le prix
Les tarifs se décident chez le fournisseur. Claude Sonnet 5, lancé en juin 2026 à un prix d'introduction de 2 dollars le million de jetons en entrée, devait passer à 3 dollars le 1er septembre ; Anthropic y a renoncé le 10 août, selon ses notes de version. La tendance de fond reste à la baisse, comme le détaille notre analyse de ce que coûte vraiment l’IA à une entreprise, mais le prix d'un modèle précis peut aussi monter.
Le modèle retiré ou modifié
Les fournisseurs retirent régulièrement leurs anciens modèles. Le 14 avril 2026, Anthropic a annoncé l'arrêt de Claude Sonnet 4 et Claude Opus 4 pour le 15 juin ; le 11 juin, OpenAI a annoncé celui de plusieurs versions de GPT-5 et o3 pour le 11 décembre 2026. Après ces dates, les appels échouent. Un modèle peut aussi changer de règles : sur Claude Opus 4.7 et les modèles suivants, un réglage de température différent de la valeur par défaut renvoie une erreur, alors que des automatisations plus anciennes l'envoient encore.
Les conditions d'utilisation
Enfin, le fournisseur fixe les règles du jeu : quotas d'appels, régions d'hébergement, usages autorisés, durée de conservation des requêtes. Une modification de ces conditions peut suffire à bloquer un usage ou à poser une question de conformité, alors que votre automatisation, elle, reste identique.
Où la dépendance se cache dans une PME
La dépendance se cache loin des outils que l'on surveille : elle est dans les maillons invisibles. Un scénario d’automatisation dans n8n qui résume les e-mails entrants, un agent qui qualifie les demandes du support, un connecteur qui reformule des fiches produits : chacun appelle une API de modèle à chaque exécution. Si cet appel échoue et que rien n'est prévu, le scénario s'interrompt, parfois en silence, et le travail s'accumule en attendant que quelqu'un s'en aperçoive.
Erreur fréquente
Confondre « le service est revenu en 40 minutes » et « mon automatisation a tout rattrapé d'elle-même ». Beaucoup de scénarios ne rejouent pas les exécutions échouées : les messages de cette fenêtre restent en attente jusqu'à une reprise manuelle.
À quoi ressemble une automatisation résiliente
Quatre réflexes de conception
Un scénario bien conçu prévoit l’échec de l’appel au modèle. Un délai maximal et une nouvelle tentative automatique absorbent les micro-coupures. Un modèle de repli, chez un autre fournisseur, prend le relais quand le premier ne répond plus. Un mode dégradé permet de continuer sur la partie critique quitte à faire moins bien : mettre la demande en file, la router vers un humain, la marquer à retraiter. Enfin, une alerte prévient une personne quand le taux d'échec dépasse un seuil, pour éviter de découvrir le problème trois jours plus tard.
Le même incident, avec et sans garde-fous : ce qui se passe quand le fournisseur principal ne répond plus. Schéma Growth AI.
Le rôle de l'outil d'orchestration
C'est là que cette résilience se met en place concrètement. Dans un outil comme n8n, chaque étape peut avoir sa gestion d'erreur, sa nouvelle tentative, sa branche de secours vers un autre modèle et son scénario d'erreur qui notifie. La logique de repli se règle dans l’orchestrateur : ajouter un second fournisseur revient à modifier une seule branche de la chaîne. Le retrait d'un modèle se gère de la même façon, à un seul endroit, avec un test sur des cas réels avant la date d'arrêt. Chaque fournisseur ajouté apporte aussi une clé d'accès de plus, à protéger comme les autres accès de vos automatisations.
Ce que vous pouvez vérifier cette semaine
Listez vos scénarios qui appellent un modèle d'IA. Pour chacun, posez quatre questions : que se passe-t-il si l’appel échoue maintenant ? Quelqu'un est-il prévenu ? Les exécutions ratées sont-elles rejouées ou perdues ? Quel modèle précis est appelé, et quelle est sa date de retrait annoncée ? Les réponses suffisent souvent à repérer les deux ou trois scénarios à sécuriser en priorité, ceux dont l'arrêt se voit tout de suite côté client. Pour un inventaire complet, c'est l'un des livrables d'un audit et cadrage de vos scénarios existants.
CHECK-LIST
✓ Chaque appel au modèle a un délai et une relance.
✓ Les scénarios critiques ont un modèle de repli.
✓ Une alerte signale la hausse des échecs.
✓ La date de retrait de chaque modèle est suivie.
Pourquoi c'est un choix de dirigeant
Décider qu'un process peut tourner en mode dégradé, ou qu'il doit s'arrêter proprement pour éviter de produire des erreurs, c’est un arbitrage métier. Un devis automatisé tolère bien moins la panne qu'un résumé d'articles de veille. Éviter de se lier à un fournisseur unique relève de la même logique que garder son cost of change bas sur un outil : c'est une décision de dirigeant.
Ce que ça change pour votre PME
La panne du 16 août a été vite résolue. La prochaine, plus longue ou pendant un pic d'activité, peut coûter cher à qui n'a rien prévu, tout comme un modèle retiré ou un prix qui change. Rendre une automatisation résiliente revient à ajouter les bons garde-fous à l'existant, là où l'arrêt se verrait. Nouvelle tentative, repli, mode dégradé, alerte : ces garde-fous font partie de chaque automatisation sur mesure que nous concevons dès le départ.
