Maintenant qu’on commence à voir des agents s’insérer dans notre quotidien. En tout cas dans le mien. J’utilise le harnais Hermes avec Codex où les modèles de Mistral. J’ai des difficultés à interagir avec ces plateformes avec ces agents, car derrière les URLs que je peux leur partager se trouve tout un tas de mesures hostiles à mes nouveaux outils.

Clairement ce n’est pas le sens de l’histoire, même si je comprends la nécessité de monétiser ces contenus ou de se protéger d’un trafic trop important et de maîtriser leur exfiltration. J’ai la sensation qu’il va falloir faire évoluer, dans leur intérêt et le nôtre, les pratiques pour trouver un nouveau compromis.

Sans aller plus loin dans la réflexion sur les business models ou autres, il y en a trop de différents, on peut vite voir que ce qui va intéresser un agent c’est la matière brute.

Sur une marketplace c’est le produit, le prix, la description. Sur des articles de presse, au moins un titre et un résumé.

Toutes les plateformes ne sont pas prêtes à partager autant et les stratégies pour le faire ne sont pas évidentes. Pourtant je pense qu’elles vont être forcées de le faire pour faciliter la navigation parallèle des agents.

Est-ce qu’on va généraliser les MCP ? Est-ce qu’on va rediriger le trafic des agents vers une vue .md ? Est-ce qu’on va avoir des URLs portant une partie du contenu ?

Chaque site web fournissant un MCP ou un moyen d’accès dédié n’est pas envisageable. Je crois que les URLs sont toujours le meilleur moyen de naviguer. Est-ce que lorsqu’on se présente comme un agent, via un header par exemple, on est redirigé vers une URL qui contient l’URL principale et quelques informations utiles pour susciter la navigation ? Pourquoi pas. Il ne faut pas oublier que pour la plupart des ressources en ligne, le but c’est quand même d’être découvertes.

Est-ce qu’on aura des plateformes intermédiaires qui feront ce travail ? Je pense que les deux approches sont possibles.

Une autre solution repose sur la production d’extensions d’URLs qui contiennent une partie du contenu pour décrire ce qu’il y a derrière. J’imagine qu’il est possible d’encoder le contenu pour simplifier le partage avec des IA.

Je sais pas dans quel sens le vent va tourner, mais je suis prêt à parier qu'il tournera et qu'il faudra que ces plateformes acceptent d'être consommé par des agents autonomes, au moins pour la partie emergée de leur iceberg de données.

Tu maîtrises et ton agent préféré a la main sur le plan que tu as crafté avec amour pendant des heures, il tourne, longtemps. Et maintenant, que faire ? Prendre un café, faire du sport, dormir ? Non, tu as été entraîné pendant 15 ans à bosser comme un idiot pendant 8 heures, pas question de rester les bras croisés dès qu'un agent fait ton boulot d'avant. Tu vas donc multitasker : ouvrir une autre feature, mettre à jour de la doc, revoir un test qui date de trois semaines... mais tu te heurtes à un mur. Ton agent est occupé. Tu ne veux pas le déranger. Tu veux lancer un nouveau truc sans cloner une seconde fois ton repo.

Tu vas utiliser git worktree. C'est ton nouveau meilleur ami.

Pourquoi un worktree ?

Parce que tu veux rester dans le même dépôt, garder les mêmes remotes, et travailler sur une autre branche ou expérimentation pendant qu'un agent continue d'écrire du code sur la branche principale. Créer un worktree, c'est comme ouvrir une nouvelle fenêtre sur ton repo. C'est une copie complète qui pointe vers une autre branche.

Tu fais :

git worktree add ../mon-prochain-truc feature/autre-chose

Tu te retrouves avec un dossier ../mon-prochain-truc, tu y ouvres un nouveau terminal, tu peux commencer du code, des docs, une revue de tests… l'agent continue à tourner là où tu es resté.

Le petit truc surprenant, mais terriblement évident, c'est qu'il faut créer ce répertoire en dehors de l'arbre courant actuellement géré par git. D'où le ../. Ce n'est pas une espèce d'environnement interne ou autre, c'est vraiment une copie ailleurs qu'il faut penser à nettoyer.

Comment je l'utilise

1. Je réserve les worktrees aux tâches courtes (doc, tests, ticket de bug). L'agent est déjà parti sur la branche principale et j'ai pas la largeur d'esprit de lancer plusieurs gros changements en même temps.
2. Je crée un worktree vers une branche dédiée au même niveau que mon repo courant, par exemple <monrepo>-<mabranche>.
3. J'ouvre un autre terminal, je travaille, je commit, je pousse, et je reviens sur la branche principale quand j'ai besoin d'évaluer ou réintégrer ce que l'agent a généré.

Quand j'ai fini, je supprime le worktree :

git worktree remove ../mon-prochain-truc

Le dossier disparaît, mais le travail reste sur la branche associée et ça, c'est royal. Plus qu'à push !

Quelques garde-fous

• Fais attention aux fichiers non suivis : un worktree a ses propres modifications. Comme toujours, commit ou stash avant de supprimer le worktree.
• Tu peux ouvrir plusieurs worktrees, mais garde en tête que chaque branche a son propre HEAD. Ne mélange pas les chemins de build ou les environnements virtuels sans faire attention.
• Si tu utilises un agent pour merger ou rebaser, laisse-le terminer avant de supprimer le worktree.

Dans ce monde où la hustle culture est reine, git worktree te donne les pleins pouvoirs pour la productivité infinie, mais aussi pour une belle explosion de charge mentale. On parlera de cette problématique dans le prochain post. Pense à t'abonner à la newsletter, garde cette astuce près de toi, va à ton rythme et fais attention à ta santé.

À la base, ce n’était pas un projet de SaaS. Juste une tentative de résoudre un problème que je voyais partout : les dashboards existent, mais les gens n’y vont pas.

Pourquoi ? Des logiciels trop compliqués, des licences qui coûtent un bras, et tout simplement le fait qu’il faut déjà savoir où les trouver.

Dans les petites structures, la donnée finit souvent dans Google Sheets ou Excel. Ça marche… jusqu’au moment où tout le monde s’emmêle, où les versions divergent, et où plus personne ne sait quel chiffre est le bon.

Dans les plus grosses, c’est l’inverse : plateformes data, outils de BI, équipes dédiées. C’est solide, mais lourd, lent, et sous le contrôle parfois flou de ce qu’on appelle la data gouvernance — une science assez inexacte. Et malgré tout, les équipes continuent à demander les chiffres dans Slack ou par mail.

Le point commun, c’est que l’accès à la donnée reste compliqué.

De mon côté, je suis de moins en moins convaincu par le modèle “tu veux un chiffre → va ouvrir un outil”. J’ai plutôt envie que la donnée arrive là où on échange déjà.

C’est le choix que j’ai fait pour EZD il y a deux ans. Tu configures des dashboards, et les chiffres te sont envoyés dans Slack, par mail, ou ailleurs. Pas besoin d’aller les chercher. Pas besoin d’apprendre un nouvel outil pour les consulter.

La solution est en production, utilisée par quelques clients qui en sont satisfaits. J’espère pouvoir parler de leur expérience ici prochainement.

L’objectif n’est pas de réinventer la BI. J’essaie juste de la rendre un peu plus banale, un peu plus accessible, un peu plus utilisée.

Créer ce qu’on appelle de la boring tech : un logiciel que tu oublies, qui ne cherche pas à t’enfermer dans son écosystème, mais qui fait simplement son travail discrètement et efficacement. C’est une autre manière de voir la technologie, à laquelle je tiens beaucoup.

Pour l’essayer, il suffit de créer un compte sur https://ez-dashboard.com

Je suis à la recherche de feedbacks pour développer cette idée plus largement. Les quotas en free sont volontairement assez bas. Si tu veux tester plus sérieusement, envoie-moi un message à quentin@ez-dashboard.com, je pourrai débloquer un peu plus.

Bonne fin d’année 2025.

On a fait un bond en avant massif dans l’architecture de ces systèmes. Aujourd’hui, ils produisent enfin la valeur qu’on espérait depuis la sortie de ChatGPT. Est-ce que cette valeur compense les investissements consentis ? Difficile à dire. L’avenir nous le dira. Fin 2025, l’intégration la plus convaincante reste néanmoins celle des copilotes de programmation. La valeur est immédiate, mesurable, et il est logique que le secteur ait d’abord investi là où il était le plus mature. Claude Code est bluffant, Codex aussi, et même Vibe de Mistral est très agréable à utiliser.

Maintenant qu’on en est là, la question devient évidente : quelle est la suite ?

Est-ce que les agents vont devenir toujours plus autonomes et aller plus loin seuls ? Ou est-ce qu’on va continuer dans la voie ouverte par les agents de code, qui exposent chaque étape, chaque action, et permettent à un opérateur humain de corriger, d’ajuster, de valider ?

De mon point de vue, l’autonomie totale n’est pas pour tout de suite, sauf pour des tâches très connues, très maîtrisées et déjà bien balisées. En revanche, je pense que le principe du Human-in-the-Loop que l’on retrouve dans les agents de codage va se diffuser très rapidement dans d’autres secteurs.

Qu’est-ce qui caractérise les agents HITL ?

Les agents peuvent agir sur leur environnement. Via des sorties structurées et l’appel de fonctions, ils proposent des actions concrètes. En leur laissant itérer sur les conséquences de leurs propres actions, on leur donne une forme d’autonomie partielle.

C’est exactement ce que font les agents de codage. La vraie question est donc : pourquoi réserver ce type d’interaction au développement logiciel ? Pourquoi ne pas proposer les mêmes patterns pour d’autres métiers ?

Un project manager pourrait utiliser un agent pour organiser des tâches, planifier des dépendances, préparer des communications ou déclencher des mails en fonction des délais. Évidemment, je ne laisserais pas un agent faire tout seul. Il ne comprendra pas tous les aspects subtils du métier.

Et c’est précisément là que l’humain entre dans la boucle. Le Human-in-the-Loop ne consiste pas à brider l’agent. Il s’agit de concevoir une expérience dans laquelle l’agent pousse ses capacités au maximum, mais dans un cadre contrôlé, sous la supervision de l’humain pour lequel il travaille.

Ces systèmes ont, selon moi, une caractéristique clé : ils permettent à l’agent de prendre des risques sans s’engager. Autrement dit, l’agent doit disposer d’un espace de travail sans impact tant que l’humain n’a pas validé le résultat. Dans le monde du code, cela se matérialise très bien par une merge request : l’agent propose, le développeur décide. Pour un project manager, cela pourrait être la génération d’un graphe de dépendances, avec des tâches et des échéances, qui ne devient réel qu’une fois validé et partagé.

Je pense que cette étape est fondamentale. Le Human-in-the-Loop n’est pas l’opposé de l’autonomie : c’en est un préalable.

Les agents progresseront vers plus d’autonomie grâce à deux facteurs principaux :

• la confiance progressive des opérateurs dans les actions proposées, qui justifie l’investissement dans ces systèmes ;
• l’accumulation de données issues d’usages réels, permettant d’améliorer continuellement les agents sur des tâches ciblées.

Je pense que nous sommes aujourd’hui suffisamment matures pour commencer à développer ce type de solutions.

J’en ai fait l’expérience avec ez-dashboard, un projet sur lequel j’ai développé un agent capable d’opérer directement dans le navigateur de l’utilisateur. Travailler à ce niveau d’intégration m’a convaincu que ce modèle est applicable bien au-delà du développement logiciel.

Je suis convaincu que 2026 verra émerger des exemples très concrets d’interactions homme–agent réellement utiles. Moins spectaculaires que les promesses d’autonomie totale, mais beaucoup plus crédibles et adoptables.

Développer des applications d'entreprise ça nécessite d'échanger des informations sensibles qu'on ne souhaite pas transmettre au modèle de langage.

MCP est vu comme l'usb-c du monde agentique et c'est très cool, mais comment on fait quand on a besoin de passer des tokens, des informations utilisateurs et que ces informations ne doivent pas passer par le modèle de langage?

Si des informations sensibles transitent par le modèle de langage, alors il y a un risque qu'un utilisateur mal intentionné puisse contourner toutes les instructions et éventuellement les modifier. Et ça c'est pas génial.

Dans la suite de l'article on va montrer une approche avec un client utilisant OpenAI agent SDK et un serveur fastmcp. Le client et le serveur MCP tournent en local, mais dans l'idée, les deux tournent dans un environment que vous maîtrisez (pas sur le poste de l'utilisateur).

Un peu de contexte.

Je travaille pour une marketplace, je veux aider nos clients à retrouver leur commande. J'ai des APIs pour ça et j'aimerais bien que mon agent puisse gérer des questions comme "Où en est ma commande #123 ?".

Un agent est capable de comprendre la question, de détecter le numéro de commande et d'appeler un outil MCP pour renvoyer les informations.

Voyons un peu de code tout cru. On retrouve côté serveur quelque chose comme ça:

ORDERS = [
    {
        "id": "#12345",
        "user_id": "user-123",
        "status": "shipped",
        "customer": "Jean Dupont",
        "address": "12 rue de la soif, Toulouse, France"
    },
    {
        "id": "#67890",
        "user_id": "user-456",
        "status": "delivered",
        "customer": "Jeanne Martin",
        "address": "46 avenue de la joie, Bordeaux, France"
    }
]

@mcp.tool
def find_order(order_id: str) -> str:
    for order in ORDERS:
        if order["id"] == order_id:
            return f"Order {order_id} is {order['status']} to {order['customer']} at {order['address']}"
    return f"Order {order_id} not found"

Et côté client quelque chose comme ça:

USER = "user-123"

async with MCPServerStreamableHttp(
    name="Streamable HTTP Python Server",
    params={
        "url": "http://localhost:8000/mcp",
        "timeout": 10,
    },
) as server:
    agent = Agent(
        name="My Agent",
        instructions="You're a customer support agent, use your tools to find the order status.",
        mcp_servers=[server],
        model_settings=ModelSettings(tool_choice="required"),
        model="gpt-4.1-mini"
    )

    result = await Runner.run(agent, "Where is my order #67890")
    print(result.final_output)py

Si vous avez une galère pour comprendre ce code ou des interrogation sur comment démarrer, mettez un commentaire sous l'article.

Si vous utilisez votre agent avec un serveur MCP en local vous verrez que ça va bien marcher, mais peut être un peu trop car qu'importe si la commande est lié à l'utilisateur du client. Aucun contrôle n'est fait côté serveur pour le moment.

Les options

Plusieurs pistes sont envisageables.

• Utiliser les query params d'abord lors de la définition du MCPServerStreamableHTTP et récupérer les informations côté serveur en inspectant l'url*.*
• Créer les paramètres côté serveur et les réécrire à la volée en utilisant un tool côté client qui s'occupe d'initialiser et d'appeler MCP lui même.
• Signer un token JWT, passer les informations en claims et utiliser le header authorization pour passer les infos.

Le premier c'est ok, mais pas hyper securisé. Le second c'est totalement contreproductif, pourquoi utiliser MCP si on part là dessus. Le troisième si le contexte à partager est important c'est pas génial, mais c'est securisé et plutôt bien supporté. On part là dessus!

Correction du code serveur

On va utiliser un code HMAC pour sécuriser la transmission des informations. Pour ça côté serveur on va simplement réutiliser ce que fastmcp propose à savoir un JWTVerfier.

SECRET = os.getenv("JWT_SECRET", "default-secret-key-change-me")

verifier = JWTVerifier(
    public_key=SECRET,
    issuer="order-agent",
    audience="order-api",
    algorithm="HS256"
)

mcp = FastMCP("MCP Order Server", auth=verifier)

Et on modifie le tool pour tirer partie de l'access_token qui va être décodé par le verifier. A chaque appel, ce middleware va vérifier qu'il y a bien un JWT transmis, vérifier qu'il est fiable et transmettre les infos pour que les handlers puisse y accéder.

On va donc aussi modifier le code du tool MCP pour vérifier que l'utilisateur est bien fourni.

@mcp.tool
def find_order(order_id: str) -> str:
    access_token = get_access_token()
    if not access_token:
        raise ValueError("Access token is missing")

    claims = access_token.claims
    for order in ORDERS:
        if order["id"] == order_id and claims["sub"] == order["user_id"]:
            return f"Order {order_id} is {order['status']} to {order['customer']} at {order['address']}"
    return f"Order {order_id} not found"

A noter que les informations qu'on veut transmettre sont dans les claims et qu'on peut maintenant faire confiance au client. C'est la clé secrete, qu'il faut partager secrètement avec le client, qui garantie que les informations transmises sont fiables.

Correction du client

Côté client on va simplement chiffrer les informations que l'on veut transmettre. Ici on va utiliser le user_id qu'on va mettre dans le champ sub vu qu'on soumet la demande pour cet utilisateur.

SECRET = os.getenv("JWT_SECRET", "default-secret-key-change-me")
USER = "user-123"

payload = {
    "sub": USER,
    "exp": datetime.datetime.now(datetime.UTC) + datetime.timedelta(hours=1),
    "aud": "order-api",
    "iss": "order-agent"
}

token = jwt.encode(payload, SECRET, algorithm="HS256")

Ce token qu'on a créé, on va simplement le passer en header de l'appel HTTP.

async with MCPServerStreamableHttp(
    name="Streamable HTTP Python Server",
    params={
        "url": "http://localhost:8000/mcp",
        "timeout": 10,
        "headers": {"Authorization": f"Bearer {token}"}
    },
)

Et voilà, c'est tout.

Conclusion

Le design est ok, c'est pas foufou car on doit chiffrer un token à chaque appel, si on veut faire de la réutilisation on peut aussi mais ça demande un peu plus de logique.

1. Par contre c'est complètement stateless, il suffit de partager la clé secrète par variable d'environnement et on n'a aucune autre dépendance. Pas de session, rien.
2. On peut embarquer le context utilisateur dans les claims au-delà du sub, très pratique si vous avez des informations qui ne sont pas forcément sensible mais qui n'ont pas d'intérêt à être transmis dans le contexte du modèle de langage comme des rôles ou des préférences utilisateur.
3. FastMCP fait le job, très peu de lignes de code.

Alors, c'est pas différent de ce qu'on peut faire en SOA, donc c'est pas très novateur. Par contre, maintenant vous avez une solution si vous avez besoin de transmettre des informations de contexte entre votre client et un serveur MCP!

[Veille Technique] Rust / Python interop

Je ne me suis pas entraîné depuis un moment. La tête dans le guidon, j'ai mis la veille technique de côté un peu trop longtemps à mon goût.

En lisant le code de nanochat de Karpathy, je me suis rendu compte que j'étais un peu largué. Rien de mieux qu'aller se casser les dents sur projet pour mettre les idées dans le bon ordre.

Cet article va résumer une partie de mes sur l'interopérabilité Rust vers Python. Il y a 10 ans j'ai fait la même chose en C vers Python, c'était fun, voyons un peu comment les choses ont évolués depuis.

La méthode employée est un classique, un terminal, un éditeur et je fonce. Ici je vais essayer une autre approche, je vais vous dire tout ce qui s'est passé, plutôt que vous donner une recette toute faite.

Mise en place

Je vais faire des prédictions de séries temporelles. Je vais démarrer en python, gérer l'entraînement et les prédictions dans un bout de code rust et les servir en python.

L'environnement :

• Python 3.13.7
• uv 0.8.13
• rustc 1.89.0

J'ai créé un dossier pyseries et initialisé un projet avec uv init et directement dans le repertoire j'ai créé un projet rust avec cargo new pyseries-rs.

Découverte de pyo3

Si j'en suis là, c'est parce qu'en lisant nanochat j'ai découvert pyo3 et je me suis dit que c'était génial. Karpathy l'utilise pour son tokenizer et en un coup d'oeil on distingue très bien comment sont décrit les modules, les fonctions etc. Donc on va l'essayer et voir ce que ça donne.

Si vous n'avez pas envie de lire cet article et d'aller vite, il suffit de lire la doc de pyo3. Je crois quand même que c'est bien de voir ce qui s'est passé de mon côté. Vous allez gagner de précieuses heures de mise en place.

Quand on fait un cargo new pyseries-rs, on crée un template pour un exécutable et pas une lib. Donc je vais ajouter les dépendances pour pyo3 et faire une lib.

En regardant la doc je découvre qu'on peut faire varier le crate-type pour définir une *cdylib**.*Le nom est cryptique mais il signifie que c'est une bibliothèque de liens dynamique (les fameuses .dll sur windows ou .so sous linux).

[package]
name = "pyseries-rs"
version = "0.1.0"
edition = "2024"

[lib]
name = "pyseries-rs"
crate-type = ["cdylib"]

[dependencies]
pyo3 = { version = "0.26.0", features = ["extension-module"] }

Il y a des pièges ici, je vous en reparle plus loin.

Un peu de code maintenant

On va reprendre bêtement (deuxième piège) celui de la doc et faire un round de compilation.

Dans mon lib.rs je glisse l'exemple.

use pyo3::prelude::*;

#[pyfunction]
fn sum_as_string(a: usize, b: usize) -> PyResult<String> {
    Ok((a + b).to_string())
}

#[pymodule]
fn string_sum(m: &Bound<'_, PyModule>) -> PyResult<()> {
    m.add_function(wrap_pyfunction!(sum_as_string, m)?)?;
    Ok(())
}

On reconnaît des choses intéressantes. D'abord les annotations pyfunction et pymodulesemblent indiquer qu'on décrit des artefacts python.

Si on regarde de plus près on voit que la fonction sum_as_string est classique, à part qu'elle retourne un type PyResult.

La deuxième fonction est un peu plus déroutante. Elle reçoit une référence de module en entrée et on lui ajoute la fonction annotée pyfunction. Il y a une macro wrap_pyfunction! au milieu qui doit cacher la complexité du binding.

Bonjour Maturin

En avançant dans la doc je retrouve maturin , que j'avais vu rapidement dans le pyproject.toml de nanochat. Je comprend maintenant que c'est un outil de build pour aider à la mise en oeuvre de la compilation, des liens et de toute la magie noire pour rendre python et rust interopérables.

On l'installe et j'initialise le projet

uv add maturin
uv run maturin init

Et c'est l'échec (on va en avoir quelques uns, c'est le but de l'article)

💥 maturin failed
  Caused by: `maturin init` cannot be run on existing projects

Notre projet existe déjà, si je redémarre un projet dans le futur je commence avec maturin. Je vais continuer en manuel en attendant.

Dans le pyproject.tomlje vais rajouter le build-system (inspiré de nanochat)

[build-system]
requires = ["maturin>=1.7,<2.0"]
build-backend = "maturin"

[tool.maturin]
module-name = "pyseries_rs"
bindings = "pyo3"
python-source = "."
manifest-path = "pyseries-rs/Cargo.toml"

Alors, plusieurs choses ici, car j'ai fais ça progressivement.

• Si on ne met pas la configuration [tool.maturin] on va pas forcément bien cibler le Cargo.toml.
• En python les modules n'ont pas de tiret, j'ai donc mis un pyseries_rs et c'est le début de la catastrophe. Vous allez voir.

Ma configuration au point je vais utiliser la commande uv run maturin develop . Au bout de quelques essais pour produire le pyproject.toml ci-dessus j'obtiens une compilation

Built pyseries @ file:///Users/quentin/code/pyseries
Installed 1 package in 1ms
🔗 Found pyo3 bindings
🐍 Found CPython 3.12 at /Users/quentin/code/pyseries/.venv/bin/python
📡 Using build options bindings from pyproject.toml
Audited 1 package in 1ms
   Compiling pyo3-build-config v0.26.0
   Compiling pyo3-ffi v0.26.0
   Compiling pyo3-macros-backend v0.26.0
   Compiling pyo3 v0.26.0
   Compiling pyo3-macros v0.26.0
   Compiling pyseries_rs v0.1.0 (/Users/quentin/code/pyseries/pyseries_rs)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.98s
⚠️  Warning: Couldn't find the symbol `PyInit_pyseries_rs` in the native library. Python will fail to import this module. If you're using pyo3, check that `#[pymodule]` uses `pyseries_rs` as module name
📦 Built wheel for CPython 3.12 to /var/folders/ld/mzw0q0c541q94y5hpzttqqhm0000gn/T/.tmpi8eC3a/pyseries-0.1.0-cp312-cp312-macosx_11_0_arm64.whl
✏️ Setting installed package as editable
🛠 Installed pyseries-0.1.0

Plein d'info ici:

• J'ai du python 3.12 au lieu de 3.13, ça vient d'uv et de mes contraintes, tant mieux.
• Le code rust à été compilé dans l'opération
• Le package rust créé une wheel qui est immédiatement installée comme editable dans le projet.
• Et : ⚠️ Warning: Couldn't find the symbol `PyInit_pyseries_rs` in the native library. Python will fail to import this module. If you're using pyo3, check that `#[pymodule]` uses `pyseries_rs` as module name

L'alerte est préoccupante, je comprend que le nom de la fonction annotée*#[pymodule]* est importante. Il me faut donc la renommer. J'ai aussi renommé tout côtéCargo.toml pour être 100% sur de pas avoir de problème avec les tiret.

#[pymodule]
fn pyseries_rs(m: &Bound<'_, PyModule>) -> PyResult<()> {
    m.add_function(wrap_pyfunction!(sum_as_string, m)?)?;
    Ok(())
}

On recompile avec uv run maturin develop. Plus d'alerte, comportement nominal.

Test final

On va simplement utiliser le REPL de l'installation python de l'environnement virtuel.

uv run python
>>> import pyseries_rs
>>> pyseries_rs.sum_as_string(1, 2)
'3'

Ça marche ! Maturin nous a fait une wheel python, l'a installé le module dans l'environnement virtuel d'uv. Si je relance uv run maturin develople module rust est mis à jour.

Conclusion

C'est génial, je ne m'attendais pas à ce que ce soit aussi peu contraignant de démarrer un projet comme ça. J'ai souvenir qu'il fallait faire plus d'effort pour obtenir un résultat similaire en C. Des efforts surtout liés au build et à la configuration de la librairie pour faire un wheel.

Au moment où j'écris, je n'ai pas entamé la suite, la librairie pour faire des prédictions. J'espère pouvoir proposer la suite rapidement. GPT generated image

Mon hypothèse, c'est que, quelle que soit la capacité du modèle, si la qualité du contexte est faible (imprécis, faux ou à côté de la plaque...), alors la réponse ne sera pas satisfaisante.

C'est pourquoi travailler sur le prompt et utiliser un modèle de raisonnement puissant n'est que le début de l'histoire quand on veut améliorer la qualité des agents. Il faut bien évidemment ne laisser aucune marge d'erreur dans la récupération d'informations, que ce soit via des techniques de RAG ou, plus simplement, via les informations transmises par les outils.

Ce qu'on appelle les outils , ce sont des programmes que le modèle de langage demande à son programme hôte d'exécuter pour obtenir des informations, effectuer un calcul ou appliquer une modification.

Lorsqu'on construit un outil, la majorité d'entre nous (développeurs) se contentent, par exemple, d'envoyer aux agents le JSON brut des API en espérant que le modèle de langage devinera le sens de chaque champ. Ça fonctionne... jusqu'à ce que les imperfections qui ruinent l'expérience apparaissent.

Prenons un exemple : j'ai un outil qui me permet de récupérer le statut d'une commande depuis une API.

Une réponse typique de cette API est la suivante :

{
   "internal_id": "1234",
   "customer_reference": "#ORD-154-15",
   "status": "PAID",
   "delivery_date": "2025-07-15",
   "risk_refund": "HIGH"
}

Imaginons qu'une requête soit : Quand est-ce que mon colis va être livré ? et qu'on se serve de cette API pour répondre. Ça signifie qu'on va injecter cette réponse dans le modèle.

Premier problème : il y a des informations qu'on ne veut absolument pas montrer au client. Or tout ce qui est ajouté dans le contexte du modèle de langage est accessible par le client, y compris des informations sensibles comme risk_refund, et éventuellement le statut ou l'identifiant internal_id. Le champ risk_refund pose un problème de sécurité, et l'identifiant interne doit rester interne.

On peut commencer par supprimer ces informations pour obtenir une réponse qui ne transmet plus de données sensibles :

{
   "customer_reference": "#ORD-154-15",
   "status": "PAID",
   "delivery_date": "2025-07-15",
}

Maintenant, il faut garder à l'esprit qu'on échange avec un modèle de langage. Son interface, c'est du texte : ce texte sera utilisé pour former des tokens, lesquels serviront à générer la suite de la réponse. Pour mettre toutes les chances de mon côté, je vais donc reformater la sortie pour fournir une explication textuelle de la situation de la commande :

Commande #ORD-154-15, payée, sera livrée le 15 Juillet 2025.

Ce changement est important : transformer le document JSON en texte ajoute du contexte, du vocabulaire et un ton. Avec un template Jinja, il est assez simple de transformer la sortie JSON.

Exemple:

{# order_summary.j2 #}
{% set status_map = {
    "PENDING": "en attente de paiement",
    "PAID":    "payée",
    "CANCEL":  "annulée"
} %}

{% set date_parts = order.delivery_date.split('-') %}
{% set mois_fr = ["", "janvier", "février", "mars", "avril", "mai", "juin", "juillet", "août", "septembre", "octobre", "novembre", "décembre"] %}
Commande {{ order.customer_reference }}, {{ status_map.get(order.status, order.status) }}, sera livrée le {{ date_parts[2]|int }} {{ mois_fr[date_parts[1]|int] }} {{ date_parts[0] }}.

Arrive ensuite la spécialisation : en fonction du statut, je vais transmettre les informations de manière différente.

Quelques exemples :

*Commande #ORD-154--15, en attente de paiement.*Les informations de livraison seront fournies après réception du paiement. *Commande #ORD-154--15, payée.*Votre colis est en cours de préparation et sera expédié dans les 24 h. *Commande #ORD-154--15, annulée.*Aucun débit n'a été effectué et la commande est maintenant clôturée. *Commande #ORD-154--15, en attente de paiement.*Les informations de livraison seront fournies suite au paiement.

Avec cette méthode, le contexte est transmis sans information superflue, et on peut s'attendre à des réponses précises même avec les modèles de langage les moins performants. En revanche, cela demande plus d'énergie : il faut concevoir une couche de présentation des données textuelles spécialement pour les modèles de langage.

Si vous investissez massivement dans les agents, cette manière d'exposer vos données est certainement un aspect clé de votre investissement.

Le contrôle d'accès et les agents

Considérant que les agents sont des systèmes utilisant des modèles de langage pouvant invoquer des programmes en autonomie, à un moment donné on souhaite les laisser accéder à des systèmes dont l'accès est limité.

La vaste majorité des logiciels en ligne sont soumis à des contrôles pour vérifier que les utilisateurs qui s'y connectent ont bien le droit de consommer ou modifier leurs propres ressources.

Comment permettre à des agents d'accéder à ces ressources sans risques pour la sécurité?

Cet article ne va pas vous donner toutes les clés pour y arriver mais quelques bases pour démarrer et progresser sur le sujet.

Comme je travaille pour une marketplace en ligne, on va utiliser un petit exemple sur le thème des commandes

from demo.models import Order, User

USERS = [
    User(id=0, email="alpha@demo.com"),
    User(id=1, email="beta@demo.com"),
]

ORDERS = [
    Order(id=0, user_id=0, model="battery", quantity=4, price_cts=7499),
    Order(id=1, user_id=1, model="shampoo", quantity=1, price_cts=1000),
]

class MarketplaceService:
    def __init__(self, trusted_user_id: int):
        self.users = USERS
        self.orders = ORDERS

        if not self.get_user(trusted_user_id):
            raise ValueError("User does not exists")

        self.trusted_user_id = trusted_user_id

    def get_order(self, id: int) -> Order:
        order = next(filter(lambda o: o.id == id and o.user_id == self.trusted_user_id, self.orders), None)
        if not order:
            raise ValueError("Order not found")
        return order

    def get_user(self, id: int) -> User:
        user = next(filter(lambda u: u.id == id, self.users), None)
        if not user:
            raise ValueError("User id not found")
        return user

On va créer un agent pour gérer l'accès à cette donnée en langage naturel. De nombreux frameworks existent déjà, pour vous dire à l'heure où j'écris, aws vient d'en sortir un dans la même veine.

De mon côté après avoir créé ma propre interprétation basée sur le papier REACT: SYNERGIZING REASONING AND ACTING IN LANGUAGE MODELS j'ai fini par me retourner sur l'implémentation proposée par OpenAI dans son agents-sdk.

from textwrap import dedent

from agents import Agent
from demo.tools import find_order_by_id
from demo.models import DemoContext

agent = Agent[DemoContext](
    name="orders",
    instructions=dedent(
        """
            Help the user to find their order information in the database.
            Tool is available to help you retrieve the data.
        """
    ),
    model="gpt-4.1-nano",
    tools=[
        find_order_by_id
    ]
)

Pour sécuriser l'accès, il faut faire attention à la fonction déclarée dans tools. Elle permet de lire le contenu d'une commande via son identifiant. On peut imaginer d'autres manières d'accéder aux données, l'exemple sera toujours pertinent.

Vous noterez que l'agent prend en charge un *Context.*C'est un objet qui vit dans l'interpréteur python et qui ne sera pas partagé avec le modèle de langage.

Vous pouvez y attacher des informations sensibles et maîtriser sa mise à jour à deux moments:

• à l'initialisation lorsque l'agent est instancié
• dans les fonctions appelée par les modèles de langage via lefunction calling

C'est là que nous allons intervenir. Nous voulons sécuriser que l'utilisateur connecté ne puisse accéder qu'a ses informations. Ce que supporte le service décrit plus haut.

Pour transmettre au service l'identifiant de l'utilisateur, nous utiliserons le Context via un champ trusted_user_idqui sera disponible dans chaque fonctions appelée par l'agent. Pour ça il faut inspecter la description de la fonction appelée.

from textwrap import dedent
from agents import function_tool, RunContextWrapper

from demo.service import MarketplaceService
from demo.models import DemoContext

def get_service(trusted_user_id: int) -> MarketplaceService:
    return MarketplaceService(trusted_user_id)


@function_tool
async def find_order_by_id(wrapper: RunContextWrapper[DemoContext], id: int) -> str:
    """
    Find an order given its integer identifier

    Args:
        id (int): integer identifier of an order

    Returns:
        str: a representation of the order for the agent
    """

    user_id = wrapper.context.trusted_user_id
    service = get_service(user_id)

    try:
        order = service.get_order(id)
        price = round(order.price_cts / 100, 2)
        return dedent(
            f"""
                Order ID: # {order.id}
                Model: {order.model}
                Price: {price}
            """
        )
    except:
        return "Impossible to retrieve the order"

Vous pouvez voir que l'identifiant de l'utilisateur est extrait du Context et qu'il sert à récupérer le services en l'initialisant à la volée. Rien n'empêche de le récupérer autrement si nécessaire.

La fonction construite ainsi garantie qu'il est impossible de récupérer via le service les commandes d'un autre utilisateur. Qu'importent les techniques de jailbreak qui pourraient être utilisées par un utilisateur malveillant.

L'identifiant de l'utilisateur utilisé pour l'accès contrôlé n'est jamaismanipulé par le modèle de langage.

Pour mettre en musique les exemples ci-dessus vous pouvez utiliser cette fonction.

async def main(user_id: int):
    context = DemoContext(
        trusted_user_id=user_id
    )
    answer_1 = await Runner.run(
        starting_agent=agent,
        input="Give me the order 0",
        context=context
    )

    print(answer_1.final_output)

    answer_2 = await Runner.run(
        starting_agent=agent,
        input="Give me the order 1",
        context=context
    )

    print(answer_2.final_output)

Je laisse à vos soins le fait d'étendre cette approche. Si vous voulez retrouver le code utilisé dans cette démonstration vous pouvez le retrouver sur mon compte Github. Secure data access with openai agents-sdk

Retour d'expérience sur l'escalade avec des LLM : tests et ajustements

Cette semaine, j'ai travaillé sur des agents de réponse automatique pour répondre à des questions générales sur nos services et les problèmes rencontrés dans l'entreprise. L'objectif est de rendre possible l'accès à de l'information en instantané sans pour autant prendre le risque de raconter n'importe quoi.

C'est dans ce cadre que j'ai développé un mécanisme d'escalade. C'est à dire le fait que l'agent qui produit une réponse automatique arrive à tirer la sonnette d'alarme pour dire de lui même qu'il ne peut pas répondre.

Je ne vais pas rentrer dans le design de nos systèmes multi-agent aujourd'hui, mais il faut assumer qu'on séquence l'utilisation de différents modèles pour créer la réponse la plus adaptée à l'utilisateur.

Méthode #1 : tout dans un seul prompt

Au départ, j'ai voulu tester une approche simple : tout gérer dans un seul prompt. Le modèle générait la réponse et je faisais en même temps une vérification rapide de sa qualité. Quelque chose comme, "write an answer and if no answer seems relevant for reason x or y suggests an escalation"

Le problème, c'est que cette méthode n'était pas optimale. Le modèle avait trop de choses à gérer en même temps : répondre à la question, intégrer le contexte de documents suite à une étape de retrieval et vérifier la qualité de la réponse. Cela a donnée de bons résultats, de moins bons. Disons qu'on s'intéressait pas forcément à l'escalade à ce moment là.

Mais le sujet de l'escalade est devenu important et il fallait plus de marge de manoeuvre.

Méthode #2 : découper, mais des réponses imprécises

Pour adapter cela, j'ai testé une approche plus stricte où je voulais découper le processus. L'idée était de s'assurer que le modèle couvrait bien le sujet avant même de générer la réponse. Si la question n'était pas suffisamment couverte par les documents, je renvoyais la demande à un humain.

Elle avait l'avantage (trop tôt) de sembler plus économe en ressources car elle évite la génération d'une réponse.

Mais cette méthode a posé un nouveau problème : le modèle a commencé à générer des réponses imprécises ou incomplètes. Par exemple, si la langue de la question ne correspondait pas à celle des documents fournis, ou si les documents ne couvraient pas le sujet, le modèle refusait strictement de proposer une réponse pour escalader.

C'était honnêtement une vrai tête de mule. Difficile à calibrer.

J'ai pas mal douté qu'il faille revenir sur le découpage, mais en expliquant le problème à une collègue, j'ai compris que je faisais les choses de travers.

Méthode #3 : générer d'abord, évaluer ensuite

J'ai donc pris un autre chemin. Plutôt que de bloquer tout en amont, j'ai laissé le modèle générer sa réponse, pour finalement évaluer la réponse ensuite. L'évaluation est bien plus efficace, et c'est flagrant ! En générant d'abord, on donne de la liberté au modèle. Ensuite, on peut juger de la pertinence de la réponse, et si nécessaire, activer l'escalade vers un humain. Cela permet de mieux contrôler le processus sans sacrifier la réactivité.

Même si cette approche semble plus efficace pour l'instant, il faut encore la tester à l'échelle pour voir si elle tient la route dans des conditions réelles. Ce qui fait vraiment la différence, c'est de laisser d'abord les agents essayer de répondre. L'évaluation finale se fait après coup, pour juger si la réponse mérite d'être désactivée et envoyée à un humain. Cette méthode permet de garder de la souplesse tout en filtrant les erreurs importantes au dernier moment, sans trop de rigidité en amont.

Conclusion

En bref, laisser le modèle répondre d'abord et évaluer ensuite semble être la bonne approche. Ça offre plus de flexibilité et permet un meilleur contrôle des escalades. Il reste à tester à grande échelle, mais les premiers résultats sont prometteurs.

Texte corrigé avec chatgpt.com

Ils m'épargnent des tâches répétitives et m'aident à me concentrer sur ce qui compte : explorer des idées, vérifier qu'elles tiennent la route, aller à l'essentiel. Ce sont des alliés précieux. Ils apportent des perspectives neuves, des angles auxquels je n'avais pas pensé. Ils clarifient, structurent, accélèrent.

Je ne suis pas perfectionniste. Ce qui m'intéresse, c'est produire, avancer, creuser des concepts et créer des choses qui fonctionnent. Grâce à ces outils, je sors du code propre sans y passer des heures.

Le gain est net. J'ai au moins doublé ma productivité. J'apprends plus vite, je fais moins d'erreurs. Mes projets avancent à un rythme soutenu, et en parallèle, ma maîtrise des outils et des concepts progresse.

Mais ce n'est pas sans conséquences. Ce qu'on faisait avant en une demi-journée peut être bouclé en une heure. Ce qui prenait une semaine parfois prend une journée. Le temps dégagé ne reste pas vide longtemps : il se remplit naturellement par des tâches plus complexes. Ce sont des problèmes qui demandent réflexion, créativité, concentration. C'est un rythme différent, exigeant.

Ce mode de travail me convient. J'apprécie les défis intellectuels, mais ce n'est pas le cas de tout le monde. La profession va devoir s'adapter à un modèle où les tâches simples disparaissent et où le cœur du métier devient la résolution de problèmes complexes.

L'intelligence artificielle ne remplace pas le développeur. Elle amplifie ce qu'on est capable de faire. Elle pousse à aller plus loin, plus vite. Mais pour en tirer le meilleur, il faut accepter de changer de rythme et d'aborder le travail autrement.

Je n'ai pas envie de discuter avec des machines à café

Est-ce que dans 4 ans, on continuera à écrire "stp" à ChatGPT et attendre la fin du petit effet streaming du contenu pour avoir nos réponses? Est-ce qu'on aura dépassé cette phase de hype autour des modèles de langages qui lâchent leur prose au compte goutte alors qu'on attend tranquillement devant notre PC ?

Dans 4 ans, j'espère qu'on pourra simplement demander un "café fort" en entrant dans la cuisine, sans avoir à formuler une commande détaillée pour que la machine démarre la préparation. Donner des ordres à ma machine à café en parlant tout haut me conviendrait bien.

Demander des choses en parlant, ça marche. L'humanité a utilisé le langage pour transmettre des ordres pendant des millénaires. Pour commander les machines, nous utilisons des langages de programmation, pratiques et formels, mais pas accessibles à tous. La solution la plus simple serait de programmer les machines pour comprendre notre langue. C'est là que les modèles de langage offrent une opportunité incroyable.

Pour une machine à café, par exemple, il faudrait qu'elle capte tout ce qu'on dit dans la pièce, comprenne qu'un ordre lui est destiné et l'exécute. Siri, Alexa et Google Assistant ont tenté cette approche, mais les avancées récentes d'OpenAI et Google montrent des progrès bien plus prometteurs.

C'est tout à fait possible que dans 4 ans, des produits qui embarquent peu de technologie aujourd'hui soient équipés de capacités à comprendre le langage naturel pour extraire les ordres pertinents.

Ca me paraît impossible pour une machine de traiter un flux audio en continu pour en extraire l'ordre à réaliser. La réalité d'un environnement aussi complexe qu'une cuisine dépasse le simple décodage du langage humain :D

Pour réaliser cet exploit, la machine devra certainement :

• Identifier une personne dans la cuisine (ou dans un périmètre acceptable)
• Capter et analyser toutes les conversations de cette personne
• Filtrer le contenu non pertinent pour ses actions possibles
• Identifier et paramétrer l'ordre adressé
• Vérifier que la personne donnant l'ordre a l'autorisation nécessaire
• Et pourquoi pas, confirmer en utilisant elle-même le langage humain.

Il faudra une bonne compréhension du langage naturel. Merci aux modèles de langage. Mais surtout, il faudra beaucoup de code pour intégrer toutes ces fonctionnalités et tout la prise en compte du contexte nécessaire à l'exécution de l'ordre.

Nous ne nous contenterons certainement pas de parler aux machines et n'attendrons pas patiemment qu'elles nous répondent. Les interactions devront être immédiates et leurs réponses instantanées pour être efficaces. Aujourd'hui, les modèles de langage et leur capacité à générer du contenu en streaming sont impressionnants. Mais je parie que cette petite tendance disparaîtra aussi vite qu'elle est apparue.

What if UX is the new best friend of data intensive application?

I'm spending several hours per days reviewing applications that rely on a huge amount of data. They provide insight to customers, simulate hypothesis or just help to look for new business opportunities.

More and more, to explore data, software engineers leverage web based user interfaces to build applications that intensively consume data. Those, supported by a data pipeline that prepare the data in advance to serve customer need efficiently. Simplified vue of a data application architecture with from the left to the right: a data pipeline with some datasets, a database and the web app displaying KPIs

With this architecture, you're able to feed an application with aggregated data based on large volume of data. You will not suffer from latency or issues with memory management as the data will be pre-computed and stored in a database. This is made possible if you're able to anticipate the queries that will be performed by the user.

The word anticipation is important. It basically means that data need to be prepared to fit user request, and those workflows are known in advance. For example, on a monthly revenue for the twenty first best products or on a list of the ten next maintenance to prioritized on a car the user workflow is perfectly managed. This situation is ideal as you are able to prepare exactly what the user want to display. There will be few questions about refresh time and number of users at the same time but honestly, this is not a big deal.

Things are going to be more complex at the time when the user will be able to generate query on his own. Imagine that the user want now to request not the tenth first rows but dynamically expand the query to thousands. Imagine also that the product aggregation is too large and now, we need to exclude or filter on specific products.

Actually, the more you will add features to filter and aggregate from the application then the more anticipating all possible queries will be a complex job. At first, you were having a responsive and efficient system, but now you need to trade-off between performance, database costs and even the customer satisfaction directly. When you're there, a step back is necessary to think about the options that you have before building the impossible.

1. The first one will be analyzed in an other post, but it basically involve an architecture-switch to leverage an asynchronous system to send back your query to your distributed system and secure a result while assuming a higher response latency.
2. The second one is to work directly on the user needs to tune or hack its actual experience to facilitate anticipation when responding to user queries.

Finding a path between the anticipation needs of engineers and the gluttony of users for data involves looking at the user experience. You need to think about user interface, user needs (or what they seems too) and the workflow they want to use.

Obviously as we're dealing with user feelings and this post have is not about the data itself there are no silver bullet solutions.

But here are the points I'm trying to optimize or look for in priority when I face such issue.

Access patterns

How does the user try to access the data? Does it use a direct reference? Do we need to stick to the common pattern of having lists of objects prior to accessing the searched one? Navigating the data and application performance or intimately linked. Whenever possible try to reduce navigation to the minimum.

I've met many users who know well the reference of their data, business users with experience have deal with excel files for years, and probably build methodologies or trick to find data faster. Leveraging this experience in accessing the data instead of building a traditional web navigation can help you to save compute and time by avoiding useless queries. Imagine that instead of building a Search List Proposition Object Result you create a Business Object Reference Object result.

This approach is interesting also on engineering side as it will help them to anticipate which field are crucial to build the correct index and cache that will improve response delay. You can now avoid preparing the whole data table and just be sure that a few subset of data is enough to fit the need. For the example above you can even avoid building list of objects, pagination, search orders.

One complex object at a time instead of list

You shouldn't ever accept to load data that is not directly displayed to the user. It will cost a lot in term of response delay and in term of computing resource while being perfectly useless for the user. For example, let's take a query that perform a compute intensive aggregation on several keys on your database. There are two scenarios:

1. User provide the scope, the query is processed, it takes time then it's available for the user and it ends up with the user to scroll to find the few keys that are really interesting.
2. The user anticipate the key that he's looking for and then process the query for this unique object. Then by clicking on a forward reference he can jump on the other one reprocessing a new query.

Focusing on one object at a time is a good way to save time and processing while offering engineer a good anticipation compared to the real volume of data. In the first case you can deal with aggregating over a stack of object that is continuously growing (I want 100 objects, 1000 ...), in the second one you help the user to focus and provide only the information he's looking for.

Filter, filter, filter.

You got the trick, the idea is to work on the user experience to find all the path possible to avoid requesting data that will not be used. But when you provide abilities to generate a query you always need to deal with the risk of performance / experience issues.

In fact, instead of wasting time to look for the data they need in a bunch of rows, power users should build the perfectly fitted query they need. It could be direct access, a set of filters or even a domain specific language to query efficiently the data. When the user share the "rules", engineering job can start to prepare datasets and views that will fit those rules leveraging the right indexes or preparing expensive aggregates.

Wrap up

To reduce continuously the risk of waste you need to closely work with users to have a comprehensive understanding of the data usage. It will be easier to avoid all the common experience issues that you find when you build product that fits industry standard instead of building a fitted experience.

Following the role you take in building such application you need to always keep in mind that their are multiple ways to achieve the same goal when building such products . Thinking about hacking your current perception of user needs can provide great benefit for the user experience directly, but also on application performance and definitely can help you to reduce the computing waste and user frustration.