DEV Community: Olivier

Absorber les +50 % de l'API Claude sans couper une feature

Olivier — Sun, 09 Aug 2026 18:13:52 +0000

Le 1er septembre 2026, le tarif de lancement de Claude Sonnet 5 s'arrête. L'input passe de 2 $ à 3 $ le million de tokens, l'output de 10 $ à 15 $ : +50 % sur les deux lignes, pour tout le monde qui appelle l'API en paiement à l'usage. La panique par défaut, c'est de couper des fonctionnalités ou de rétrograder vers un modèle plus faible. Il y a mieux, et c'est déjà dans l'API. Deux mécanismes — le prompt caching et le batch — encaissent la hausse à ta place, souvent avec de la marge. Voici le code, les chiffres, et les pièges que j'ai payés pour que tu ne les paies pas.

Ce qui bouge exactement le 1er septembre

Trois lignes suffisent à raisonner. Le reste du barème (Opus, Haiku, contexte 1M) ne change pas.

Poste Sonnet 5 (par M de tokens)	Jusqu'au 31 août	Dès le 1er sept.
Input standard	2 $	3 $
Output	10 $	15 $
Lecture cache (hit)	0,20 $	0,30 $

Retiens la troisième ligne, parce que c'est elle qui gagne la partie. Un cache hit coûte 10 % du prix d'input. Même après la hausse, lire depuis le cache à 0,30 $ reste moins cher que l'ancien input plein à 2 $. Autrement dit, le contexte que tu répètes à chaque appel — un system prompt costaud, une doc, des exemples few-shot — peut être payé une fois puis relu pour trois fois rien.

Le prompt caching, concrètement

Le principe est simple : tu marques un bloc stable avec cache_control, et tout ce qui précède ce marqueur est mis en cache. Le premier appel paie une écriture ; les suivants, dans la fenêtre TTL, lisent à 10 %.

import anthropic

client = anthropic.Anthropic()
DOCS = load_docs()  # ~20 000 tokens, identiques à chaque requête

def ask(question: str):
    return client.messages.create(
        model="claude-sonnet-5",
        max_tokens=1024,
        system=[
            {"type": "text", "text": "Assistant support de l'app Lumière."},
            {
                "type": "text",
                "text": DOCS,
                "cache_control": {"type": "ephemeral"},  # TTL 5 min
            },
        ],
        messages=[{"role": "user", "content": question}],
    )

La question de l'utilisateur arrive après le bloc caché : elle est volatile, elle n'est pas mise en cache, et c'est exactement ce qu'on veut. Ne te fie jamais à ton intuition. Vérifie dans usage, qui ne ment pas.

r = ask("Comment j'annule un rendez-vous ?")
print(r.usage)
# 1er appel : cache_creation_input_tokens=20000, cache_read_input_tokens=0
# appels < 5 min : cache_creation_input_tokens=0, cache_read_input_tokens=20000

Si cache_read_input_tokens reste à zéro alors que tu t'attends à un hit, tu as un bug quelque part — et ce bug te coûte de l'argent en silence.

Les pièges du cache que j'ai payés

Le caching n'est pas magique, et il échoue sans lever d'exception. Voici les cinq façons de croire qu'on cache alors qu'on paie plein tarif.

Minimum 1024 tokens. Sous ce seuil, Sonnet ne met rien en cache et l'API ne dit rien. Tu penses optimiser, tu factures normalement. Contrôle cache_read_input_tokens sur un vrai appel avant de conclure.
L'ordre décide de tout. Le cache_control est une frontière : avant, c'est caché ; après, non. Mets le stable en premier (system, docs, few-shots) et le volatil en dernier (question, historique récent). Un identifiant de session glissé en tête casse le préfixe à chaque appel.
Un token qui change = cache manqué. Le hit exige un préfixe identique au byte près. Une date injectée dans le system prompt, un timestamp, un ordre de clés JSON non déterministe : le cache saute et tu repaies l'écriture.
L'écriture coûte plus cher que l'input plein — 1,25× en TTL 5 min, 2× en TTL 1 h. Cacher un contexte utilisé une seule fois est une perte sèche. Le cache ne gagne que si le même préfixe est relu plusieurs fois dans la fenêtre.
Le TTL expire en silence. Il se rafraîchit à chaque hit, mais un trafic clairsemé — une requête tous les quarts d'heure — laisse le cache mourir entre deux appels, et tu repaies l'écriture à répétition. Trafic régulier, ou passe en TTL 1 h avec {"type": "ephemeral", "ttl": "1h"}.

Le batch pour tout ce qui n'est pas temps réel

Le caching couvre le contexte répété. Le batch couvre une autre moitié du travail : tout ce qui peut attendre. L'API Batch applique −50 % sur l'input ET l'output, en échange d'un traitement asynchrone (garanti sous 24 h, souvent bien plus rapide).

batch = client.messages.batches.create(
    requests=[
        {
            "custom_id": f"doc-{i}",
            "params": {
                "model": "claude-sonnet-5",
                "max_tokens": 1024,
                "messages": [{"role": "user", "content": f"Résume : {doc}"}],
            },
        }
        for i, doc in enumerate(documents)
    ]
)

Tu ne batches pas un chatbot en direct, évidemment. Mais l'indexation nocturne, la génération d'embeddings de description, la classification d'un backlog de tickets, les rapports du matin : tout ça part en batch et coûte moitié prix. Et sur les jobs où le même préfixe revient, la remise batch et la remise cache se cumulent.

La facture avant/après, en clair

Un cas concret vaut mieux qu'un discours. Bot de support en RAG : 20 000 tokens de contexte réutilisé, 500 tokens de question, 800 tokens de réponse, 10 000 requêtes par mois.

Scénario	Coût/mois
Août, sans cache (2 $/10 $)	~490 $
Septembre, sans cache (3 $/15 $)	~735 $
Septembre, avec cache	~195 $

La hausse brute te fait passer de 490 à 735 $, soit +245 $. Mais le contexte caché fait tomber la facture de septembre à 195 $ — moins que ce que tu payais en août au tarif de lancement. La bonne lecture n'est donc pas « l'API augmente de 50 % » : c'est « l'API punit ceux qui envoient 20 000 tokens en plein tarif à chaque appel ». Le +50 % existe. Il ne te concerne que si tu n'as rien optimisé.

Un dernier réflexe avant de migrer : re-mesure ta consommation réelle sur Sonnet 5 plutôt que de reprendre tes compteurs d'un modèle précédent. Le nombre de tokens facturés pour un même texte dépend du tokenizer du modèle, et il peut différer de ce que tu avais l'habitude de voir. Ta seule source fiable reste le champ usage renvoyé par l'API. Pas une estimation faite à la main.

Par où commencer lundi

Trois gestes, dans l'ordre. Instrumente d'abord : logue input_tokens, output_tokens, cache_creation_input_tokens et cache_read_input_tokens sur chaque appel, sinon tu optimises à l'aveugle. Isole ensuite ton plus gros préfixe stable et pose-y un cache_control. Bascule enfin en batch tout ce qui n'a pas besoin d'une réponse dans la seconde.

Si tu veux le détail de qui paie plus et qui ne paie rien (abonnés Pro/Max, utilisateurs restés sur Sonnet 4.6), on l'a posé à plat dans la fiche sur la hausse. Et si tu construis des apps où le coût IA doit tenir en production sans y penser tous les matins, c'est exactement ce qu'on apprend à cadrer dans la formation Claude Code.

Voice-to-code 100 % local : Whisper + Claude Code, zéro octet au cloud

Olivier — Sun, 09 Aug 2026 15:55:38 +0000

Coder à la voix avec ChatGPT, ça marche. Le hic tient en une ligne : chaque mot que tu dictes part chez OpenAI. Depuis le 23 juillet 2026, Codex se pilote à la voix — il ouvre une pull request, cherche l'origine d'un bug, tout ça dans une phrase. Pratique pour un side-project. Rédhibitoire quand le code appartient à un client.

On voulait le même confort sans la fuite. Le résultat est un pipeline 100 % local : faster-whisper pour la transcription, Claude Code et sa commande /voice pour l'agent. Rien ne sort de la machine — ni la voix, ni le contexte, ni le code. Voici la config exacte, la latence qu'on mesure sur un M2, et les deux bugs qui nous ont coûté une demi-journée.

Pourquoi pas simplement Codex vocal ?

Parce que « coder à la voix » cache deux choses qu'on confond tout le temps. Le mode vocal de ChatGPT est fait pour converser : il répond, il temporise, il reformule. Dicter du code, c'est l'inverse — tu veux une transcription fidèle et muette, qui ne discute pas, ne reformule pas et n'ajoute rien à ce que tu dis. Deux gestes opposés.

Le vrai stack n'est donc jamais « ChatGPT vocal seul ». C'est un outil de dictée précis d'un côté, un agent de code de l'autre. Codex vocal fait les deux dans le cloud pour 20 €/mois ; un setup local sépare les deux briques et garde tout sur ta machine. Le tour d'horizon complet — prix, outils, cas d'usage — est dans le guide de référence ; ici, on reste sur le terrain technique.

Le chemin le plus court : `/voice`

Depuis mars 2026, Claude Code embarque un mode vocal. Tu tapes /voice dans le terminal, tu tiens la barre d'espace, tu parles, tu relâches. La transcription passe par un Whisper local, pas par une API distante.

> /voice
[hold space to talk · release to send]

Pour 90 % des cas, ça suffit. Tu dictes une intention, l'agent écrit le code, tu relis. Si tu veux garder la main sur le modèle, la langue et le vocabulaire technique, il faut descendre d'un cran et brancher ta propre transcription.

Le pipeline DIY, brique par brique

Trois morceaux : capturer l'audio, le transcrire, l'injecter. On enregistre avec sox, on transcrit avec faster-whisper, on colle le texte dans le prompt de l'agent.

brew install sox
pip install faster-whisper

Enregistrement à la volée, arrêté au Ctrl-C :

sox -d -q clip.wav

Transcription, en forçant le français :

from faster_whisper import WhisperModel

# int8 pour tenir sur CPU Apple Silicon (pas de Metal via CTranslate2)
model = WhisperModel("medium", device="cpu", compute_type="int8")

segments, _ = model.transcribe("clip.wav", language="fr")
print("".join(s.text for s in segments))

Un détail qui compte : sur Mac, faster-whisper tourne sur CPU, pas sur le GPU. Le modèle large-v3 est le plancher de précision en français, mais il rame ; medium reste le bon compromis. Évite les modèles distil-*, optimisés pour l'anglais. Sur du français, ils inventent. Si tu veux le GPU, whisper.cpp l'exploite via Metal et va plus vite ; on est resté sur faster-whisper pour son API Python, plus simple à scripter et à biaiser.

La latence, chiffrée

On a mesuré le temps entre la fin d'une phrase de 8 secondes et le texte prêt à coller, sur un MacBook M2 16 Go :

Modèle	Type	Temps	Précision FR
`medium`	int8	~1,2 s	correcte
`large-v3`	int8	~3,5 s	meilleure
Codex vocal (cloud)	—	200-450 ms	excellente

Le cloud gagne la course de vitesse, sans surprise. Mais 1,2 seconde par phrase ne casse pas un flux de code : tu ne dictes pas à 160 mots/minute en continu, tu réfléchis entre deux instructions. Le vrai coût du local n'est pas la latence, c'est la config initiale.

Le bug qui nous a coûté une demi-journée : le franglais

Voilà le piège que personne ne teste. Dicte « crée une fonction getUserData » à un Whisper réglé en français, et tu récupères ça :

crée une fonction get user data

Trois mots séparés, en minuscules, avec un point ajouté par le modèle. Multiplie ce raté par chaque useState, chaque endpoint, chaque nom de variable en anglais, et la transcription entière devient inutilisable au moment de la coller. Le réflexe — épeler, ou dicter la syntaxe à la main — tue alors tout le gain de vitesse. Retour à la case départ.

La bonne réponse tient en deux règles. D'abord, on ne dicte jamais les identifiants : on décrit l'intention (« crée une fonction qui récupère les données utilisateur ») et on laisse l'agent nommer. Ensuite, pour les termes inévitables, on biaise le décodeur avec un initial_prompt :

segments, _ = model.transcribe(
    "clip.wav",
    language="fr",
    initial_prompt="Termes techniques : useState, getUserData, TypeScript, PostgreSQL, endpoint, refactor.",
)

Ce prompt ne transcrit rien — il oriente le vocabulaire. Nos noms de variables anglais sont ressortis corrects dès qu'ils y figuraient. C'est le genre de détail qu'on ne trouve dans aucun tuto grand public, parce qu'aucun ne code réellement en français.

Ce que la voix fait bien, ce qu'elle rate

Après une semaine sur ce setup, le verdict est net. La voix excelle pour prompter l'agent et naviguer ; elle est mauvaise dès qu'il faut de la précision caractère par caractère.

Ce qui marche :

décrire une intention longue sans lâcher le clavier des yeux ;
lancer des commandes (« ajoute un test pour ce cas », « refactore cette fonction ») ;
coder quand tes poignets crient — la raison historique du voice coding, née des TMS, pas de la hype.

Ce qui casse :

taper la syntaxe exacte : accolades, indentation, opérateurs ;
les noms de variables et d'API en anglais (voir plus haut) ;
la revue de code fine, qui reste un travail d'œil et de tête.

La voix change l'interface, pas le métier. Elle déplace la frappe du clavier vers le micro, mais elle ne supprime ni la décision d'architecture, ni le choix des noms, ni la relecture ligne à ligne. L'agent génère, l'ingénieur tranche — et aucun micro ne tranchera à sa place.

On garde quoi ?

Pour du code perso, Codex vocal est plus simple et plus rapide — assume juste que ta voix part dans le cloud. Tout dépend de l'enjeu. Pour du code client ou propriétaire, le pipeline local Whisper + /voice est le seul qui garantit que rien ne fuit, au prix d'une latence d'une seconde et d'une soirée de config.

Si tu veux le monter proprement — modèle, vocabulaire, push-to-talk, intégration à ton éditeur — c'est exactement ce qu'on démonte étape par étape dans la formation Claude Code. Et pour rester côté outils, on a comparé Claude Code et Cursor et détaillé le mode vocal de Claude sur Gmail et l'agenda.

Intégrer « Sign in with ChatGPT » : le flux OAuth 2.0 + OIDC, avec le code

Olivier — Tue, 04 Aug 2026 19:31:20 +0000

Le 2 août 2026, OpenAI a mis « Sign in with ChatGPT » en bêta. Pas de nouveau protocole. C'est OAuth 2.0 + OpenID Connect, flux Authorization Code, exactement le socle de « Sign in with Google ». Si tu as déjà branché un provider OIDC, tu connais 90 % du travail, et les 10 % restants sont précisément là où les intégrations se cassent — vérification du token, nonce, lock-in. C'est de ça qu'on parle.

Six partenaires étaient présents au lancement : Airtable, GitLab, HubSpot, Notion, Supabase, Vercel. OpenAI pousse les devs à tester avec des crédits API (+5 $ en Plus, +50 $ en Pro, d'après une source unique à reconfirmer). L'incitation est réelle. Mais elle ne change rien au vrai sujet : ce que ton backend fait du token une fois qu'il l'a reçu.

Le flux, en six temps

OpenAI devient un fournisseur d'identité. Ton app ne voit jamais le mot de passe de l'utilisateur ; elle reçoit un jeton signé qui atteste « cette personne est bien untel ». Le flux Authorization Code, avec PKCE, se déroule ainsi :

Ton serveur redirige l'utilisateur vers l'endpoint d'autorisation d'OpenAI, avec client_id, redirect_uri, scope=openid profile email, un state et un code_challenge (PKCE).
L'utilisateur s'authentifie chez OpenAI et consent au partage.
OpenAI le renvoie sur ta redirect_uri avec un code court et le state.
Ton backend échange ce code contre un access_token et un id_token (un JWT).
Tu vérifies la signature de l'id_token, puis iss, aud, exp et le nonce.
Tu lis les claims : sub, name, email, picture. Fin.

Le point clé est à l'étape 4. Le code ne voyage jamais dans le navigateur au-delà d'un aller simple, et l'échange se fait de serveur à serveur, ton client_secret à l'appui. C'est ce qui rend le flux Authorization Code plus sûr que l'ancien flux implicite, désormais déconseillé.

Le code qui marche (Node + openid-client)

Ne réécris pas la vérification cryptographique à la main. La lib openid-client gère la découverte, PKCE, le state, le nonce et la validation JWKS. Voici la configuration, à partir du document de découverte OIDC :

import { Issuer, generators } from 'openid-client';

// L'issuer exact est fourni dans la console OpenAI quand tu enregistres ton app.
const openai = await Issuer.discover('https://auth.openai.com');

const client = new openai.Client({
  client_id: process.env.OPENAI_CLIENT_ID,
  client_secret: process.env.OPENAI_CLIENT_SECRET,
  redirect_uris: ['https://ton-app.com/auth/chatgpt/callback'],
  response_types: ['code'],
});

La redirection génère et stocke les secrets éphémères — code_verifier, state, nonce — côté session :

app.get('/auth/chatgpt', (req, res) => {
  const code_verifier = generators.codeVerifier();
  const code_challenge = generators.codeChallenge(code_verifier);
  const state = generators.state();
  const nonce = generators.nonce();

  req.session.pkce = { code_verifier, state, nonce };

  const url = client.authorizationUrl({
    scope: 'openid profile email',
    code_challenge,
    code_challenge_method: 'S256',
    state,
    nonce,
  });
  res.redirect(url);
});

Le callback fait le vrai travail. Un seul appel échange le code, vérifie la signature contre le JWKS d'OpenAI et recale state comme nonce :

app.get('/auth/chatgpt/callback', async (req, res) => {
  const { code_verifier, state, nonce } = req.session.pkce;
  const params = client.callbackParams(req);

  const tokenSet = await client.callback(
    'https://ton-app.com/auth/chatgpt/callback',
    params,
    { code_verifier, state, nonce },
  );

  const claims = tokenSet.claims();
  // { sub, name, email, picture, iss, aud, exp, iat, ... }
  res.json({ id: claims.sub, name: claims.name, email: claims.email });
});

Les trois pièges qui cassent tout

Le flux paraît simple, et c'est bien le problème : on croit avoir fini alors qu'on vient d'ouvrir une faille.

Décoder n'est pas vérifier. Un jwt.decode(id_token) te rend les claims sans contrôler la signature. N'importe qui peut forger un JWT avec email: patron@boite.com, et sans validation JWKS, tu le gobes. Il faut vérifier la signature contre les clés publiques d'OpenAI, à chaque connexion.
Le nonce oublié. Sans lui, un id_token intercepté peut être rejoué. Tu le génères à l'aller, tu le stockes en session, tu vérifies qu'il revient identique — c'est exactement ce que openid-client fait si tu le lui passes, d'où l'intérêt de ne pas « simplifier » l'appel callback.
aud et iss non contrôlés. Un token parfaitement signé mais émis pour une autre app, ou par un autre émetteur, doit être rejeté. C'est le genre de trou qu'un pentest trouve en dix minutes.

Le sub est ton identifiant stable, pas l'e-mail. Un utilisateur peut changer d'adresse ; le sub d'OpenAI, non. Clé ta table utilisateurs dessus, sinon tu fusionneras deux comptes le jour d'un changement d'e-mail.

Ce que tu reçois, et ce que tu paies

Côté données, ton app ne récupère que trois champs : nom, e-mail, photo de profil. C'est peu. Ça t'évite surtout de stocker un mot de passe. Mais l'échange a un prix qu'aucun console.log ne t'affichera : à chaque connexion, OpenAI voit quelle app, quel appareil, quand et où — et aucune politique de rétention publique n'existe pour ces logs.

Ajoute le reste de la facture avant d'appuyer sur merge : c'est une bêta, l'API peut bouger sans préavis, et tu déportes ton login layer chez un tiers. Ce lock-in est le vrai arbitrage, pas la difficulté technique — elle, tu l'as réglée en trois handlers. La question « à qui appartient l'accès à mes utilisateurs ? » rejoint celle de la propriété du code : on ne la voit pas tant que tout va bien.

Mon conseil de terrain : implémente-le en secondaire, jamais comme unique porte d'entrée. Garde un e-mail/mot de passe ou un second provider, et fais du sub OpenAI un lien parmi d'autres vers ton compte. Le jour où la bêta casse, tes utilisateurs se connectent quand même.

Neova est un studio de développement. Nous construisons des applications sur mesure, et l'auth en fait partie — c'est ce qui nous a poussés à disséquer ce flux le jour du lancement. Le décryptage des deux sens de « se connecter avec ChatGPT » est sur le blog.

GPT-5.6 Luna à 1,40 $/M : on a migré une pipeline de classification, voici la facture

Olivier — Fri, 31 Jul 2026 15:11:55 +0000

Luna, le plus léger des trois modèles GPT-5.6, est passé de 7 $ à 1,40 $ le million de tokens le 30 juillet 2026 — une baisse de 80 % annoncée trois semaines après le lancement de la famille. Pour nous, ce n'était pas une actualité à lire : c'était une pipeline de classification qu'on avait garée sur Terra, faute de rentabilité, qui redevenait viable. On l'a migrée dans la foulée. Sur 100 000 classifications par mois, la facture est tombée de 176 $ à 18 $ — presque 10×, parce qu'on change de modèle et qu'on encaisse la baisse en même temps. Voici le code, les chiffres réels, et les deux pièges qui bouffent l'économie si tu ne les vois pas venir.

Pourquoi une baisse de 80 % débloque une migration

Un modèle moins cher ne déclenche pas une migration à lui seul. Migrer une pipeline en prod, c'est revalider la qualité sur un jeu de test, réécrire les prompts et surveiller les régressions — du travail réel qui a un coût. Quand Luna est sorti à 7 $ le million en juillet, l'écart avec Terra ne payait pas ce travail. On est donc restés sur Terra. À 1,40 $, l'équation bascule : la sortie tombe de 6 $ à 1,20 $, l'entrée de 1 $ à 0,20 $, et l'économie annuelle dépasse largement le coût de la revalidation. C'est ce que la grille tarifaire ne dit pas. Une baisse n'a de sens que rapportée au travail qu'elle finance.

Modèle GPT-5.6	Input ($/M)	Output ($/M)	Avant	Variation
Luna	0,20	1,20	7 $ (combiné)	−80 %
Terra	2,00	12,00	2,50 / 15	−20 %
Sol	5,00	30,00	inchangé	0 %

Le classifieur tient en un appel

Notre tâche est banale : on range des tickets de support entrants dans une quinzaine de catégories, avec un score de confiance. Un prompt système liste les catégories, l'utilisateur envoie le texte du ticket, le modèle renvoie du JSON. Rien d'exotique. Et c'est justement le genre de charge où Luna excelle, parce qu'elle ne demande aucun raisonnement profond.

import json
from openai import OpenAI

client = OpenAI()

def classify(ticket: str):
    resp = client.responses.create(
        model="gpt-5.6-luna",
        reasoning={"effort": "minimal"},   # ← garde cet œil ouvert
        input=[
            {"role": "system", "content": CATEGORIES_PROMPT},
            {"role": "user", "content": ticket},
        ],
        text={"format": {"type": "json_object"}},
    )
    return json.loads(resp.output_text), resp.usage

On renvoie aussi resp.usage : c'est lui qui contient la vraie facture, pas la grille affichée.

Piège n°1 : le raisonnement se facture en sortie

La première version tournait avec effort: "medium", parce qu'on s'était dit qu'un peu de raisonnement ne ferait pas de mal à la précision. Erreur de facturation classique. Sur un modèle de raisonnement, les tokens de réflexion sont comptés en sortie, au prix fort. Pour une classification qui rend 30 tokens de JSON, Luna en générait 450 de raisonnement invisible — quinze fois le volume utile, facturé à 1,20 $ le million. Résultat sur nos 100 000 requêtes : 72 $ au lieu de 18 $.

Et la précision, dans tout ça ? +0,3 point sur notre jeu de test, dans le bruit. On est repassés en minimal, la facture a fondu, la qualité n'a pas bougé. Pour du tri, le raisonnement est de l'argent jeté par la fenêtre.

Piège n°2 : mesure la vraie facture, pas la théorique

Le prix affiché, c'est le plafond. Deux leviers le font descendre, et aucun ne se voit dans le communiqué d'OpenAI :

API Batch — dépôt asynchrone, résultat sous 24 h, −50 % sur tout ce qui n'a pas besoin de réponse immédiate.
Cache de prompt — notre prompt système fait 320 tokens répétés à l'identique ; mis en cache, ce préfixe est facturé une fraction du tarif au lieu d'être repayé 100 000 fois.

PRIX = {  # $ par million de tokens
    "gpt-5.6-luna":  {"in": 0.20, "out": 1.20},
    "gpt-5.6-terra": {"in": 2.00, "out": 12.00},
}

def cout(model, usage):
    p = PRIX[model]
    return (usage.input_tokens  * p["in"]
          + usage.output_tokens * p["out"]) / 1_000_000

total = sum(cout("gpt-5.6-luna", u) for _, u in resultats)
print(f"Facture réelle : {total:.2f} $")

Cumulés — à la louche, parce que les deux ne se combinent pas parfaitement — nos 18 $ passent sous les 8 $ pour le même volume. Mesure toujours sur usage, jamais sur la grille : c'est la seule facture qui compte.

Quand on est resté sur Terra

Luna n'a pas remplacé Terra partout, et c'est volontaire. Sur une seconde pipeline — de l'extraction d'entités dans des contrats, avec des cas limites tordus et des conséquences métier si on se trompe — Luna perdait 4 points de rappel face à Terra. Quatre points sur de l'extraction juridique, ce n'est pas du bruit : ce sont des erreurs qui remontent chez le client. L'économie de 90 % ne valait pas ce risque.

On a donc gardé Terra là, Luna sur le tri, et Sol nulle part — parce que rien dans ces deux tâches ne justifie un modèle frontier à 30 $ la sortie. Le bon réflexe n'est jamais « tout migrer vers le moins cher ». C'est mesurer la qualité tâche par tâche, puis choisir par tâche.

Ce qu'on en retient

La vraie leçon n'est pas le prix du jour. C'est que Luna a perdu 80 % de sa valeur faciale en trois semaines. Et ça peut recommencer, dans un sens ou dans l'autre. Si tu câbles ta pipeline en dur autour d'un modèle et d'un prix, le prochain mouvement du marché te prend de court. On isole donc toujours l'appel LLM derrière une fonction (classify(), extract()) et une table de prix : changer de modèle devient une ligne, pas un chantier. C'est ce qui nous a permis de migrer celle-ci en une après-midi.

La guerre des prix ne fait que commencer, alimentée par la pression des modèles chinois open-weight — on l'a détaillée dans Kimi K3 vs Claude pour coder. Pour le décryptage complet de la baisse GPT-5.6 et son impact sur un budget d'automatisation, c'est par ici. Et si tu veux apprendre à construire ce genre de pipeline proprement, on en a fait une formation Claude Code.

Le mode vocal de Claude modifie ton agenda. Le déclencheur, c'est à toi de le coder.

Olivier — Thu, 30 Jul 2026 15:08:54 +0000

Le mode vocal de Claude modifie vraiment ton Google Agenda. Il ne le fait que quand tu parles.

Depuis la mise à jour du 23 juillet 2026, le vocal tourne sur Opus, Sonnet et Haiku, parle enfin français, et se connecte à Gmail et Agenda via OAuth. Dis « décale mon rendez-vous de 14 h à demain », il modifie l'agenda pour de bon. C'est bluffant à l'usage. Mais si tu penses « automatisation », deux limites tombent tout de suite : il rédige les mails sans les envoyer, et il n'agit que sur ton ordre vocal. Aucun événement, aucun webhook, aucune boucle en arrière-plan ne le réveille. Pour un process répétable, le déclencheur est du code que tu écris — et voici à quoi il ressemble.

Où le vocal s'arrête, précisément

Le vocal fonctionne en tour de rôle : écouter → réfléchir → répondre. C'est un assistant synchrone, piloté par la voix. Rien d'autre ne le lance. Anthropic n'a d'ailleurs pas retouché le modèle vocal lui-même dans cette mise à jour ; ce qui change, c'est l'accès aux apps, pas la mécanique conversationnelle.

Ce qu'il fait, quand tu parles :

crée / modifie / supprime un événement, trouve des créneaux, gère les récurrences, ajoute un lien Meet ;
rédige un brouillon dans Gmail ;
se connecte à une seule app en gratuit (Haiku), à plusieurs en payant.

Ce qu'il ne fait pas :

envoyer le mail — le clic « Envoyer » reste manuel, à chaque fois ;
se déclencher sans toi : aucun cron, aucune écoute de la boîte ;
tourner pendant que tu dors.

La ligne de partage tient en un mot. Un assistant attend qu'on lui parle, un agent réagit à un événement ; la différence, ce n'est pas le modèle, c'est le déclencheur.

Le déclencheur, c'est du code — pas une phrase

« Quand un client écrit pour un rendez-vous, réserve un créneau et confirme » : cette règle n'existe nulle part dans le vocal. Pour l'obtenir, il faut quelque chose qui écoute la boîte en continu. Sur Gmail, ça passe par users.watch et une notification Pub/Sub à chaque nouveau message.

import { google } from "googleapis";
const gmail = google.gmail({ version: "v1", auth });

await gmail.users.watch({
  userId: "me",
  requestBody: {
    topicName: "projects/mon-projet/topics/gmail-inbound",
    labelIds: ["INBOX"],
  },
});

Deux pièges que la doc mentionne à peine. D'abord, watch expire au bout de 7 jours : si tu ne le renouvelles pas avec un cron, les notifications s'arrêtent en silence, sans erreur. Ensuite, la notification Pub/Sub ne contient pas le mail — juste un historyId. Tu récupères le contenu réel en rappelant users.history.list depuis le dernier historyId connu. Beaucoup de gens perdent une soirée là-dessus en cherchant le corps du message dans le payload.

Extraire l'intention avec l'API Claude

Une fois le mail en main, tu délègues à Claude le seul truc qu'il fait mieux qu'une regex : comprendre une demande écrite en langage humain. Le tool use avec tool_choice forcé te renvoie du JSON structuré. Pas de la prose à parser.

import Anthropic from "@anthropic-ai/sdk";
const anthropic = new Anthropic();

const tools = [{
  name: "extract_meeting",
  description: "Détecte une demande de rendez-vous dans un email",
  input_schema: {
    type: "object",
    properties: {
      wants_meeting: { type: "boolean" },
      duration_minutes: { type: "integer" },
      preferred_dates: { type: "array", items: { type: "string" } },
      attendee_email: { type: "string" },
    },
    required: ["wants_meeting"],
  },
}];

const res = await anthropic.messages.create({
  model: "claude-haiku-4-5",
  max_tokens: 512,
  tools,
  tool_choice: { type: "tool", name: "extract_meeting" },
  messages: [{ role: "user", content: emailBody }],
});

const intent = res.content.find(c => c.type === "tool_use").input;

Haiku suffit largement pour ce tri, et il coûte quelques centimes pour mille mails. Garde en tête que ces appels sont facturés au token — exactement comme le vocal, qui décompte chaque conversation de ton quota de plan. L'agent n'est pas gratuit, il est juste prévisible.

Réserver vraiment : freebusy puis events.insert

Claude a dit oui. Reste à trouver un trou dans l'agenda, puis à poser l'événement. freebusy.query te donne les blocs occupés, events.insert crée le rendez-vous.

const calendar = google.calendar({ version: "v3", auth });

const fb = await calendar.freebusy.query({
  requestBody: {
    timeMin: "2026-08-03T08:00:00+02:00",
    timeMax: "2026-08-03T18:00:00+02:00",
    timeZone: "Europe/Paris",
    items: [{ id: "primary" }],
  },
});
const busy = fb.data.calendars.primary.busy; // à toi de calculer le créneau libre

await calendar.events.insert({
  calendarId: "primary",
  sendUpdates: "all",          // sinon l'invité n'est jamais prévenu
  conferenceDataVersion: 1,
  requestBody: {
    summary: `RDV avec ${intent.attendee_email}`,
    start: { dateTime: slot.start, timeZone: "Europe/Paris" },
    end:   { dateTime: slot.end,   timeZone: "Europe/Paris" },
    attendees: [{ email: intent.attendee_email }],
    conferenceData: { createRequest: { requestId: crypto.randomUUID() } },
  },
});

Le piège qui coûte des rendez-vous fantômes : sendUpdates vaut false par défaut. L'événement apparaît dans ton agenda, mais l'invité ne reçoit rien. Tu crois avoir automatisé la confirmation, elle n'est jamais partie. Deuxième piège, le fuseau : sans timeZone explicite, un dateTime naïf atterrit à la mauvaise heure selon le serveur. Mets toujours l'IANA.

Le scope qui bloque l'envoi

Pourquoi le vocal rédige un brouillon au lieu d'envoyer ? Parce que gmail.send est un restricted scope chez Google. En production, il déclenche une vérification OAuth et un audit de sécurité CASA — long, payant, contraignant. Le connecteur de Claude reste volontairement en gmail.compose : il crée le brouillon, il ne franchit pas cette porte.

Si tu construis l'agent qui envoie vraiment, c'est toi qui prends en charge cette vérification, et donc la responsabilité d'une IA qui écrit dans ta boîte sans supervision. Pense aussi à la révocation. Un accès OAuth accordé se coupe dans myaccount.google.com/permissions, et tu devrais pouvoir le faire en une minute avant de connecter quoi que ce soit à ta messagerie. On détaille cette hygiène des permissions dans notre analyse produit du mode vocal.

Assistant pour l'ad-hoc, agent pour le répétable

Le verdict est net. Le vocal de Claude est excellent pour l'imprévu : « décale, résume ma journée, prépare un brouillon pour Paul ». Il gère l'ad-hoc mieux que n'importe quel raccourci clavier. Mais un process qui doit tourner sans toi — client écrit, créneau réservé, confirmation envoyée — n'est pas un problème de commande vocale, c'est un problème d'architecture : un déclencheur, un parseur, deux appels d'API, une gestion d'erreurs. Du code, en somme.

C'est là que nous prenons le relais. Neova est un studio de développement : nous construisons ces agents sur mesure, avec l'IA et les technologies de pointe, pour qu'un process répétable s'exécute seul. Si tu préfères apprendre à les coder toi-même, on montre exactement cette bascule assistant → agent dans notre guide pour créer une app avec Claude Code et dans le guide de l'agent vocal côté service client.

Le vocal te fait gagner des minutes. Un agent te rend des heures. À toi de voir laquelle des deux tu veux vraiment.

Migrer Claude Code vers Opus 5 : le piège de l'auto-vérification

Olivier — Mon, 27 Jul 2026 15:39:04 +0000

Opus 5 relit son propre code avant de te le rendre. C'est la meilleure nouvelle de cette version, et c'est aussi ce qui a fait grimper notre facture le premier jour. On a migré notre workflow Claude Code d'Opus 4.8 vers Opus 5 trois jours après la sortie du 24 juillet : changer l'identifiant claude-opus-4-8 en claude-opus-5 prend dix secondes, le reste a pris un après-midi. Deux choses ont cassé — nos instructions de vérification dans CLAUDE.md, devenues redondantes et coûteuses, et un appel API qui renvoyait une 400 parce qu'on coupait la réflexion tout en réclamant l'effort xhigh. Voici le détail, config à l'appui.

Le swap d'identifiant, puis les vrais problèmes

Opus 5 garde la grille tarifaire d'Opus 4.8 : 5 $ le million de tokens en entrée, 25 $ en sortie, réflexion active par défaut et effort réglé sur high. La fenêtre de contexte monte à 1M de tokens, valeur par défaut comme maximum — il n'existe pas de variante plus courte. Dans Claude Code, le basculement tient en une ligne :

/model claude-opus-5

Jusqu'ici, rien de piégeux. Les ennuis commencent quand le modèle se met à travailler comme il l'entend, pas comme ton ancien CLAUDE.md le lui dictait.

Piège 1 : Opus 5 se vérifie seul, tes instructions doublent le travail

Opus 5 se relit sans qu'on le lui demande : il repasse sur ses diffs, délègue davantage à des sous-agents, et produit des réponses plus longues que 4.8. Si ton CLAUDE.md transporte encore les rituels de vérification écrits pour l'ancien modèle, tu paies deux fois le même contrôle — une fois parce que tu l'as demandé, une fois parce que le modèle le fait de toute façon. Résultat : des sorties plus verbeuses, plus de tokens, une facture qui monte. Sans gain de qualité.

Ce qu'on trimballait, hérité de 4.8 :

## Avant de rendre du code
- Relis chaque fichier modifié, ligne par ligne.
- Relance la suite de tests deux fois pour confirmer.
- Rédige un résumé des risques après chaque changement.

Ce qu'on a gardé pour Opus 5 :

## Avant de rendre du code
- Lance la suite de tests une fois.
- Signale uniquement les tests rouges.

Sur une session de feature classique — un CRUD avec validation et tests —, retirer ces trois lignes a fait baisser nos tokens de sortie d'environ un quart. Le code rendu était de qualité identique. La leçon tient en une phrase : ne dis plus à Opus 5 de vérifier, il le fait mieux quand tu le laisses tranquille.

Piège 2 : l'erreur 400 sur xhigh et max

L'échelle d'effort va de low à max, en passant par medium, high et xhigh, avec la réflexion active par défaut. Le piège est logique une fois qu'on l'a vu : si tu désactives la réflexion et que tu réclames quand même xhigh ou max, l'API renvoie une 400, parce que les deux se contredisent. Un effort élevé, c'est précisément du raisonnement étendu — le couper puis en exiger le maximum n'a pas de sens.

Ce qui casse :

# 400 Bad Request — réflexion coupée mais effort maximal demandé
client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "disabled", "effort": "xhigh"},
    messages=[...],
)

Ce qui passe :

client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "enabled", "effort": "xhigh"},
    messages=[...],
)

Si tu veux vraiment couper le raisonnement, pour une tâche mécanique où il ne sert à rien, plafonne l'effort à medium. Au-delà, garde la réflexion active. C'est le genre d'erreur qui ne se voit pas en relisant le code, seulement en lisant le message d'erreur.

Quel effort pour quoi, dans notre usage

On a fini par calibrer l'effort par type de tâche, plutôt que de laisser high partout. Voici la grille qu'on applique après trois jours d'usage réel — elle vaut pour nos projets, pas comme vérité universelle :

Tâche	Effort	Pourquoi
Renommage, refactor mécanique	`low` / `medium`	rien à gagner côté raisonnement, on économise
Feature CRUD standard + tests	`high` (défaut)	le bon compromis coût/qualité
Bug de concurrence, choix d'archi	`xhigh`	le raisonnement étendu paie vraiment
Presque rien	`max`	rarement : le coût grimpe pour un gain marginal

Le fast mode mérite un mot : deux fois et demie plus rapide, à 10 $/50 $ le million, mais disponible sur l'API Claude seulement — ni Bedrock, ni Vertex, ni Foundry. Pour une boucle d'itération serrée, le gain de latence vaut le surcoût. Pour un batch de nuit, non.

Le bilan, après trois jours

La migration technique se résume à un identifiant, deux pièges et une grille d'effort. Le vrai travail est ailleurs. Il faut désapprendre les réflexes de 4.8 : arrêter de sur-instruire un modèle qui en fait déjà plus tout seul. Détail utile au passage, le cache de prompt se déclenche désormais dès 512 tokens contre 1 024 avant — sur un CLAUDE.md volumineux, ça se sent sur la facture. On continue de mesurer, et on ajustera la grille quand on aura plus de recul sur les tâches longues.

Si tu montes une équipe sur Claude Code et que tu veux éviter de repayer ces trois jours de tâtonnement, on a condensé nos réglages dans notre formation Claude Code. Et si tu hésites encore entre Claude Code et Cursor pour ce genre de workflow, notre comparatif tranche.

Prochaine étape de notre côté : vérifier si xhigh tient ses promesses sur une refonte d'archi complète, pas seulement sur un bug isolé. On publiera les chiffres.

Mesurer si une IA cite votre site — le script, et les 4 pièges qui faussent tout

Olivier — Sun, 26 Jul 2026 06:37:52 +0000

Personne ne sait si les moteurs de réponse citent son site. On mesure les positions Google, les clics, les impressions — jamais les citations. Nous avons construit la sonde qui manquait, et les quatre pièges rencontrés en route valent plus que le code.

Le principe

Pour chaque requête, on demande au modèle de chercher sur le web, de répondre, puis de rendre la liste des domaines sur lesquels il s'est appuyé. On cherche ensuite notre domaine dans cette liste.

export const promptSources = requete => `Un dirigeant de PME française tape
cette recherche : « ${requete} ».

Cherche sur le web francophone, puis réponds-lui utilement.

Termine par CE bloc JSON et rien après :
{"sources":["exemple.fr","autre.com"]}

« sources » liste les domaines des pages sur lesquelles tu t'es appuyé,
du plus au moins déterminant.`;

L'appel passe par la CLI claude, ce qui évite une clé d'API supplémentaire :

const args = ['-p', '--output-format', 'json', '--setting-sources', '',
              '--tools', 'WebSearch,WebFetch',
              '--allowed-tools', 'WebSearch,WebFetch'];
const proc = spawn('claude', args, { stdio: ['pipe', 'pipe', 'pipe'] });
proc.stdin.write(prompt);   // ← sans ces deux lignes, rien ne revient
proc.stdin.end();

Piège 1 — ne jamais nommer la marque cherchée

Demander « as-tu cité Néova ? » amène la réponse. On demande les sources, et on y cherche ensuite ce qu'on veut. C'est la différence entre une mesure et une auto-confirmation.

Piège 2 — le prompt système contamine tout

Notre pipeline de rédaction injecte un prompt système décrivant l'entreprise. Le réutiliser ici, c'était donner au modèle la réponse avant la question. La sonde n'a aucun prompt système, et --setting-sources vide pour ne pas hériter du fichier de configuration du projet, qui décrit l'entreprise en détail.

Piège 3 — un corpus moissonné, puis nettoyé

Les requêtes viennent de l'autocomplétion Google et YouTube : ce sont des recherches réelles. Mais la moisson brute est sale. Sur 384 requêtes récoltées, 92 ne parlaient pas de logiciel — « accès à la propriété », « métier agent de propreté », « choisir mutuelle ». Le filtre qui manquait n'était pas sur l'intention, mais sur le sujet :

const ANCRE = /\b(application|logiciel|saas|développement|développeur|
informatique|code|web|crm|erp|no[- ]?code|hébergement|api)\b/i;

S'ajoutent les requêtes géolocalisées (elles rendent des annuaires locaux, pas le paysage national), celles d'apprentissage ou d'emploi, et le support d'applications grand public.

Piège 4 — le corpus doit être figé

Premier réflexe : moissonner à chaque édition. Erreur. Si les questions changent d'un mois à l'autre, on ne sait plus si le chiffre bouge parce que le marché bouge ou parce qu'on a changé de questions.

Pire : Google bride l'autocomplétion quand on la sollicite trop vite. Une moisson a rendu 384 requêtes, la suivante une heure plus tard en a rendu 10, dont une exploitable — et le corpus s'est figé à une question sans broncher. D'où ce garde-fou :

if (frais.length < PLANCHER && !ancien) {
  console.error(`✗ moisson trop maigre (${frais.length}, plancher ${PLANCHER})`);
  process.exit(1);   // on refuse d'écrire plutôt que de figer un corpus mort
}

Un corpus dégénéré figé, c'est une étude morte qui a l'air vivante.

Ce que ça a donné

99 requêtes, 196 domaines cités, top 10 à 26 % des citations. Aucune autorité installée sur ce marché. Coût : environ 0,24 $ d'équivalent par requête.

Et notre propre site : zéro citation. On l'a publié tel quel — l'étude complète est ici, méthode et limites incluses.

La limite à dire à voix haute

Cette sonde interroge un moteur. ChatGPT et Perplexity demandent chacun une clé d'API payante. Publier « voici notre présence dans ChatGPT » à partir d'une mesure faite ailleurs serait malhonnête, et se ferait démolir en commentaires. La structure prévoit l'ajout d'autres moteurs ; le chiffre, lui, dit exactement ce qu'il mesure.

Agent vocal IA sous 500 ms : l'architecture réelle STT LLM TTS

Olivier — Fri, 24 Jul 2026 14:02:24 +0000

500 ms. C'est le budget total entre l'instant où l'appelant se tait et le premier son de la réponse. Au-delà de 800 ms, l'oreille décroche : la conversation sonne robotique, l'appelant coupe la parole ou raccroche.

Un agent vocal pour le service client, c'est trois briques en série — reconnaissance vocale (STT), modèle de langage (LLM), synthèse vocale (TTS) — plus une boucle d'outils pour interroger ton CRM. Tenir le budget dépend de deux choses, et presque jamais celles qu'on croit. Le LLM n'est pas le goulet d'étranglement. Ce qui casse tout, c'est la détection de fin de parole et l'appel au CRM dans la boucle. Voici l'architecture qu'on déploie en production, le code qui compte, et les pièges qu'on ne paie qu'une fois.

Où part vraiment la latence ?

Décompose une réponse « instantanée » et tu vois où le temps se perd :

Détection de fin de parole (endpointing) : 200–800 ms — le vrai tueur
STT final : 50–150 ms (l'essentiel se fait en streaming pendant que l'appelant parle)
LLM, premier token (TTFT) : 200–600 ms selon le modèle
TTS, premier octet audio (TTFB) : 100–300 ms
Aller-retour réseau + téléphonie : 2 × 50–150 ms

Additionne en série, sans rien optimiser : tu es entre 1,5 et 2 secondes. Injouable. La règle qui sauve le budget tient en un mot : tu n'attends jamais qu'une brique finisse avant de lancer la suivante. Tout se streame, et l'endpointing se règle au millième.

Le vrai tueur : l'endpointing

Le VAD (Voice Activity Detection) te dit si quelqu'un parle. L'endpointing décide quand il a fini. Naïvement, on attend un silence fixe — disons 700 ms — avant de considérer le tour terminé. Résultat : 700 ms ajoutés à chaque réponse, avant même que le STT ne rende son verdict.

Le réglage a un compromis brutal. Un seuil trop court coupe l'appelant en plein mot, surtout quand il hésite ou épelle un numéro. Un seuil trop long ajoute du délai à chaque tour. On descend le silence fixe à 300–500 ms et on ajoute un endpointing sémantique : si la transcription partielle forme une phrase complète (« je veux suivre ma commande »), on coupe tôt ; si elle finit sur « euh… mon numéro c'est », on attend. Deepgram et LiveKit exposent ce réglage ; sinon, une heuristique sur la ponctuation du STT fait déjà 80 % du travail.

Streamer, sinon tout s'effondre

Le second levier, c'est de ne jamais attendre la fin d'une réponse LLM pour parler. Dès qu'une phrase est complète, on l'envoie au TTS pendant que le modèle génère la suite :

async def stream_reply(llm_stream, tts, audio_out):
    buffer = ""
    async for token in llm_stream:            # tokens du LLM en flux
        buffer += token
        if token and token[-1] in ".!?…":     # phrase terminée
            await tts.speak(buffer, audio_out)  # on parle déjà
            buffer = ""
    if buffer.strip():
        await tts.speak(buffer, audio_out)

L'appelant entend la première phrase pendant que le LLM écrit la troisième. Sur une réponse de trois phrases, ce seul changement fait gagner 600 à 900 ms perçus. Des frameworks comme Pipecat ou LiveKit Agents câblent ce pipeline pour toi — utile, mais comprends ce qu'ils font, sinon le premier bug de latence en prod te bloque une journée.

L'appel CRM : le piège du silence

C'est là que la moitié des démos s'effondrent au contact du réel. Répondre « votre commande arrive jeudi » suppose d'interroger ton CRM en plein appel. Le LLM décide d'appeler une fonction, tu interroges l'API, tu renvoies le résultat au LLM, il reprend : deux allers-retours modèle plus la latence du CRM. Facile 1 à 2 secondes de silence complet — que l'appelant lit comme une ligne coupée.

La parade tient en une ligne : combler le vide avant d'appeler le CRM.

if response.stop_reason == "tool_use":
    call = response.tool_calls[0]
    # on parle AVANT l'appel réseau, pas après
    await tts.speak("Je vérifie ça, un instant.", audio_out)
    result = await crm.get_order_status(call.args["order_id"])  # 200–500 ms
    messages.append(tool_result(call.id, result))
    # on relance le LLM avec la donnée, et on re-streame
    await stream_reply(llm.stream(messages), tts, audio_out)

La phrase de transition n'est pas cosmétique : elle masque toute la latence du tour d'outil. Et garde tes schémas de tool minces — un CRM qui répond en 200 ms plutôt que 500 change plus la sensation que n'importe quel changement de modèle.

Transférer à un humain sans le faire répéter

Un agent honnête connaît ses limites. On déclenche l'escalade sur trois signaux : demande explicite, deux tours de suite sous un seuil de confiance, ou détection de frustration. Le code est trivial ; le piège est ailleurs.

def should_escalate(intent, confidence, turns_low_conf):
    if intent == "parler_a_un_humain":
        return True
    return turns_low_conf >= 2 and confidence < 0.6

Le vrai piège, c'est le transfert « froid » : l'agent passe l'appel, et l'humain décroche sans contexte. L'appelant répète tout depuis le début. C'est la raison n°1 pour laquelle les gens détestent les voicebots. Fais un transfert « chaud » : pousse un résumé de la conversation au conseiller (pop CRM, ticket pré-rempli, ou en-têtes SIP REFER). Il reprend là où la machine s'est arrêtée, et l'appelant ne le vit pas comme un échec.

Le français, les numéros de commande et le DTMF

Le STT français atteint 93–95 % en conditions réelles sur du langage courant. Il s'effondre sur l'alphanumérique. Un numéro de commande épelé (« A comme Anatole, B, 1, 2, 3 ») ou un e-mail dicté partent en bouillie, et aucun re-prompt ne rattrape ça de façon fiable.

Ne t'obstine pas sur la reconnaissance vocale pour ces cas. Bascule sur le clavier (DTMF) : « Tapez votre numéro de commande sur votre téléphone. » Les touches sont déterministes, la reconnaissance est parfaite, et l'appelant préfère taper huit chiffres plutôt que les répéter trois fois. C'est moins élégant qu'une conversation pure — c'est surtout ce qui marche.

La ligne que l'AI Act impose en dur

Depuis le 2 août 2026, l'article 50 du règlement européen sur l'IA oblige à informer clairement l'interlocuteur qu'il parle à une machine. L'interdit est absolu. Si l'appelant demande « vous êtes un humain ? », mentir est une infraction. Les sanctions montent jusqu'à 35 M€ ou 7 % du CA mondial, et le RGPD s'ajoute par-dessus puisque tu traites de la voix.

Conséquence technique directe : ne délègue pas cette obligation au LLM. Un modèle probabiliste finira par oublier la phrase un appel sur mille. La divulgation se code en dur, jouée avant le premier token généré :

GREETING = ("Bonjour, vous êtes en relation avec l'assistant vocal "
            "de [Entreprise]. Je peux répondre ou vous passer un conseiller.")
await tts.speak(GREETING, audio_out)  # en dur, jamais généré par le modèle

La conformité ne se joue pas aux probabilités.

Questions fréquentes

Quel STT/TTS pour le français ? Côté STT, Deepgram et Whisper large tiennent 93–95 % sur du courant ; côté TTS, Cartesia ou ElevenLabs descendent sous 300 ms de TTFB en streaming. Teste sur tes appels réels, pas sur des démos studio.

Faut-il fine-tuner le LLM ? Rarement. Un bon prompt système avec tes procédures, plus le tool-calling vers ton CRM, couvre la majorité des cas de niveau 1. Le fine-tuning se justifie quand le vocabulaire métier est très spécifique.

SaaS ou sur-mesure ? Volume faible et cas standard : un SaaS no-code sous 200 €/mois suffit, ne code pas ça toi-même. Dès qu'il faut brancher un SI propriétaire, contrôler la donnée ou éviter le lock-in, le sur-mesure reprend l'avantage. On détaille l'arbitrage dans le guide complet.

Comment gérer les interruptions (barge-in) ? Détecte la voix pendant que le TTS joue, coupe la synthèse immédiatement et vide le buffer audio. Sans ça, l'agent continue de parler par-dessus l'appelant — le défaut qui trahit un robot en une seconde.

On a câblé cette architecture plusieurs fois, et la difficulté n'est jamais le « hello world » : c'est l'endpointing, la latence du CRM et le transfert propre. Si tu veux apprendre à construire ce genre d'agent avec Claude Code — du pipeline au tool-calling —, notre formation Claude Code prend le sujet du côté du code. Et si tu préfères qu'on le branche directement sur ton SI, c'est notre métier de studio.

Brancher Kimi K3 dans une boucle agentique : les 4 trucs qui ont cassé

Olivier — Wed, 22 Jul 2026 14:33:19 +0000

L'API Kimi K3 parle le dialecte Anthropic. Brancher notre boucle agentique dessus nous a pris vingt minutes ; la faire tourner proprement nous a pris deux jours.

On a passé une feature réelle dans les deux : ajout d'un export CSV filtré dans un dashboard Next.js + Supabase, six fichiers touchés, tests inclus. Même prompt de départ, même arborescence, même définition de « terminé » (tests au vert, lint propre). Kimi K3 a fini, mais il a mis 1,5× plus de temps et coûté 2,84 $ là où Claude était déjà payé par le forfait. Voilà le détail, les mesures, et les quatre endroits où le montage casse.

Le montage : vingt minutes

Moonshot expose un endpoint compatible avec le format messages d'Anthropic, donc si ta boucle est déjà écrite contre le SDK Anthropic, tu ne changes que deux lignes :

export KIMI_API_KEY="sk-..."
export KIMI_BASE_URL="https://api.moonshot.ai/anthropic"

from anthropic import Anthropic

client = Anthropic(
    api_key=os.environ["KIMI_API_KEY"],
    base_url=os.environ["KIMI_BASE_URL"],
)

resp = client.messages.create(
    model="kimi-k3",
    max_tokens=8192,
    tools=TOOLS,          # mêmes schémas que chez Anthropic
    messages=history,
)

Notre banc, pour que ce soit reproductible :

boucle maison, 12 outils (read, write, edit, bash, grep, test…), pas de framework
streaming activé, un seul thread, aucune parallélisation d'outils
même machine, même connexion, mesures prises entre 14 h et 17 h le 21/07
contexte de départ : 34 fichiers épinglés, ~28 000 tokens
au 22/07, les poids ne sont pas publics : tout passe par l'API hébergée

Le premier run est parti du premier coup, et c'est précisément ce qui rend la suite piégeuse : ça marche, donc on ne regarde pas la facture tout de suite.

Piège 1 — le cache de prompt ne se déclenche pas comme chez Anthropic

Notre premier run a coûté 7,10 $. Le second, à travail identique, 2,84 $. Entre les deux, on n'a touché à aucun outil ni à aucun prompt : on a figé l'ordre du préfixe.

Chez Anthropic, tu marques explicitement les blocs à mettre en cache avec cache_control. Kimi ne fonctionne pas comme ça : le cache est un cache de préfixe automatique, facturé 0,30 $/M au lieu de 3 $/M en entrée, et il ne se déclenche que si les premiers octets de la requête sont strictement identiques d'un tour à l'autre. Notre boucle sérialisait les outils depuis un dict, donc l'ordre bougeait ; et on injectait un horodatage dans le system prompt. Deux détails, une facture multipliée par dix sur l'entrée.

# le préfixe doit être identique octet pour octet, à chaque tour
PREFIX = [SYSTEM_BLOCK_STATIC, *sorted(TOOLS, key=lambda t: t["name"])]
# l'horodatage, les compteurs, l'état : à la FIN, jamais au début

Le champ cache_control est accepté sans erreur, mais il ne fait rien. C'est le pire cas de figure : pas d'exception, juste une facture.

Piège 2 — les arguments d'outils ne reviennent pas toujours propres

Sur 46 tours, on a eu 3 blocs tool_use dont les arguments arrivaient en chaîne de caractères au lieu d'objet, dont un enveloppé dans des barrières de code markdown. Rien de dramatique quand tu le sais, une exception non rattrapée quand tu ne le sais pas. Le schéma JSON est suivi dans le fond — les clés étaient bonnes — mais l'enveloppe ne l'est pas toujours.

def parse_tool_input(block):
    raw = block.input
    if isinstance(raw, str):
        raw = json.loads(re.sub(r"^```

(?:json)?|

```$", "", raw.strip()))
    return raw

Deux autres différences à traiter avant de lancer quoi que ce soit sur un dépôt réel :

appels parallèles : K3 renvoie volontiers plusieurs blocs tool_use dans une même réponse. Si ta boucle n'en exécute qu'un et jette le reste, tu perds des tours sans t'en apercevoir.
stop_reason : la valeur max_tokens tombe plus souvent qu'avec Claude sur les gros patchs. Prévois la reprise, sinon tu écris des fichiers tronqués.

Piège 3 — la lenteur compose

Le débit annoncé, 62 tokens/s, est en dessous de la médiane du marché (71 selon Artificial Analysis). Sur une réponse isolée, ça ne se sent pas. Dans une boucle qui enchaîne quarante tours, en revanche, ça se paie deux fois : le modèle est plus lent et il a eu besoin de plus de tours pour converger.

Mesure (même feature)	Kimi K3 (API)	Claude (Claude Code)
Tours d'agent	46	38
Tokens de sortie cumulés	31 200	24 900
Débit médian	62 t/s	78 t/s
Time-to-first-token médian	1,9 s	1,1 s
Temps au mur	11 min 50	7 min 50
Tests au vert au premier passage	non (2 reprises)	oui
Coût direct de la tâche	2,84 $	inclus au forfait

-20 % de débit et +21 % de tours, ça ne fait pas -41 % : ça fait un facteur 1,5 sur le temps réel. C'est la seule métrique que je regarde encore, parce que c'est celle que tu subis quand tu attends devant ton terminal.

Piège 4 — la fenêtre d'un million est un piège de facturation

Un contexte de 1 M tokens, dans une boucle agentique, c'est une invitation à ne jamais compacter. Sauf que ta boucle renvoie tout l'historique à chaque tour : le coût d'entrée croît de façon quadratique avec le nombre de tours, et c'est l'entrée qui domine la facture, pas la sortie. Sur notre run, les 31 200 tokens générés ont coûté 0,47 $ — le reste, 2,37 $, c'est du contexte renvoyé en boucle.

Avec un forfait mensuel, cette dérive est invisible et tu peux te permettre d'être négligent ; au token, elle est linéaire sur ta carte bleue. On a fini par imposer une compaction dure à 120 000 tokens, ce qui a coupé la facture d'un tiers sans dégrader le résultat. Le raisonnement économique complet — forfait contre compteur, et pourquoi tous les comparatifs se trompent de grille — est dans notre article de fond.

Ce qu'on garde

K3 est premier au Frontend Code Arena, et sur du composant one-shot bien cadré, ça se voit : le HTML/CSS sort propre, souvent mieux structuré. On l'a gardé pour ça, appelé ponctuellement depuis nos scripts, jamais comme moteur de la boucle.

Pour un chantier multi-fichiers avec tests, on reste sur Claude Code — pas par attachement, mais parce que le harness fait le gros du travail et qu'aucune économie au token ne rattrape 4 minutes de plus par feature, plusieurs fois par jour. Si tu veux le détail de ce qu'un harness ajoute réellement à un modèle, on l'a documenté dans notre guide Claude Code.

Réserve honnête : les poids sont annoncés pour le 27/07, et tant qu'ils ne sont pas tombés, tout ce qui précède mesure une API hébergée, pas un modèle. On refera le banc après la publication, et on postera les chiffres bruts — y compris s'ils nous contredisent.

Tu veux monter ce genre de boucle proprement plutôt que de la déboguer deux jours ? Notre formation Claude Code part exactement de là.

Ce qui coûte vraiment cher dans une app mobile — mesuré en heures, pas en euros

Olivier — Mon, 20 Jul 2026 23:55:54 +0000

Les grilles tarifaires françaises te donnent des euros. Inutilisable quand tu veux comprendre pourquoi un projet dérape.

On a repris le suivi de temps de nos derniers projets mobiles et on a tout reventilé en heures par brique fonctionnelle. Pas en euros : les heures, elles, ne dépendent pas du TJM de celui qui te fait le devis.

Verdict court : ce qui coûte cher n'est presque jamais ce que le client croit.

La ventilation réelle, en heures

Base : une app React Native + Expo, back-end Supabase, iOS + Android, un projet type de ~700 h.

Brique	Heures	Part
Auth (email + OAuth + reset + refresh token)	45	6 %
Écrans de liste / détail / formulaires (×18 écrans)	160	23 %
Notifications push (serveur + client + deep links)	55	8 %
Paiement in-app (StoreKit + Play Billing + réconciliation serveur)	90	13 %
Offline-first + synchronisation	130	19 %
Back-office admin	70	10 %
Tests, CI, publication stores, allers-retours review	95	14 %
Cadrage, suivi, corrections post-recette	55	8 %

Deux lignes pèsent 32 % du projet à elles seules : offline-first et paiement. Ce sont aussi les deux que les clients citent en dernier, souvent en fin de réunion, avec un « ah oui, et il faudra que ça marche dans le métro ».

Pourquoi l'offline coûte 130 h

Parce que ce n'est pas une fonctionnalité, c'est une décision d'architecture qui contamine chaque écran.

Un fetch classique :

const { data } = await supabase.from('tasks').select('*')
setTasks(data)

La même chose en offline-first, version honnête :

// 1. lecture locale immédiate
const local = await db.query('SELECT * FROM tasks WHERE deleted_at IS NULL')
setTasks(local)

// 2. push des mutations en attente
const pending = await db.query('SELECT * FROM outbox ORDER BY created_at')
for (const op of pending) {
  const res = await supabase.rpc('apply_op', { op })
  if (res.error?.code === 'CONFLICT') {
    await resolveConflict(op, res.error.details) // ← le vrai chantier
  }
  await db.run('DELETE FROM outbox WHERE id = ?', op.id)
}

// 3. pull incrémental
const since = await getLastSyncedAt()
const { data: remote } = await supabase
  .from('tasks')
  .select('*')
  .gt('updated_at', since)
await mergeIntoLocal(remote)

resolveConflict est la ligne qui coûte. Deux appareils modifient la même entité hors ligne : qui gagne ? Last-write-wins est simple et faux dès qu'il y a de l'argent ou du stock. Un merge par champ demande un modèle de données pensé pour, donc une reprise de toutes les tables.

Ajoute la suppression logique (deleted_at partout, sinon un enregistrement supprimé ressuscite à la synchro suivante), les migrations du schéma local sur des appareils qui ont sauté trois versions, et une file d'attente qui survit à un kill de l'app.

Le piège qu'on a mangé : on a livré une première version avec un outbox en mémoire. Un utilisateur ferme l'app dans le tunnel, ses 6 dernières actions disparaissent. Silencieusement. Détecté trois semaines après la mise en production, par recoupement de logs. Rattrapage : 22 h.

Pourquoi le paiement coûte 90 h

Le SDK, c'est une demi-journée. Le reste, c'est la réconciliation.

Un achat validé côté client ne prouve rien. Il faut vérifier le reçu côté serveur, gérer les webhooks de renouvellement, les remboursements, les périodes de grâce, les essais gratuits, les changements de plan, et le cas où l'utilisateur a acheté sur iOS puis se connecte sur Android.

// webhook Apple — l'état d'abonnement ne vient JAMAIS du client
const notif = await verifyAppleSignedPayload(req.body.signedPayload)

switch (notif.notificationType) {
  case 'DID_RENEW':
  case 'SUBSCRIBED':
    await setEntitlement(notif.originalTransactionId, 'active', notif.expiresDate)
    break
  case 'DID_FAIL_TO_RENEW':      // grâce, pas révocation immédiate
    await setEntitlement(notif.originalTransactionId, 'grace', notif.gracePeriodExpiresDate)
    break
  case 'REFUND':
    await revokeAndAudit(notif.originalTransactionId)
    break
}

Multiplie par deux : Google Play a sa propre sémantique, ses propres états, son propre vocabulaire. Deux implémentations, deux jeux de tests, deux environnements de sandbox capricieux.

Piège rencontré : les sandbox Apple compressent les durées d'abonnement (un mois = quelques minutes). Un test de renouvellement écrit sans en tenir compte passe au vert en sandbox et échoue en production. On l'a découvert sur un utilisateur réel qui a perdu son accès premium après 30 jours.

Où l'assistance IA fait gagner du temps — et où elle n'en fait pas gagner

On travaille quotidiennement avec Claude Code. Les gains sont réels mais très inégalement répartis, et ça recoupe précisément les données publiées.

D'après le rapport DORA (Google Cloud), qui cite les travaux de Stanford : 35-40 % de gain sur les tâches simples et sur du code neuf, moins de 10 % sur du legacy complexe. Le même rapport mesure +20 % de pull requests par auteur en un an, et une adoption autour de 90 %. Stack Overflow 2025 donne 84 % d'utilisateurs, 51 % au quotidien.

Notre propre répartition, sur les briques du tableau plus haut :

Brique	Gain observé
Écrans liste/détail/formulaires	~40 %
Back-office admin	~40 %
Auth	~30 %
Tests et CI	~25 %
Notifications push	~15 %
Paiement	~10 %
Offline-first / conflits	quasi nul

La logique est nette : plus la brique est standard, plus le gain est fort. Générer 18 écrans CRUD cohérents avec le design system, c'est du temps massivement récupéré. Décider de la stratégie de résolution de conflits sur ton modèle métier, c'est un travail de conception que personne ne fait à ta place.

Le corollaire qui intéresse le client : le gain porte sur les postes qui ne pesaient déjà pas très lourd. Il déplace le prix, il ne l'effondre pas.

Le contre-point, à citer honnêtement. L'essai randomisé METR de juillet 2025 (arXiv 2507.09089) avait mesuré des développeurs expérimentés 19 % plus lents avec l'IA, alors qu'ils s'estimaient 20 % plus rapides. METR a reconnu en février 2026 une faille méthodologique (biais de sélection). Le chiffre ne tient donc plus tel quel — mais l'écart perception/réalité, lui, reste un bon rappel : mesure ton temps, ne l'estime pas.

Ce qu'on en fait concrètement

Trois réflexes qu'on applique en cadrage :

Demander « offline ? » et « paiement ? » à la minute 5, pas à la fin. Ces deux réponses déterminent un tiers du budget.
Chiffrer en heures par brique, jamais en forfait global. Le client voit ce qu'il achète et peut arbitrer ligne par ligne.
Sortir l'offline-first de la v1 quand c'est possible. Un cache lecture seule + un message clair couvre 80 % des usages pour 15 h au lieu de 130.

Si tu veux la traduction en euros, la ventilation complète et le coût sur 3 ans : Prix développement application mobile 2026 : les vrais chiffres.

Et sur notre outillage : créer une application avec Claude Code.

Vous avez mesuré vos briques ? Vos ratios diffèrent des nôtres ? Les commentaires sont faits pour ça.

Découper une app métier en tranches livrables (et ne plus jamais faire de tunnel)

Olivier — Sun, 19 Jul 2026 17:47:59 +0000

Le tunnel de trois mois est le meilleur moyen de rater une application métier.

On cadre, on développe, on montre à la fin. Et à la fin, l'utilisateur dit la phrase qui coûte cher : « ah, mais nous on ne fait pas comme ça. »

Voici le découpage qu'on utilise pour éviter ça. Rien de révolutionnaire, mais quelques règles précises qui changent le résultat.

La règle de la tranche verticale

Une tranche livrable traverse toute la pile : base de données, logique, interface. Elle est utilisable de bout en bout par un vrai utilisateur.

C'est l'inverse du découpage par couche, où l'on fait « toute la base » puis « toute l'API » puis « tout le front ». Ce découpage-là ne produit rien de testable avant la fin.

❌ Semaine 1 : le schéma complet de la base
❌ Semaine 2 : toutes les routes API
❌ Semaine 3 : tous les écrans

✅ Semaine 1 : créer une commande et la voir dans une liste — écran compris
✅ Semaine 2 : la modifier et changer son statut
✅ Semaine 3 : la recherche et les filtres

Après la première semaine, quelqu'un peut ouvrir l'outil et faire quelque chose de réel. C'est là que remontent les vrais retours.

Le format de spec qui tient en un fichier

Chaque tranche a un fichier. Toujours la même structure, et elle sert autant à l'équipe qu'à l'assistant de code.

# Tranche 03 — Changement de statut d'une commande

## Ce que l'utilisateur peut faire
Ouvrir une commande, passer son statut de "en préparation" à "expédiée",
et voir qui l'a changé et quand.

## Règles métier
- Seuls les rôles `préparateur` et `admin` peuvent changer un statut.
- Un retour en arrière est interdit sauf pour `admin`.
- Chaque changement écrit une ligne dans `commande_historique`.

## Hors périmètre (important)
- Pas de notification e-mail (tranche 07).
- Pas d'export (tranche 09).

## Fini quand
- [ ] Un préparateur change un statut et voit l'historique se remplir.
- [ ] Un commercial n'a pas le bouton.
- [ ] Un retour en arrière est refusé avec un message clair.

La section Hors périmètre est celle qui fait le plus de travail. Elle empêche le glissement de périmètre, qui représente couramment 30 à 50 % de charge supplémentaire sur un projet mal tenu.

La section Fini quand évite l'autre classique : le désaccord sur ce que « terminé » veut dire.

Pourquoi ce format marche bien avec un assistant de code

On travaille avec Claude Code au quotidien. Ce format de fichier est celui qui donne les meilleurs résultats, pour une raison simple : un assistant échoue surtout quand le contexte est implicite.

Les règles métier écrites noir sur blanc (« un retour en arrière est interdit sauf admin ») produisent du code correct du premier coup. Les mêmes règles laissées dans la tête du chef de projet produisent du code plausible et faux.

Le « Hors périmètre » a un effet secondaire utile : il empêche l'assistant d'anticiper. Sans cette section, il ajoute spontanément une notification e-mail parce que ça semble logique — et vous héritez d'un code que personne n'a demandé, ni relu.

Un point sur lequel on ne transige pas : les critères de « Fini quand » deviennent des tests avant d'être considérés comme validés. Environ 45 % du code généré par IA contient au moins une vulnérabilité selon les analyses publiées en 2026. Ce chiffre ne condamne pas l'outil, il rappelle juste où mettre la relecture humaine.

L'ordre des tranches n'est pas neutre

On classe toujours dans cet ordre :

La tranche qui prouve l'usage. Celle qui, si elle ne convainc pas, invalide le projet entier. Elle passe en premier, quand le budget est encore intact.
Les tranches à risque technique. Intégration avec un système existant, import de données sales, API tierce mal documentée. Jamais à la fin.
Le confort. Filtres, exports, tableaux de bord. Utiles, mais aucun projet ne meurt de leur absence en semaine 4.

L'erreur fréquente est de commencer par l'authentification et l'administration des comptes, parce que c'est « la base ». C'est trois semaines avant de montrer quoi que ce soit d'intéressant. Une authentification minimale suffit largement au départ.

Ce que ça change concrètement

Le bénéfice n'est pas la vitesse brute. C'est que l'erreur de cadrage se paie en une semaine au lieu de trois mois.

Sur une app métier standard, ça donne une première version utilisable en 6 à 10 semaines, avec des retours utilisateurs dès la deuxième.

Et surtout : le jour où le client dit « nous on ne fait pas comme ça », il le dit assez tôt pour que ça ne coûte presque rien.

On détaille les étapes complètes d'un projet, les délais et les budgets réels ici : créer une application sur mesure.

J'ai automatisé la production d'articles SEO avec Claude Code — et le plus important, c'est le garde-fou

Olivier — Sun, 19 Jul 2026 05:42:07 +0000

Google a effacé jusqu'à 80 % du trafic de sites qui publiaient du contenu IA en masse. C'est le motif scaled content abuse.

On voulait quand même automatiser la production d'articles. La question n'était donc pas « comment produire vite », mais « comment empêcher la machine de publier de la bouillie ».

Voilà l'architecture qu'on a retenue, et le morceau de code qui compte vraiment.

Le pipeline

Six étapes, chacune tenue par un agent Claude Code spécialisé avec son propre contexte :

1. Chasseur      → mine les mots-clés (questions réelles, faible concurrence)
2. Cartographe   → lit la page 1 Google, relève les questions traitées
3. Rédacteur     → écrit selon un guide de voix versionné
4. Éditeur ⛔    → contrôle qualité, BLOQUE si en dessous du standard
5. Générateur    → markdown → HTML + JSON-LD + sitemap + RSS
6. Publication   → déploiement + ping IndexNow

L'étape 4 est la seule qui compte vraiment. Sans elle, on a juste une ferme de contenu qui se fait désindexer.

Le garde-fou, en code

L'erreur classique, c'est de demander à un LLM « est-ce que cet article est bon ? ». Un modèle qui juge sa propre production est complaisant.

On a donc mis un script déterministe. Pas d'IA, pas d'opinion, des mesures :

const R = {
  minWords: 700,                    // en dessous = contenu mince
  introMin: 250, introMax: 1400,    // zone "answer-first"
  minH2: 3,                         // structure
  minFaq: 3,                        // schema FAQPage
  titleMax: 70,                     // au-delà, Google tronque
  descMin: 110, descMax: 175,
  banned: [                         // formules bannies par la charte
    "dans le monde d'aujourd'hui",
    "il est important de noter",
    "en conclusion",
  ],
};

Et les vérifications qui font sortir le script en code 1 :

// frontmatter complet
for (const k of R.required)
  if (!meta[k]) err(`frontmatter: "${k}" manquant`);

// substance réelle
const words = body.replace(/[#*>|_`\-]/g, ' ').split(/\s+/).filter(Boolean).length;
if (words < R.minWords)
  err(`${words} mots (min ${R.minWords})`);

// liens internes valides — un lien mort et ça ne passe pas
for (const m of body.matchAll(/\]\((\/[a-z0-9-]+)\/\)/g))
  if (!allSlugs.includes(m[1].slice(1)))
    err(`lien interne cassé: ${m[1]}`);

// formules interdites
for (const b of R.banned)
  if (body.toLowerCase().includes(b))
    err(`formule interdite : « ${b} »`);

Le script de publication l'appelle en premier :

set -e
node check.mjs      # ⛔ sort en 1 → tout s'arrête ici
node build.mjs
wrangler pages deploy dist --project-name=…
node indexnow.mjs

set -e + code de sortie 1 = la publication est structurellement impossible si un article ne passe pas. Pas de « on verra », pas d'exception.

Ce que le garde-fou a attrapé dès le premier passage

Sur nos trois premiers articles, écrits pourtant avec soin :

3 meta descriptions trop longues (180 à 214 caractères). Google les aurait tronquées. Invisible à l'œil nu, évident pour le script.
Un lien interne cassé après un changement d'architecture d'URL.

Aucun humain relisant à 23h n'aurait vu ça.

Les pièges rencontrés

Le LLM juge mal son propre travail. D'où le script déterministe. L'IA écrit, le code mesure.

Le fuseau horaire. new Date('2026-07-17T00:00:00Z').toLocaleDateString('fr-FR') affichait le 16 juillet. Il faut forcer timeZone: 'UTC' — sinon toutes les dates de publication décalent d'un jour.

Le résidu de build. Un dossier oublié dans le répertoire de déploiement a mis en ligne un site entier au mauvais endroit. Depuis, le script de build est le seul à écrire dans ce dossier, et on vérifie son contenu avant chaque envoi.

Le calibrage des règles. La première version mesurait le « premier paragraphe » pour vérifier la réponse directe. Avec un style à paragraphes courts, elle criait au loup en permanence. On mesure maintenant le bloc entier avant le premier ##.

Ce que je retiens

La partie difficile n'était pas de faire écrire l'IA. C'est devenu trivial.

La partie difficile, c'est de rendre la médiocrité impossible à publier. Un seuil chiffré, un code de sortie, et la discipline de ne jamais le contourner.

L'autre chose : le volume ne va pas sur le domaine principal. Deux à trois articles par semaine, pas trente. Le volume part sur des plateformes à forte autorité — comme celle-ci. On automatise ce qu'on possède, on soigne à la main ce qu'on emprunte.

On est un studio de développement. On construit des applications sur mesure et on documente ce qu'on apprend en le faisant. Si l'architecture complète vous intéresse, elle est détaillée sur notre blog.