Tu peux aujourd’hui demander à Claude, Codex ou Gemini de te générer une interface, un workflow ou une première version d’outil en quelques heures.
C’est une bonne nouvelle.
Mais elle crée une nouvelle difficulté : on peut construire beaucoup trop vite des choses qui ne méritent pas encore d’être construites.
C’est aussi la raison pour laquelle je fais évoluer No Code Station vers Builder Station. Le sujet n’est plus seulement de découvrir les bons outils pour fabriquer une V1. Il est de savoir transformer un problème métier en système utile, contrôlable et exploitable.
Cette semaine, on va donc parler de ce qui devient rare quand la construction accélère : la décision.
Au programme :
Pourquoi la vitesse de prototypage déplace le goulot d’étranglement
Les cinq questions à poser avant de construire un agent
Le test de sept jours qui évite de bâtir une plateforme inutile
🔮 Trois découvertes utiles sur les agents, les évaluations et le contrôle
⏳ Temps de lecture : 8 minutes
Pendant longtemps, construire un outil demandait suffisamment de temps et d’argent pour imposer une sélection naturelle.
Il fallait choisir une idée, écrire un cahier des charges, trouver quelqu’un pour développer, attendre plusieurs semaines, puis découvrir que le besoin avait changé.
L’IA réduit fortement le coût de la première version. Le prototype n’est plus toujours le meilleur filtre.
La rareté se déplace vers la qualité de la décision qui précède le prototype.
Est-ce le bon problème ? Pour le bon utilisateur ? Avec les bonnes données ? Le résultat est-il mesurable ? Qui reprend la main quand l’agent se trompe ?
Si ces réponses sont floues, une V1 rapide ne fait que produire plus vite de la confusion.
Un agent n’est pas simplement un chatbot auquel on aurait ajouté trois boutons.
C’est un système qui peut interpréter un contexte, choisir une action, utiliser des outils et poursuivre un workflow jusqu’à une condition de fin.
OpenAI recommande de réserver les agents aux cas où les règles sont difficiles à maintenir, où les données sont non structurées ou où le travail demande des décisions complexes.
Pour une tâche simple et déterministe, une automatisation classique reste souvent préférable.
Le premier travail du Product Builder n’est donc pas de choisir un modèle. C’est de déterminer quelle part du workflow doit rester déterministe, quelle part peut être probabiliste et où l’humain doit reprendre la main.
1. Quel résultat doit changer ?
« Ajouter de l’IA au support » n’est pas un résultat.
Réduire le temps de première réponse de 8 heures à 30 minutes, sans augmenter les escalades incorrectes, en est un.
Si le résultat n’est pas formulé, tu ne pourras ni choisir le bon workflow ni évaluer l’agent.
2. Qui possède le résultat ?
Un agent peut être construit par une équipe et utilisé par une autre. Cela ne veut pas dire que quelqu’un en est responsable.
Il faut un propriétaire capable de répondre à trois questions :
que doit faire le système ?
que n’a-t-il pas le droit de faire ?
qui décide qu’il est suffisamment fiable pour passer à l’étape suivante ?
Sans propriétaire, l’agent devient vite une démonstration orpheline.
3. Quelles sources font autorité ?
Le modèle ne doit pas seulement avoir accès à « beaucoup de contexte ».
Il doit savoir quelles données sont fiables, lesquelles sont anciennes, lesquelles sont contradictoires et lesquelles ne doivent jamais être utilisées.
Une bonne question n’est pas : « Quelles informations donner au modèle ? »
C’est : « Quelle source peut faire foi si deux informations se contredisent ? »
4. Quelles actions sont autorisées ?
Toutes les actions ne se valent pas.
Lire un document, proposer une réponse, modifier un CRM, envoyer un e-mail ou déclencher un paiement ne présentent pas le même risque.
L’approche d’OpenAI consiste notamment à classer les outils selon leur niveau de risque : accès en lecture ou en écriture, action réversible ou non, permissions nécessaires et impact financier.
Tu peux commencer avec un agent qui observe et recommande, puis autoriser progressivement certaines actions. L’autonomie devient un niveau que l’on mérite par la preuve, pas un réglage activé par défaut.
5. Comment saura-t-on que le travail est terminé ?
Un agent ne doit pas décider seul qu’il a « probablement réussi ».
Il faut un critère observable : un test qui passe, un champ correctement complété, un document validé, une réponse classée dans la bonne catégorie ou une intervention humaine déclenchée.
Anthropic insiste sur les évaluations de workflow : il faut vérifier que l’agent ne casse rien, qu’il fait ce qui était demandé et qu’il le fait correctement.
Le bon builder ne demande pas seulement : « Est-ce que la réponse est pertinente ? »
Il demande : « Est-ce que le système a fait avancer le travail sans créer un nouveau risque ? »
Avant de construire une plateforme, prends un seul workflow récurrent et limite l’expérience à sept jours.
Pendant cette période :
1. Sélectionne un petit jeu de cas réels ;
2. Définis le résultat attendu et les cas d’échec ;
3. Commence avec des droits en lecture ou une validation humaine ;
4. Mesure le temps gagné, les erreurs et les reprises manuelles ;
5. Décide ensuite si le workflow mérite davantage d’autonomie.
Ce test produit un actif plus utile qu’une démo : une première évaluation, une liste de limites et une décision documentée.
Le NIST AI Risk Management Framework résume cette logique en quatre fonctions : gouverner, cartographier, mesurer et gérer. Le point important n’est pas de transformer chaque projet en exercice de conformité. C’est de ne pas séparer la construction de la responsabilité.
Je ne veux pas transformer Builder Station en une newsletter qui annonce simplement le prochain outil à tester.
Je veux en faire une note de terrain pour les personnes qui doivent passer :
d’un problème flou à un workflow clair ;
d’un prototype à un système utilisable ;
d’un modèle choisi à une architecture justifiable ;
d’une promesse d’automatisation à une preuve de valeur.
La veille restera présente. Mais elle servira de matière première à une décision, une méthode ou un test concret.
À partir de maintenant, réponds simplement à cet e-mail avec un workflow, une tâche ou un problème métier que tu aimerais voir décortiqué. Je m’en servirai pour choisir les prochains dossiers.
→ Les évaluations deviennent une pièce du produit : Anthropic décrit des tests qui vérifient qu’un agent ne casse rien, fait bien ce qui est demandé et maintient la qualité sur la durée. Le signal : un agent sans jeu de tests est encore une démo. — Demystifying evals for AI agents
→ Le moindre privilège devient une fonctionnalité produit : un agent qui peut lire, écrire et déclencher des actions financières ne doit pas être conçu comme un agent qui ne fait que proposer. Le signal : les permissions, la réversibilité et l’escalade humaine font partie de l’expérience utilisateur. — A practical guide to building agents
→ La décision go/no-go doit arriver plus tôt : le cadre NIST organise le travail autour de gouverner, cartographier, mesurer et gérer les risques sur tout le cycle de vie. Le signal : décider de ne pas construire est parfois le meilleur résultat d’un projet IA. — NIST AI RMF Core
Si un sujet t’a parlé, si tu veux challenger une idée ou juste dire que tu étais là — réponds directement à cet email. Je lis tout et je réponds à tout.
Et si tu as un projet à développer — une app, un outil interne, une V1 à finaliser — c’est exactement pour ça que je suis là. Un message en réponse à cet email suffit pour qu’on en parle.
Si tu veux sponsoriser les prochaines éditions c’est possible. Je te laisse consulter le deck.
Si cette édition t’a apporté quelque chose, le meilleur coup de pouce que tu puisses me donner, c’est de la partager à quelqu’un qui en ferait quelque chose 👇
Tu peux aussi me retrouver sur LinkedIn pour suivre ce que je construis en dehors des éditions.
Bonne semaine,
— Milan
Aucun post
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.