Panne d'assistant IA, projet bloqué : le 16 août, et ce qui reste chez vous

Le 16 août 2026, Claude Code est resté hors service quarante-deux minutes. Pour qui fait construire un logiciel par une équipe d'agents, la question qui suit vaut plus que l'incident : selon l'endroit où vivent vos documents et votre code, une panne chez un fournisseur vous prend une soirée ou tout votre chantier.

Panne d'assistant IA, projet bloqué : le 16 août 2026 à 21h58 UTC, Anthropic a confirmé un incident touchant Claude.ai, Claude Code et Claude Cowork, avec une dégradation signalée à 22h07 et un rétablissement complet à 22h40 (BleepingComputer, 16 août 2026). Quarante-deux minutes pendant lesquelles personne ne faisait écrire une ligne.

Ce qui s'est passé le 16 août

L'incident a commencé à 21h58 UTC. Neuf minutes plus tard, l'éditeur signalait des problèmes d'authentification puis des performances dégradées ; le rétablissement complet est arrivé à 22h40. La console d'administration et l'accès par clé restaient opérationnels d'après le même relevé, sans que l'article explique pourquoi. Quarante-deux minutes un soir d'août font peu de dégâts. La même interruption un mardi de livraison, ou trois heures au lieu de quarante minutes, pose une autre question, et cette question ne porte pas sur la fiabilité du fournisseur, que personne ne maîtrise, mais sur ce qui vous reste sous la main quand il tombe.

Le lendemain, GitHub tombait sept heures

Le 17 août 2026, GitHub restait indisponible 7 heures et 47 minutes : le site, l'authentification, les API, les tâches automatisées, les tickets et Copilot. L'éditeur a publié son analyse trois jours plus tard et écarte toute modification de code ou de configuration : la cause tenait à la capacité, sous une charge qui a fait passer les contributions mensuelles de 1,4 milliard en avril à 2,9 milliards. Deux pannes en deux jours, chez deux fournisseurs indépendants, sur les deux briques dont dépend une grande partie des projets logiciels du monde. Un dirigeant n'a aucune prise sur ces incidents. Il a une prise sur l'endroit où vivent ses fichiers.

Ce que vous perdez dépend de l'endroit où vit votre projet

Comparez deux situations. Vous construisez sur une plateforme en ligne qui héberge l'éditeur, le code, la base de données et l'adresse publique : quand le fournisseur tombe, vous ne pouvez plus travailler, ni relire ce que vous avez écrit hier, ni montrer le résultat à un associé, et votre application en service tombe avec lui. Vous travaillez sur une application installée sur votre Mac : l'assistant se tait, donc plus une ligne de code ne s'écrit, mais le cahier des charges validé, le découpage en étapes et l'historique des versions restent lisibles et modifiables sur votre disque. Dans le premier cas, la panne vous enlève le chantier. Dans le second, elle vous enlève l'ouvrier, et vous pouvez passer la soirée à relire ce que vous alliez faire construire.

Ce que Maestro ne peut pas faire non plus

Aucun outil ne fabrique du texte sans modèle. Maestro n'a pas de moteur à lui : il pilote Claude Code, Codex, Cursor ou Mistral Vibe, et quand le fournisseur choisi tombe, la construction s'arrête aussi. Sur ce terrain, un outil hébergé garde même un avantage réel. Votre application en ligne continue de servir vos clients si la panne ne touche que l'éditeur, alors qu'un projet posé sur votre Mac attend que quelqu'un le déploie quelque part, et cette étape reste à votre charge. La différence porte sur la matière que vous détenez, pas sur la disponibilité du moteur qui l'a produite.

Changer d'assistant sans changer de projet

Maestro laisse choisir entre quatre assistants et en changer au milieu d'une conversation, avec un abonnement ou une clé rangée dans le Trousseau de macOS (vos projets ne quittent pas votre machine). Le soir du 16 août, la manœuvre consistait à basculer vers un autre fournisseur et à reprendre l'étape en cours, puisque le brief, le cahier des charges et le découpage ne dépendent d'aucun d'eux : ce sont des documents en français, pas des réglages propres à un modèle. C'est le raisonnement que nous avons tenu pour un outil qui perd son moteur du jour au lendemain. Le critère de choix tient moins à la qualité du modèle du jour qu'à la facilité d'en changer sans rien perdre.

Pendant la panne, la seule chose à faire

Ouvrez le dossier de votre projet et regardez ce qui s'y trouve sans connexion : le brief, le cahier des charges, le découpage en étapes, le code, l'historique des versions. Ce que vous pouvez lire hors ligne est ce qui vous restera le jour d'une panne longue, et la liste se fait en dix minutes. Si elle revient vide parce que tout vit chez un éditeur, demandez-lui aujourd'hui par écrit comment sortir votre travail, et rangez la réponse avec vos contrats, comme nous l'avons décrit à propos de ce que devient une application quand l'outil disparaît. Une coupure de quarante minutes coûte une soirée : c'est le moment le moins cher pour découvrir ce que vous ne pourriez pas récupérer.