Panne de Claude Code : Codex prend le relais
Mes règles, ma mémoire et mes verrous sont des fichiers texte. Codex les lit comme Claude Code, et peut reprendre le travail quand l’un des deux s’arrête.
Le 13 novembre 2026, Claude a connu deux incidents dans la même journée. Le matin, de 10 h 58 à 12 h 58, heure de Paris, la connexion à claude.ai et à Claude Code était en panne. L’après-midi, de 14 h 09 à 16 h 38, claude.ai, l’API et Claude Code ont renvoyé des erreurs. Cela fait quatre heures et demie, en pleine journée de travail.
Chez moi, Claude Code m’a demandé deux fois de me reconnecter dans la matinée, avec une erreur 403. Mes sessions déjà ouvertes ont continué à répondre, et je n’ai pas eu à changer d’outil. Je me suis quand même posé la question : si Claude Code s’arrête une journée entière, qu’est-ce qui s’arrête avec lui ?
Peu de choses. L’essentiel de mon harnais est rangé dans des fichiers texte, à côté de l’outil. Claude Code est celui que j’utilise le plus. Codex, l’outil d’OpenAI, lit les mêmes fichiers et peut reprendre le travail.
Ce qui s’arrête avec un outil
Prenez quelqu’un qui a tout construit dans une seule application : ses consignes sont dans les réglages, ses habitudes dans l’historique des conversations, ses automatisations dans les tâches planifiées de l’application. Pendant une panne, il peut ouvrir un autre outil. Mais cet outil ne connaît ni ses règles, ni ses projets, ni ce qu’il ne doit jamais faire.
Le 13 novembre, la page de statut signalait aussi que des tâches planifiées hébergées chez Claude partaient avec plus de deux heures de retard, et que certaines avaient été sautées.
Le socle commun
Lors de la dernière revue de mon système, tout ce qui compte a été sorti des outils et mis dans des dossiers que les deux savent lire.
Les règles : un seul fichier
Mes règles globales sont dans un fichier AGENTS.md, un format ouvert que Codex lit directement. Claude Code le lit par un lien symbolique : c’est le même fichier sous un deuxième nom, et je le modifie à un seul endroit. Chaque projet a aussi le sien. Quand un projet n’a que le fichier propre à Claude Code, une ligne de réglage demande à Codex de lire celui-là.
~/.claude/rules/shared.md → ~/.codex/AGENTS.md
project_doc_fallback_filenames = ["CLAUDE.md"]J’en ai la trace. Le 13 novembre à 15 h 17, pendant le second incident, Codex relisait trois guides d’un de mes sites. Son journal commence par mes règles, dans l’ordre : l’interdiction de contacter certaines entreprises, les règles communes aux deux outils, puis celles du projet.
La mémoire : un dossier de notes
La mémoire est un dossier d’une cinquantaine de notes courtes, avec un index d’une ligne par note. Les deux outils lisent l’index et peuvent ajouter une note, dans le même format.
Les skills : une source, des liens
Chaque skill a une seule source. Celles qui servent aux deux outils, quatre pour l’instant, sont reliées au dossier de Codex par un lien symbolique.
Les verrous : le même script
Le script qui bloque un e-mail destiné à une entreprise exclue est un fichier unique, branché sur les deux outils. Si je passe sur Codex, cette ligne rouge me suit.
Les agents : une source, deux formats
Mes 15 agents spécialisés sont écrits pour Claude Code, un fichier texte par agent. Un script les traduit au format de Codex au début de chaque session, dans l’un ou l’autre outil. Il traduit aussi le choix du modèle : dans les deux outils, le modèle le plus cher supervise et les agents tournent sur un modèle moins cher. Je modifie un agent à un seul endroit, et Codex a les mêmes le jour où je change d’outil.
Les contrôles de fin de session : le relecteur change de côté
Le même script tourne à la fin de chaque session dans les deux outils. Il lance les tests rapides du projet, puis demande une relecture à l’autre outil quand la modification est assez grosse : Codex relit Claude Code, et Claude relit Codex. Lors d’un essai avec un bug glissé exprès, Claude l’a signalé en dix secondes. Pendant une panne de Claude, les tests tournent toujours sous Codex.
Les commandes à valider : une seule liste
Pousser du code ou déployer un site demande mon accord. Ces commandes sont dans une liste unique, et le même script en tire les réglages des deux outils : une demande de validation dans Claude Code, la même dans Codex. Le script fait pareil pour les verrous propres à un projet, comme un déploiement interdit dans un seul dossier. Quand une interdiction ne se traduit pas exactement, Codex demande mon accord au lieu de bloquer.
Les connecteurs : les mêmes comptes
Mes deux comptes Google passent par un petit serveur installé sur mon Mac, que les deux outils savent appeler. Codex lit donc les mêmes boîtes et les mêmes agendas que Claude Code, et le serveur refuse lui-même d’écrire à une entreprise exclue.
Le 13 novembre, ces quatre éléments n’existaient que dans Claude Code. Je les ai alignés le lendemain, en préparant cet article.
Les tests, les secrets et les tâches planifiées
Chaque projet a une carte de ses tests : quelle commande lancer après quel changement. C’est un fichier texte, que l’un ou l’autre outil peut suivre. Mes clés d’API sont dans le trousseau du Mac, et les scripts les lisent directement. Mes tâches planifiées tournent sur mon Mac, chez Cloudflare, sur GitHub Actions et sur Firebase : une panne de Claude Code ne les arrête pas, à une exception près, détaillée plus bas.
La passation entre les deux outils
Quand un outil s’arrête au milieu d’un travail, l’autre doit savoir où il en est. Ma règle demande une note de passation à la racine du projet : le but, la branche, les changements non enregistrés, le dernier contrôle qui est passé, la prochaine action et ce que j’ai déjà autorisé. Elle commence par la date, l’outil qui l’a écrite et l’état du code.
L’outil qui reprend compare la note à l’état réel du dossier avant de continuer. Si la note a plus d’un jour, il me redemande les autorisations qu’elle contient.
Cette note a une limite. Lors d’une panne brutale, Claude Code n’a pas le temps de l’écrire. Git prend alors le relais : presque tous mes projets sont versionnés, et la première consigne commune est de regarder l’état du dossier avant d’y toucher. Codex voit ce qui a changé, même sans note.
Ce qui ne suit pas
Il reste trois choses que je perds en passant sur Codex :
- La relecture par un second modèle : pendant une panne de Claude, il n’y a plus de relecteur. Les tests tournent, mais personne ne relit.
- Une tâche planifiée appelle Claude : parmi les neuf qui tournent sur mon Mac, ma veille IA lui fait rédiger un brouillon de post. Pendant une panne, elle échoue, l’écrit dans son journal, et je la relance plus tard.
- Mon abonnement Codex est le plus petit, à 20 € par mois, avec des limites d’usage plus basses. En cas de panne, je finis ce qui est en cours et je reporte le reste.
Sur Codex, je garde donc les mêmes règles, les mêmes agents, les mêmes contrôles et les mêmes comptes, avec moins de marge. Pour une panne de quelques heures, c’est suffisant.
Un secours qui sert tous les jours
Un plan de secours qu’on n’essaie jamais a peu de chances de marcher le jour où on en a besoin. Le mien sert tous les jours : dès qu’une modification devient assez grosse, Codex relit le travail de Claude Code. Il ouvre les mêmes dossiers, lit les mêmes règles et lance les mêmes commandes. Si un fichier commun était cassé, je le verrais dans la semaine.
La protection vaut dans l’autre sens. Si Codex ne répond pas, la relecture automatique est sautée et Claude Code continue. Elle vaut aussi pour un changement de prix, de limites d’usage ou de modèle : je peux changer d’outil sans réécrire mes règles.
Pour votre propre installation
- Écrivez vos règles dans un fichier texte que plusieurs outils savent lire, comme
AGENTS.md. Si votre outil principal veut son propre fichier, faites-le pointer vers le premier. - Gardez votre mémoire et vos procédures dans des dossiers à vous, en dehors de l’historique d’une application.
- Faites tourner vos tâches planifiées sur votre machine ou chez votre hébergeur.
- Installez un deuxième outil et confiez-lui un vrai travail chaque semaine, une relecture par exemple.
- Quand un réglage doit exister dans les deux outils, écrivez-le une fois et faites générer l’autre par un script.
- Faites la liste de ce qui ne suit pas, pour ne pas la découvrir pendant la panne.
Le 13 novembre, je n’ai pas eu à changer d’outil. Le jour où il le faudra, j’ouvrirai Codex dans le même dossier et je lui demanderai de lire l’état du projet avant de continuer.
