Qu'est-ce qu'un « compte » Claude Code, au juste

Avant de commencer

En deux ans, « je veux utiliser Claude Code / Codex » est passé de installer un paquet, coller une clé à quelque chose qui exige un vrai choix technique.

Les mêmes questions reviennent sans cesse dans la communauté, et ceux qui les posent sont rarement des débutants :

• « J'ai acheté du crédit API. Pourquoi la version web me demande-t-elle encore de me connecter ? »
• « Même compte. Hier tout marchait, aujourd'hui ça tourne dans le vide. Qu'est-ce qui a changé ? »
• « Pourquoi les relais font-ils tout un plat des IP ? Je ne peux pas simplement brancher un proxy plus cher ? »
• « Les hébergeurs disent "une fois attribué, l'environnement ne change plus". N'est-ce pas terriblement conservateur ? Passer à un meilleur ne serait-il pas plus rapide ? »
• « Une tâche longue a tourné deux minutes puis s'est coupée. Pourquoi réessayer coûte-t-il plus cher ? »

Ces questions semblent disparates. Elles pointent toutes le même endroit : la plupart des gens traitent le « compte » comme un atome indivisible, alors qu'il s'agit en réalité de trois types d'identifiants + deux niveaux de fenêtre de quota + un ensemble de contraintes de cohérence d'identité superposés. Tant qu'on ne sépare pas ces couches, aucune des questions ci-dessus n'a de réponse.

Cet article n'enseigne aucune combine et ne contient aucune recette d'évitement. Il fait une seule chose : rendre les contraintes techniques explicites — pourquoi les choses sont ainsi, et où chaque approche atteint son plafond sous ces contraintes.

Environ dix mille mots, avec cinq schémas explicatifs. À la fin, vous devriez pouvoir répondre vous-même aux cinq questions, et savoir quelle voie est la vôtre.

Sommaire

• Chapitre 1 Les identifiants : trois choses distinctes pendent au même compte
  • 1.1 La conclusion d'abord
  • 1.2 Deux chemins, séparés dès le système de facturation
  • 1.3 Clés API : de la mesure sans état
  • 1.4 Jetons OAuth : une identité porteuse de quota d'abonnement
  • 1.5 Identifiants de session : la couche web
  • 1.6 La chaîne de dérivation : qui produit quoi
• Chapitre 2 Le quota : comment les fenêtres glissantes façonnent votre ressenti
  • 2.1 Deux niveaux de fenêtre
  • 2.2 Les fenêtres se comptent par compte
  • 2.3 L'effet de file d'attente quand un compte est partagé
  • 2.4 Lire un 429 : toutes les « limitations » ne se valent pas
  • 2.5 Pourquoi « répartir équitablement » ne tient pas sous un modèle à fenêtre
• Chapitre 3 Cohérence d'identité : le risque n'est pas d'être utilisé, c'est d'avoir l'air d'un autre
  • 3.1 Ce que le serveur peut observer
  • 3.2 La cohérence l'emporte sur « mieux »
  • 3.3 Pourquoi un environnement fixe est une contrainte, pas de la paresse
  • 3.4 Une limite qu'il faut énoncer
• Chapitre 4 Isolation multi-tenant : où le partage atteint son plafond
  • 4.1 Isolation des sessions
  • 4.2 Isolation du quota
  • 4.3 Isolation des pannes
  • 4.4 Peut-on avoir les trois
• Chapitre 5 Le streaming : la partie la plus difficile d'un relais
  • 5.1 Pourquoi on ne peut pas « tamponner puis transmettre »
  • 5.2 Quatre façons de casser, identiques vues de l'extérieur
  • 5.3 Les reprises ne sont pas idempotentes
  • 5.4 Le dilemme du délai d'attente
  • 5.5 La contre-pression, la partie que tout le monde oublie
• Chapitre 6 Reprise et restauration : ce qu'un client d'hébergement fait sur votre machine
  • 6.1 Le problème
  • 6.2 Sauvegarder, écraser, restaurer
  • 6.3 Fusionner, ne pas remplacer
  • 6.4 Idempotence et « la première sauvegarde fait foi »
  • 6.5 Sûreté au crash : que se passe-t-il si le courant saute
  • 6.6 La symétrie à la sortie
• Chapitre 7 Observabilité : ce que vous devriez exiger de voir
  • 7.1 Un critère brut
  • 7.2 Ce qui devrait concrètement être visible
  • 7.3 Un anti-modèle
• Chapitre 8 Liaison d'appareil : pourquoi les identifiants sont émis pour « cette machine »
  • 8.1 Une connexion, plusieurs machines
  • 8.2 Pourquoi la révocation doit être un citoyen de première classe
• Chapitre 9 Choisir : un tableau de décision
  • 9.1 Ne comptez pas que le coût d'entrée
  • 9.2 Ces deux-là ne s'excluent pas
• Chapitre 10 Neuf idées fausses, en un tableau
• Conclusion

Chapitre 1 Les identifiants : trois choses distinctes pendent au même compte

1.1 La conclusion d'abord

Un compte Claude ou ChatGPT n'est pas, techniquement, « une chose ». Il dérive au moins trois types d'identifiants, qui ne sont pas équivalents :

La colonne contre-intuitive — celle sur laquelle on trébuche — est la dernière : les trois ouvrent des portes différentes et ne se substituent pas l'un à l'autre.

1.2 Deux chemins, séparés dès le système de facturation

Beaucoup croient qu'il s'agit simplement de « deux entrées vers le même modèle ». Techniquement, les deux atteignent bien les mêmes poids, mais ce sont deux systèmes entièrement séparés sur trois axes : facturation, authentification et limitation de débit.

Cette séparation est délibérée, car les deux publics veulent des choses incompatibles : l'appelant programmatique veut un prix unitaire prévisible, une concurrence extensible horizontalement, et aucune dépendance à « quelqu'un est en ligne » — une clé sans état l'implémente au mieux. L'abonné individuel veut « un prix, usage libre », et pour ne pas couler sous une poignée d'utilisateurs intensifs le fournisseur doit introduire un quota ; or pour qu'un quota fonctionne, la consommation doit être imputable à une personne précise — d'où une identité, d'où une connexion.

Une fois cela compris, toute une famille de « pourquoi ne peut-on pas… » se dissout d'elle-même. Ce n'est pas que les fournisseurs refusent de relier les deux : c'est qu'une fois reliés, les deux modèles de facturation ne se réconcilient plus.

1.3 Clés API : de la mesure sans état

La propriété déterminante d'une clé API tient en trois mots : mesure sans état — elle n'est liée à aucune session de connexion, peu importe la machine ou le client, le serveur l'accepte sur présentation ; la facturation se règle au token.

Sans état, elle convient donc parfaitement à l'appel programmatique (CI, services back-end, traitements par lots), sans que personne n'ait à rester connecté.

Et sans état, elle n'ouvre aucune surface destinée à un humain. La version web et le client de bureau ne veulent pas « quelque chose de facturable », ils veulent « quelqu'un de connecté » — et côté serveur ce sont deux chemins d'authentification entièrement distincts.

C'est la réponse complète à « j'ai acheté du crédit API, pourquoi la version web veut-elle encore une connexion ? ». Le produit n'est pas mal fichu ; ce que vous avez en main n'a jamais été fait pour ouvrir un navigateur.

1.4 Jetons OAuth : une identité porteuse de quota d'abonnement

Le deuxième type est le jeton OAuth, généralement une paire : un jeton d'accès à courte durée et un jeton de rafraîchissement qui le maintient en vie.

La différence de fond avec une clé API tient à la provenance :

• Une clé API se crée en cliquant un bouton dans une console. Elle vient de nulle part.
• Un jeton OAuth s'échange depuis une session déjà connectée — il faut que quelqu'un se soit effectivement connecté avant qu'un jeton puisse seulement être émis.

Deux conséquences.

Il puise dans le quota d'abonnement, pas dans le crédit mesuré. Quand vous lancez des tâches via le CLI officiel ou une extension d'éditeur, vous consommez l'allocation incluse dans votre formule — c'est pourquoi, chez un même fournisseur, « abonnement » et « API » sont deux comptabilités distinctes.

Il a un prérequis. Qu'un jeton puisse être émis dépend du palier du compte derrière la session source. Une session en palier gratuit ne produit généralement pas de jeton exploitable par le CLI ou les extensions d'éditeur — ce n'est pas un intermédiaire qui le retient, c'est la portée d'autorisation fixée à l'instant de l'émission.

L'implication pratique est nette : si vous comptez utiliser le CLI ou une extension d'éditeur, « j'ai un compte » doit se compléter en « j'ai un compte payant ». À confirmer avant l'achat, pas à mi-parcours de la configuration.

1.5 Identifiants de session : la couche web

Le troisième type est l'identifiant de session web — le cookie dans votre navigateur.

Sa propriété déterminante est d'être fortement lié à l'environnement d'émission. Une session est frappée lors d'une connexion précise, et le serveur observe bel et bien dans quel type d'environnement cette session réapparaît ensuite. Qu'un changement brusque déclenche une revérification est un comportement serveur parfaitement normal.

Le chapitre 3 développe ce point, car c'est celui qui porte les implications techniques les plus lourdes de tout l'article.

1.6 La chaîne de dérivation : qui produit quoi

Dessinée en chaîne :

Connexion e-mail ──► Identifiant de session ──► (si le palier l'autorise) Jeton OAuth
                             │
                             └──► Interface de chat web

Clé API ──► API mesurée     (entièrement parallèle ; les deux ne se croisent jamais)

Propriétés à retenir :

1. Les flèches sont à sens unique. Une session peut produire un jeton OAuth ; l'inverse est impossible.
2. La ligne des clés API est isolée. Elle ne participe à aucune étape ci-dessus et ne peut en être produite.
3. « Configuration terminée » comporte des niveaux. Obtenir une session signifie que le web fonctionne ; obtenir en plus un jeton signifie que le CLI et l'éditeur fonctionnent. Le premier est obligatoire, le second est une suite facultative.

Cette chaîne explique une confusion fréquente : pourquoi, après configuration, l'hébergement allume souvent le web d'abord et le CLI ensuite. Parce que ce sont réellement deux étapes, pas une. Tout service qui présente cela comme « configurez et tout marche » a soit caché la seconde étape, soit ignoré le cas où le palier du compte est insuffisant.

Chapitre 2 Le quota : comment les fenêtres glissantes façonnent votre ressenti

2.1 Deux niveaux de fenêtre

Le quota d'abonnement ne se mesure pas comme la plupart l'imaginent. Ce n'est pas un réservoir mensuel — pas « N appels ce mois-ci, puis terminé ». L'implémentation courante est une fenêtre glissante, généralement à deux niveaux :

• La fenêtre courte, de l'ordre de quelques heures. Elle décide si vous pouvez continuer à travailler maintenant. Elle est petite, donc la heurter est fréquent — surtout lors d'un gros refactoring ou d'une longue exécution d'agent.
• La fenêtre longue, de l'ordre de quelques jours. Elle décide votre enveloppe de la semaine. On la heurte rarement, mais la récupération est d'autant plus longue.

« Glissante » signifie que la borne de la fenêtre se mesure en remontant depuis cet instant, et non fixée à une heure ronde. Il n'y a donc pas de « attendre minuit et tout se réinitialise » — seulement « la consommation la plus ancienne sort de la fenêtre, et la capacité revient au compte-gouttes ».

2.2 Les fenêtres se comptent par compte

C'est la phrase porteuse du chapitre :

Les deux fenêtres se comptent par compte — pas par personne, pas par appareil, pas par IP.

Du point de vue du serveur, un compte est un sujet de quota. Qu'il y ait un humain ou dix derrière n'est ni connu ni pertinent.

2.3 L'effet de file d'attente quand un compte est partagé

Supposons un compte portant cinq utilisateurs, chacun avec un usage quotidien modeste. Sur le papier, cela passe largement. Mais une fenêtre glissante est extrêmement sensible à la concurrence instantanée : l'un lance un gros refactoring, la fenêtre courte monte à 90 % en vingt minutes, et les quatre autres se mettent à heurter le mur sans le moindre signe avant-coureur — sans voir qui, ni combien il reste, ni quand cela reviendra, puisque la récupération dépend du moment où la consommation la plus ancienne sortira, et que cette consommation n'est pas la leur.

Ce n'est pas quelque chose qu'un meilleur ordonnancement corrige. C'est déterminé par la granularité du sujet de quota. Tant que le quota se compte par compte et que le compte est partagé, le couplage existe.

2.4 Lire un 429 : toutes les « limitations » ne se valent pas

Ce que vous recevez en heurtant le mur est généralement un HTTP 429. Mais 429 ne veut pas dire la même chose selon la couche, et confondre les cas mène à la mauvaise réaction :

C'est le deuxième cas qu'on interprète mal. Beaucoup de clients appliquent par défaut « backoff puis reprise », mais sous quota de fenêtre réessayer est non seulement inutile, cela repousse la récupération — chaque requête échouée pouvant encore compter.

Le test est simple : la réponse porte-t-elle une heure de réinitialisation explicite ? Si oui, c'est du quota — patientez. Sinon, et si l'intervalle est court, c'est une limitation de débit et le backoff est approprié.

C'est aussi pourquoi « voir le quota restant et un compte à rebours » n'est pas un gadget mais une information de diagnostic nécessaire. Sans elle, tout ce que vous pouvez faire en heurtant le mur, c'est deviner.

2.5 Pourquoi « répartir équitablement » ne tient pas sous un modèle à fenêtre

L'idée évidente : mettre une répartition de quota dans la couche intermédiaire, plafonner chacun à un cinquième.

Deux problèmes la rendent inopérante.

Vous ne pouvez pas mesurer juste. La couche intermédiaire compte les requêtes qu'elle relaie, mais la comptabilité de fenêtre du serveur — pondération, conversion, glissement de borne — relève de son implémentation et n'est pas contractuelle. Votre courbe et la sienne divergeront, et l'écart entre elles est exactement « il m'en reste plein, et l'autre bout renvoie déjà des 429 ».

Et même si c'était possible, le compte n'y est pas. Divisez précisément en cinq, et chacun obtient un cinquième du quota d'un compte. Ce que l'utilisateur a réellement acheté n'est pas « un abonnement » mais « un cinquième d'abonnement » — autant le dire.

Le positionnement honnête d'une formule partagée est donc : usage modeste, tolérance aux files occasionnelles, priorité au faible seuil d'entrée et au faible coût de départ. C'est une position parfaitement légitime. Simplement, ce n'est pas la même chose que « stable et prévisible ».

Chapitre 3 Cohérence d'identité : le risque n'est pas d'être utilisé, c'est d'avoir l'air d'un autre

3.1 Ce que le serveur peut observer

À dire d'emblée : cette section ne discute d'aucune contre-mesure. Elle énonce un fait neutre — les signaux qu'un serveur peut observer pendant l'authentification vont bien au-delà de « avez-vous présenté un identifiant ».

Tout service en ligne mature consulte un ensemble de signaux contextuels lors du renouvellement de session, des opérations sensibles et de la détection d'anomalies. En gros, trois couches :

Comment le serveur pondère cela, et où sont les seuils, personne ne le publie et personne ne devrait prétendre le savoir. Quiconque brandit une « table de règles » garantissant la sécurité si on la suit peut être jugé non fiable sur cette seule base.

3.2 La cohérence l'emporte sur « mieux »

Il existe en revanche une régularité empirique qui découle des principes de conception et tient très bien :

Pour un détecteur d'anomalies, un changement brusque est plus intéressant que n'importe quelle valeur particulière.

La détection d'anomalies modélise « à quoi ressemble le normal » puis cherche les écarts. Si un compte opère longtemps dans un contexte stable, ce contexte devient sa ligne de base ; plus elle est stable, moins chaque accès ultérieur coûte à expliquer. À l'inverse, un compte ici aujourd'hui et là demain présente un changement qui, en soi, demande une explication, même si chaque « là » pris isolément semble normal.

D'où la conclusion technique la plus contre-intuitive — et la plus importante — de cet article :

La stabilité vaut plus que « mieux ».

L'instinct dit « je passe à une sortie réseau plus rapide et plus propre, le compte devrait être plus sûr ». Du point de vue du détecteur, ce que vous avez fait, c'est fabriquer une discontinuité. Le coût de cette discontinuité peut fort bien dépasser la qualité gagnée.

3.3 Pourquoi un environnement fixe est une contrainte, pas de la paresse

Voilà ce qui explique cette règle d'apparence conservatrice dans les offres hébergées : une fois attribué, l'environnement d'exécution ne change plus.

Facile à lire comme « le fournisseur se facilite la vie ». C'est en réalité une contrainte payée au prix fort : renoncer à « ordonnancer dynamiquement vers le meilleur chemin du moment », qui sonne bien plus sophistiqué, en échange d'une ligne de base qui ne bouge pas pour chaque compte.

La justification est le §3.2 : la disponibilité d'un compte est bien plus sensible à la stabilité du contexte qu'à sa qualité. Échanger un peu de plafond contre une ligne de base sans gigue est une bonne affaire.

La même logique explique un second choix : changer de compte ne change pas l'environnement. Compte et environnement sont deux couches ; quand un compte doit être remplacé, seule cette couche bouge. Bouger les deux reviendrait à déposer un nouveau compte dans un nouveau contexte — deux variables à la fois, la pire combinaison possible.

3.4 Une limite qu'il faut énoncer

Il faut le dire clairement, car c'est l'égarement le plus courant du domaine :

Aucun tiers ne peut garantir qu'un compte reste utilisable.

La disponibilité est tranchée en dernier ressort par le fournisseur officiel, pas par un intermédiaire. Ce qu'un prestataire — hébergeur compris — peut réellement faire tient en deux points :

1. Ne pas ajouter de risque inutile : pas de discontinuités gratuites, pas de schémas d'usage manifestement anormaux.
2. Rapporter l'état honnêtement : quand quelque chose casse, le signaler et vous prévenir immédiatement, plutôt que de vous laisser deviner devant une page d'erreur si le problème vient de vous.

Quant à « nous maintenons votre compte en vie », « aucun bannissement », « remboursement en cas de bannissement » — de telles promesses sont soit irréfléchies, soit sciemment intenables. Qu'un prestataire accepte d'écrire cette limite noir sur blanc en dit plus long que l'élégance de ses promesses.

Chapitre 4 Isolation multi-tenant : où le partage atteint son plafond

Le chapitre 2 a traité le couplage de quota, qui n'est qu'un des trois problèmes d'isolation. Partager un compte unique impose de résoudre les trois à la fois :

4.1 Isolation des sessions

Le problème : les conversations sous un même compte s'empilent naturellement ; A ouvrant la liste ne doit pas voir les sessions de B. La solution habituelle : la couche intermédiaire tient une table d'« appartenance des conversations » et filtre la liste par utilisateur.

Le plafond : le filtrage est au niveau présentation, pas au niveau stockage. Les conversations vivent toujours sous un seul compte, et toute action au niveau du compte (suspension, nettoyage officiel) frappe tout le monde également.

Les exigences techniques sur cette table sont d'ailleurs bien plus raides qu'il n'y paraît, et c'est la meilleure illustration de l'endroit où se cache réellement la complexité d'une conception partagée.

Un — c'est une lecture sur le chemin critique. Chaque ouverture de liste l'interroge, donc la latence se ressent directement. Le réflexe naturel est un cache mémoire en chemin rapide.

Deux — elle ne doit absolument pas être perdue. Ce qui entre en conflit avec le premier point : les caches sont volatils. Si le cache est la seule copie, alors un redémarrage de processus, une éviction ou une migration d'instance videra simultanément la liste de conversations de tous les utilisateurs. Et la panne est vicieuse à sa façon : elle ne ressemble pas à une panne. L'utilisateur voit une liste vide et en conclut « mes données ont disparu », pas « le service est cassé ».

Trois — elle doit être reconstructible. Ces deux points ne laissent qu'une solution : double écriture plus réhydratation au démarrage à froid — stockage durable comme source de vérité, cache comme chemin rapide, et au démarrage à froid le cache est rerempli depuis la vérité.

Ce qui mérite d'être dit franchement : une formule partagée paraît moins chère parce que le coût s'est déplacé des frais d'abonnement vers la complexité technique. Ce coût ne disparaît pas ; il est simplement payé ailleurs — et si une partie est bâclée, c'est l'utilisateur qui règle l'addition.

Quatre — le piège de la clé de tri. Un détail très concret et facile à rater. Une telle table doit trier par « dernière activité », et dès qu'un champ temporel traverse une interprétation de fuseau horaire, le problème surgit : si l'écrivain et le lecteur divergent sur le fuseau, le même instant se convertit en valeurs différentes et l'ordre s'effondre.

L'approche sûre est de stocker la clé de tri comme un horodatage entier brut, non comme un type date-heure porteur de fuseau, et de garder une colonne séparée pour l'affichage humain. Les entiers ne participent à aucune conversion de fuseau et sont immunisés par construction.

4.2 Isolation du quota

Le chapitre 2 a tranché : c'est impossible. Le sujet de quota est le compte ; c'est la granularité. Tout ce qu'une couche intermédiaire peut faire, c'est limiter de son côté, et cette courbe ne coïncide pas avec la vraie fenêtre du serveur.

4.3 Isolation des pannes

Le problème : quand le compte casse, le rayon d'impact est tout le monde qui y est rattaché.

Le plafond : c'est ce que signifie le mot partagé. Aucune technique ne contourne cela. Un compte en difficulté, c'est un groupe de gens en difficulté.

4.4 Peut-on avoir les trois

Non, et la raison est nette :

L'isolation des sessions peut être simulée par une couche intermédiaire. L'isolation du quota et des pannes exige de scinder le sujet de quota pour être réellement résolue.

Et « scinder le sujet de quota » se traduit en clair par : un compte, une personne.

C'est là toute la raison d'être de l'hébergement de compte comme catégorie. Ce n'est pas plus sophistiqué que le partage ; cela déplace simplement le problème vers la seule couche où il peut être résolu — au prix d'un abonnement par personne, ce qui change entièrement la structure de coûts.

Chapitre 5 Le streaming : la partie la plus difficile d'un relais

Les chapitres précédents traitaient le compte comme un actif statique. Celui-ci regarde ce qu'une requête traverse sur le fil. Les services IA ont une propriété que les API ordinaires n'ont pas : les réponses arrivent en flux, et une interaction peut durer des dizaines de secondes — ce qui transforme plusieurs non-problèmes en problèmes durs.

5.1 Pourquoi on ne peut pas « tamponner puis transmettre »

L'implémentation paresseuse lit intégralement la réponse amont en mémoire puis l'envoie d'un bloc. Convenable pour une API ordinaire ; catastrophique en streaming : le temps jusqu'au premier token passe de quelques centaines de millisecondes à toute la durée de génération — l'utilisateur fixe un curseur immobile pendant trente secondes, ce qui est expérientiellement indiscernable d'un blocage.

Le relais doit donc transmettre au fil de la réception, ce qui signifie qu'il maintient deux connexions vivantes pendant toute la génération. C'est la racine de tout ce qui suit.

5.2 Quatre façons de casser, identiques vues de l'extérieur

Chaque saut peut casser : le réseau du client vacille, l'instance de relais redémarre, le segment inter-réseaux expire, l'amont tombe en erreur. L'ennui, c'est que les quatre se ressemblent exactement côté client — le flux s'arrête, sans information distinctive.

Vous voilà donc incapable de décider depuis le symptôme s'il faut réessayer. Une atténuation praticable est que le relais émette un événement de fin structuré à la coupure, portant ce qu'il sait (quel saut, si l'amont a terminé délibérément, un éventuel code d'erreur). Ce ne sera pas parfait — si c'est le relais lui-même qui est mort, il ne peut rien émettre — mais cela couvre l'essentiel.

Il y a là un test de qualité pratique : regardez s'il vous dit quelque chose quand un flux meurt. Une implémentation qui s'arrête en silence est une implémentation qui ne suit pas cela elle-même.

5.3 Les reprises ne sont pas idempotentes

Les reprises d'API ordinaires sont généralement sûres : l'échec n'a rien coûté, on renvoie. Mais en streaming, à l'instant de l'interruption l'amont a peut-être déjà produit l'essentiel du contenu, et le quota est réellement dépensé. Une reprise porte donc un coût réel : double dépense (un succès du point de vue de l'utilisateur, deux du point de vue du compteur), impossible à recoudre (la génération est stochastique ; la seconde tentative ne prolonge pas la première), et comptabilité opaque (un relais qui réessaie en silence laisse l'utilisateur penser que son quota fond sans raison).

Le premier token est la ligne de partage :

Une implémentation responsable réessaie discrètement avant le premier token et rapporte honnêtement la coupure après. Déguiser un flux cassé en succès réduit les réclamations à court terme et dépense le quota de l'utilisateur pour soigner sa propre image à long terme.

5.4 Le dilemme du délai d'attente

Trop court et les tâches de longue réflexion sont tranchées — ce qui est précisément le cas d'usage principal du développement agentique, où un gros refactoring de plusieurs minutes est normal. Trop long et un amont figé retient des ressources jusqu'à l'expiration.

Mieux qu'un délai total, il y a le délai d'inactivité : ignorer la durée totale, ne regarder que le temps écoulé depuis le dernier fragment. Tant que ça débite, on ne coupe pas ; plus rien pendant plus que le seuil, on déclare le blocage. L'idée partage sa racine avec les fenêtres glissantes — toutes deux remplacent la « quantité absolue » par le « relatif à la dernière activité », car c'est cela qui reflète réellement la santé.

5.5 La contre-pression, la partie que tout le monde oublie

Le rythme auquel un relais lit l'amont et celui auquel il écrit vers le client ne sont pas nécessairement égaux. Si le client consomme lentement (mauvais réseau, ou simplement un terminal bloqué) tandis que le relais continue de tirer à plein régime, le tampon intermédiaire enfle sans borne — invisible sur une connexion, et épuisement mémoire quand des centaines le font en même temps.

Le comportement correct est que le rythme de consommation en aval exerce une contre-pression sur le rythme de lecture en amont : si le client ne suit pas, on arrête de lire l'amont. La plupart des frameworks de streaming modernes l'intègrent, mais une logique de relais écrite à la main l'omet constamment, et cela ne se manifeste que sous vraie concurrence, que les environnements de test produisent rarement.

Le chapitre en une ligne : le streaming fait passer le « relayage » d'une opération sans état à une opération avec état. Chaque saut supplémentaire ajoute un endroit où casser, un tampon à gérer, une décision de reprise à prendre. C'est pourquoi les chemins courts paraissent plus stables — non parce que court serait sophistiqué, mais parce qu'il y a moins de choses qui peuvent mal tourner.

Chapitre 6 Reprise et restauration : ce qu'un client d'hébergement fait sur votre machine

6.1 Le problème

Un compte hébergé doit faire tourner les clients officiels sur votre propre machine, et ces clients conservent leur identité dans des fichiers de configuration locaux. D'où la question évidente : vous avez déjà votre propre état de connexion.

Une implémentation sans conception l'écrase, tout simplement — votre compte est inutilisable pendant l'hébergement, et à la fin vous devez vous reconnecter sans probablement plus vous souvenir de ce que vous aviez configuré. Dans beaucoup d'offres, ce coût est discrètement transféré à l'utilisateur.

6.2 Sauvegarder, écraser, restaurer

Une implémentation responsable en fait une séquence en trois temps strictement symétrique :

Avant la reprise   conserver l'état actuel tel quel
       ↓
Pendant           la configuration hébergée s'applique ; la vôtre n'est pas touchée
       ↓
Au démontage      remettre la copie conservée, retirer toute trace

Simple à énoncer. Bien le faire demande plusieurs détails non triviaux.

6.3 Fusionner, ne pas remplacer

Écrire la configuration doit se faire par fusion, pas par remplacement intégral. Un fichier de configuration contient plus que l'identité — préférences, historique, réglages de projet. Remplacez intégralement et tout cela disparaît.

Le comportement correct est de n'écrire que la poignée de clés dont l'hébergement a réellement besoin et de laisser le reste intact octet pour octet ; au démontage, ne retirer que ces clés. Un fichier qui ne contenait jamais ces clés doit ressortir d'un cycle complet reprise-restauration identique à son entrée.

C'est aussi pourquoi, en décrivant un tel système, « nous ne touchons pas à vos réglages » est un mensonge, tandis que « nous n'écrivons que les quelques clés nécessaires et laissons le reste tel quel » est la vérité. L'utilisateur ne croit pas la première (il sait bien qu'il faut modifier quelque chose) ; la seconde est vérifiable.

6.4 Idempotence et « la première sauvegarde fait foi »

La partie la plus propice aux bugs : les sauvegardes doivent être idempotentes, et la première fait foi. Considérez cette séquence :

1. Reprise ; votre configuration d'origine est sauvegardée — sauvegarde = votre original ✓
2. L'hébergement tourne ; la configuration est en état hébergé
3. Pour une raison quelconque (reconnexion, bascule, redémarrage du client) la reprise se déclenche à nouveau
4. Si cette sauvegarde écrit sans condition — sauvegarde = la configuration hébergée ✗
5. Le démontage restaure — vous récupérez l'état hébergé, et votre original est perdu pour toujours

La règle doit donc être : s'il existe une sauvegarde, ne jamais l'écraser. La première est l'original ; toutes les suivantes sont de la saleté.

Un cas limite se rate facilement : « il n'y avait pas de fichier ici » est aussi un état, et il doit être enregistré. Sinon la restauration ne peut distinguer « remettre les octets » de « supprimer ce que nous avons créé » — et une implémentation qui ne les distingue pas laisse à l'utilisateur un fichier qu'il n'a jamais eu.

6.5 Sûreté au crash : que se passe-t-il si le courant saute

Tout ce qui précède suppose que la séquence va au bout. En réalité, les processus sont tués, les machines s'endorment, les disques se remplissent. Donc : interrompue à n'importe quelle étape, dans quel état est le système ?

① lire la configuration d'origine de l'utilisateur
② écrire le fichier de sauvegarde   ← mort ici : sauvegarde peut-être incomplète
③ écrire la configuration hébergée  ← mort ici : sauvegarde intacte, config à moitié écrite
④ ……exécution……
⑤ restaurer depuis la sauvegarde    ← mort ici : config peut-être à moitié écrite
⑥ supprimer la sauvegarde (si besoin) ← mort ici : config restaurée, juste un fichier résiduel

Les dangereuses sont ② ③ ⑤ — un fichier de configuration à moitié écrit est, pour le client, un fichier corrompu.

Le remède standard consiste à écrire dans un fichier temporaire puis renommer atomiquement. Le système de fichiers garantit l'atomicité du renommage : vous voyez soit l'ancien fichier, soit un nouveau complet, jamais un hybride. C'est quasi universel pour l'écriture de configuration, cela ne coûte presque rien, et s'en passer corrompt les configurations à faible probabilité — une classe de bug extrêmement coûteuse à reproduire et qui n'apparaît en général qu'en production.

Un résidu de l'étape ⑥ est en revanche inoffensif : un fichier de sauvegarde en trop ne casse rien, et la règle « ne jamais écraser une sauvegarde existante » le protège encore. Dans ce type de conception, mieux vaut un résidu qu'une perte — un bon principe général.

6.6 La symétrie à la sortie

Le démontage doit être aussi complet que la reprise. Si la reprise a touché trois endroits (configuration CLI, extension d'éditeur, pointeur du client de bureau), le démontage doit défaire les trois. En rater un ne produit généralement pas une erreur mais une dégradation silencieuse : la configuration de l'éditeur pointe encore vers un exécutable supprimé, l'extension ne le trouve pas et retombe discrètement sur sa copie intégrée, et l'utilisateur ne peut pas voir que l'hébergement a cessé de fonctionner. Il trouve juste que « ça déconne un peu ces derniers temps ».

Un échec silencieux est dix fois plus difficile à diagnostiquer qu'une erreur. C'est la partie de ce type d'ingénierie client qui mérite le plus d'investissement.

Chapitre 7 Observabilité : ce que vous devriez exiger de voir

7.1 Un critère brut

Un service d'hébergement, c'est fondamentalement détenir un actif pour vous et l'exploiter pour vous, et l'asymétrie d'information y est inhérente. Le meilleur indicateur unique pour savoir s'il mérite votre confiance n'est donc pas son marketing technique mais :

Combien vous montre-t-il spontanément de ce que vous ne pourriez pas voir autrement ?

Publier son état a un coût — une fois à découvert, on ne peut plus rester vague quand ça tourne mal. Ceux qui acceptent ce coût sont généralement ceux qui peuvent l'assumer.

7.2 Ce qui devrait concrètement être visible

Par ordre de priorité approximatif :

Deux bonus, qui font aussi office d'indicateurs inversés :

• Les résultats sont-ils affichés tels que mesurés ? Un panneau qui affiche toujours « tout est normal » ne mesure probablement rien. Celui qui accepte d'afficher « pas encore vérifié » et « vérification échouée » est plus crédible qu'un panneau perpétuellement vert.
• Pouvez-vous déclencher une vérification vous-même ? Attendre passivement une notification et vérifier activement sont deux expériences différentes, et seule la seconde produit un sentiment de maîtrise.

7.3 Un anti-modèle

Une conception dont il faut se méfier : donner la conclusion sans la base.

Un panneau annonce « ligne saine » sans indiquer quand cela a été établi ni à partir de quoi. Le problème surgit quand votre expérience contredit la conclusion : vous n'avez aucun moyen de juger si le problème vient de vous ou de lui.

Mieux vaut présenter conclusion, heure et origine ensemble : « voici le résultat de la vérification que vous avez lancée il y a dix minutes » est bien plus utile qu'un « saine » esseulé.

Chapitre 8 Liaison d'appareil : pourquoi les identifiants sont émis pour « cette machine »

8.1 Une connexion, plusieurs machines

Question légitime : si le compte est le mien, en quoi le nombre de machines importe-t-il ?

Techniquement, on pourrait copier un identifiant partout. L'approche plus mature est l'émission par appareil : chaque machine s'autorise une fois et reçoit son propre identifiant.

Cette étape supplémentaire achète trois choses :

1. La visibilité : vous voyez quels appareils sont utilisés et quand chacun a été actif pour la dernière fois.
2. La révocabilité : retirer une machine, ou une que vous ne reconnaissez pas, sans affecter les autres.
3. Un rayon d'impact réduit : un identifiant fuité compromet exactement une machine.

8.2 Pourquoi la révocation doit être un citoyen de première classe

Le point 2 mérite qu'on insiste. Dans beaucoup de conceptions, la révocation est ajoutée après coup et bâclée. Or en termes de sécurité, émission et révocation doivent former une paire symétrique — un système qui ne sait qu'émettre accumule, avec le temps, une pile d'identifiants encore valides dont plus personne ne se souvient.

Pour un utilisateur, « puis-je révoquer un appareil moi-même » est un bien meilleur test du sérieux d'une conception que le décompte des mots de sécurité dans son marketing.

Chapitre 9 Choisir : un tableau de décision

Les huit premiers chapitres, compressés en quelque chose d'actionnable :

9.1 Ne comptez pas que le coût d'entrée

Une dimension que presque personne ne soulève : combien cela vous coûte-t-il de partir quand ça ne va plus ?

Ce n'est pas une question commerciale mais technique — le coût de sortie est déterminé presque entièrement par le nombre et la profondeur des points de couplage.

Trois points méritent d'être relevés.

Le faible coût de sortie des clés API est très sous-estimé. Les formes d'API officielles ont convergé et la plupart des clients permettent de changer l'URL de base — passer du fournisseur A au B coûte à peu près rien. Cela ne vous enferme presque pas.

Juger le coût de sortie d'une offre hébergée revient à juger la logique de restauration du chapitre 6. Une implémentation qui restaure proprement demande une désinstallation ; une implémentation bâclée vous laisse traquer chaque endroit modifié, sans savoir lesquels. Ces détails pointilleux du chapitre 6 (la première sauvegarde fait foi, fusionner plutôt que remplacer, démontage symétrique) ne déterminent donc pas « l'agrément d'usage » mais votre liberté de partir quand vous voulez.

Les comptes achetés couplent le plus profondément. Une seule question compte : si j'arrête de renouveler, le compte reste-t-il le mien ? Les réponses varient beaucoup d'un prestataire à l'autre, et poser la question une fois le problème survenu est trop tard. À l'inverse, apporter son propre compte est la forme d'hébergement la moins couplante — le compte reste le vôtre du début à la fin ; seul l'environnement qui l'exécute est hébergé.

9.2 Ces deux-là ne s'excluent pas

À l'usage et abonnement peuvent coexister, et la plupart des équipes matures font exactement cela : développement interactif sur un compte d'abonnement (il faut l'interface et la continuité), CI et traitements par lots sur une clé API (il faut l'absence d'état et la concurrence). Les deux se complètent ; forcer un choix complique la vie sans raison.

Chapitre 10 Neuf idées fausses, en un tableau

Conclusion

Revenons aux cinq questions du début :

• Crédit API acheté, le web demande quand même une connexion — deux chemins d'authentification parallèles ; une clé ne produit pas une identité.
• Bien hier, ça tourne dans le vide aujourd'hui — très probablement une fenêtre glissante, et si le compte est partagé, celui qui l'a consommée n'est pas forcément vous.
• Pourquoi insister sur le fixe plutôt que sur « mieux » — la détection d'anomalies modélise le normal ; c'est la discontinuité elle-même qui demande une explication.
• « L'environnement ne change jamais » est-il trop conservateur — c'est un coût payé délibérément, pas de la paresse.
• Pourquoi réessayer une longue tâche coupée est pire — après le premier token le quota est dépensé ; une reprise facture deux fois, et cela ne se recoud pas.

Un niveau au-dessus, ce que cet article veut vraiment dire tient en une phrase simple :

Dans ce domaine, ceux qui énoncent clairement leurs contraintes méritent plus de confiance que ceux qui énoncent joliment leurs promesses.

Parce que les contraintes sont vérifiables — vous pouvez aller les heurter et voir si les choses se comportent comme annoncé. Les promesses, elles, logent là où vous ne pouvez pas vérifier, et quand vous le pouvez enfin, vous avez généralement déjà payé.

Si cela vous amène à poser deux questions de plus lors de votre prochain choix — « comment le quota est-il compté exactement », « que fait-il quand un flux meurt », « ma machine peut-elle être proprement restaurée quand je pars » — l'objectif est atteint.

Cet article ne discute que de mécanismes publiquement observables et de compromis techniques généraux. Il ne contient aucun détail de règle côté serveur et n'offre aucune technique d'évitement. Les descriptions des fenêtres de quota et des chemins d'authentification sont des généralisations comportementales du point de vue de l'utilisateur et ne représentent l'implémentation interne d'aucun fournisseur.