Fusionner les appels de fonction : 270 appels évités, latence réduite, oublis IA éliminés

Hier, en faisant l'analyse complète de ma consommation de tokens, j'ai eu une révélation inattendue.

Ce n'était pas le nombre de tokens qui posait problème — c'était le nombre d'appels. Sur une journée de travail normale, mes agents Claude avaient déclenché 270 appels de fonction qui n'auraient pas dû exister. Pas des appels inutiles — des appels redondants, qui faisaient deux ou trois fois la même chose au lieu d'une.

En les fusionnant, j'ai économisé ~138 200 tokens bruts et 45 invocations agent dans la journée. Mais ce qui m'a vraiment surpris, c'est un bénéfice que je n'avais pas anticipé : l'IA oubliait moins.

Voici ce que j'ai trouvé.

Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.

L'insight de départ : chaque appel a un coût invisible

Quand on optimise les tokens, on pense naturellement au contenu — raccourcir les prompts, migrer les instructions dans le RAG, activer le prompt caching. C'est ce que j'avais fait dans l'article précédent, avec une réduction de 70 % du contexte fixe.

Mais il y a une autre dimension que j'avais sous-estimée : le nombre d'appels.

Chaque appel de fonction — qu'il s'agisse d'une requête SQL, d'une commande bash, ou d'un appel d'outil Claude — génère un overhead :
- Tokens input + output (même pour un appel simple : ~200-500 tokens)
- Latence réseau (50ms à 300ms selon l'outil)
- Interruption du raisonnement de l'IA (c'est là que les oublis se produisent)

Ce dernier point est contre-intuitif. Quand un agent doit enchaîner 3 appels SQL séquentiels au démarrage, il y a 3 "pauses" dans son raisonnement. Entre chaque appel, le contexte actif peut dériver — et certaines informations des étapes précédentes sont moins "saillantes" dans la fenêtre d'attention. En pratique, ça se traduit par des oublis : l'agent perd de vue une contrainte établie deux appels plus tôt.

Les 6 fusions déployées — et leurs résultats

1. Bundle de démarrage agent : 3 requêtes SQL → 1

Le coût le plus élevé était invisible parce qu'il se répétait à chaque invocation d'agent.

Avant : chaque agent exécutait 3 requêtes psql séquentielles au démarrage :

getAgentLearnedSkills()    # ~500 tokens
getWorkflowSteps()         # ~500 tokens
getMacroDomainFor()        # ~500 tokens

Après : une fonction PostgreSQL agent_startup_bundle(agent, session) retourne les trois en un seul appel.

Sur 45 invocations mesurées dans la journée :

2. Enregistrement + logging : 2 requêtes SQL → 1

Chaque routage d'agent déclenchait deux opérations distinctes : enregistrer la tâche dans agent_tasks, puis logger le routage dans une table séparée.

Avant :

const taskId = await registerAgentTask(agent, title, context)
await logRouting(agent, session, taskId)

Après :

const taskId = await registerAndLog(agent, session, title, context)

45 appels économisés, ~22 500 tokens. Plus important : l'agent ne "coupait" plus son raisonnement initial pour deux opérations administratives.

3. Pre-workflow : SESSION_ID + watchdog en 1 appel

Au démarrage de chaque session de travail, deux variables d'environnement devaient être initialisées séparément.

Avant :

_WD_SLUG=$(date +%Y%m%d-%H%M%S)
# initialisation watchdog séparée...

Après :

PREWF=$(bun pre-workflow.ts --command agent --context "...")
SESSION_ID=$(echo "$PREWF" | jq -r '.session_id')
export ERROR_WATCHDOG_FILE=$(echo "$PREWF" | jq -r '.watchdog_file')

Un seul appel, deux résultats. 45 appels économisés sur la journée.

4. Seed de skills : 3 commandes → 1 avec flags intégrés

Chaque fois qu'un agent crée un nouveau skill appris, trois opérations manuelles s'enchaînaient :

bun seed-single-agent.ts --skill learned-foo --learned-from mgrr-agent-bar
bun propagate-skill.ts --skill learned-foo --origin mgrr-agent-bar
rm -rf ~/.claude/skills/learned-foo

Après :

bun seed-single-agent.ts --skill learned-foo --learned-from mgrr-agent-bar \
  --propagate mgrr-agent-bar --cleanup

Gain modeste sur la journée (3 skills seedés = 6 appels), mais l'ergonomie est transformée : l'agent ne peut plus oublier de propager ou de nettoyer.

5. LSP enforcement : rediriger les lectures coûteuses

Ce n'est pas une fusion à proprement parler, mais le principe est identique : remplacer plusieurs opérations coûteuses par une seule, précise et rapide.

Un Read complet d'un fichier TypeScript de 500 lignes coûte ~5 000 tokens et prend 200-2 000ms. Un appel documentSymbol (LSP) sur le même fichier retourne la structure complète en ~500 tokens et 30ms.

Les hooks LSP déployés ont redirigé 16 opérations sur la journée :

L'économie de latence est aussi significative : LSP à 50ms vs Read à 300-2 000ms.

6. git-summary.sh : 3 commandes git → 1 script

Avant chaque commit, 3 commandes git s'exécutaient en parallèle :

git status    # ~200 tokens
git diff      # ~400 tokens
git log       # ~200 tokens

Après :

bash ~/.claude/scripts/git-summary.sh > /tmp/git-summary.txt && tail -80 /tmp/git-summary.txt

Avec 34 commits déployés dans la journée : 68 appels économisés, ~6 800 tokens.

Le tableau consolidé

Le bénéfice inattendu : l'IA oubliait moins

Les tokens économisés sont réels, mais sur un abonnement Max, l'impact financier direct est marginal. Ce qui a vraiment changé, c'est deux choses.

La latence. Le bundle de démarrage seul a éliminé 13,5 secondes de latence cumulée sur 45 invocations. Sur une journée de travail intensive avec des dizaines d'agents en parallèle, ça se traduit par un flux de travail nettement plus fluide.

Les oublis. C'est l'observation qui m'a le plus surpris. Avant les bundles SQL, j'observais régulièrement un pattern : l'agent démarrait, exécutait ses 3 requêtes initiales, puis "oubliait" une contrainte établie dans la première. En réduisant 3 appels à 1 au démarrage, je lui ai donné un contexte plus dense et moins fragmenté. Les informations critiques (learned skills, étapes du workflow, domaine macro) arrivent en une seule réponse structurée, pas en trois fragments séparés par des interruptions d'attention.

Les LLMs traitent les tokens dans leur fenêtre de contexte — mais l'attention n'est pas uniforme. Un token loin dans la fenêtre reçoit moins d'attention qu'un token récent. Chaque appel de fonction intercale du "bruit" entre les informations importantes. Moins d'appels = moins de fragmentation = moins d'oublis.

En pratique, cela signifie moins de re-prompting, moins de "rappelle-toi que tu dois..." dans les instructions, et des agents qui terminent leurs tâches avec plus de cohérence.

Ce que j'aurais dû faire dès le départ

L'erreur courante est de concevoir les agents en mode "exploration" — chaque besoin d'information génère un nouvel appel. C'est naturel quand on prototype, mais catastrophique à l'échelle.

La règle que j'aurais dû appliquer dès le début : concevoir les appels de démarrage comme un contrat d'interface. Qu'est-ce que l'agent a besoin de savoir au démarrage ? Regrouper ces besoins en un seul appel, structuré, qui retourne tout ce qui est nécessaire.

C'est exactement ce que fait agent_startup_bundle() : learned skills, étapes du workflow, et domaine macro — en un seul appel PostgreSQL, une seule réponse JSON, un seul moment d'attention.

La même logique s'applique à tous les workflows répétitifs : si vous faites toujours A puis B dans cet ordre, créez AB(). Les deux gains — tokens et cohérence de l'IA — suivent automatiquement.

Projection hebdomadaire

En extrapolant sur 5 jours de travail similaire :

Le coût évité reste modeste (~0,04 $/jour sur les tokens pondérés). La vraie valeur est dans la réduction du toil : moins de re-prompting, moins d'agents à relancer parce qu'ils ont "oublié", moins de tokens gaspillés à rappeler des contraintes déjà établies.

Pour aller plus loin

• 6 semaines de RAG — comment j'ai réduit ma consommation de tokens Claude de 70 % — les stratégies structurelles de réduction du contexte fixe
• Prompt caching Anthropic : analyse complète — exploiter le cache serveur pour multiplier votre débit effectif
• Rate limit 429 Anthropic en multi-agent — quand les tokens économisés déterminent combien d'agents vous pouvez lancer en parallèle

Qui suis je ?

Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.

J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.

Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.

L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.

La technologie, les méthodes, le management sont le cœur de mes compétences.

Vous pouvez me faire confiance sur ces points là.

Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr

Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100 % IA.

​