Mémo — Industrialiser des agents IA : ce que le webinar Forest confirme, et les trous qu'il révèle¶
Date : 21 juillet 2026 Auteur : Nicolas Léonard (réflexion assistée) Statut : Note stratégique, matière pour la synchro macro mardi 14h30 Lecteur cible : squad Analyse, puis décideurs métier Source : Webinar The Product Crew × Forest (ex-Forest Admin), « Industrialiser des Agents IA de A à Z », 21/07/2026. Intervenant : Gautier, VP Product Forest. Replay
1. Pourquoi ce webinar nous concerne¶
Forest a pivoté du backoffice vers l'infra d'opérations agentiques pour des clients fintech régulés (Spendesk, Qonto, Swan, Mastercard). Leur contrainte est la nôtre : des agents qui n'ont pas le droit de se tromper, un régulateur qui peut auditer, des décisions qui doivent être justifiables. C'est le contexte le plus proche de l'analyse Bricks (conformité AMF, décision de comité explicable) qu'on ait vu traité publiquement.
Le contenu est du « boring AI » assumé : pas un mot sur les modèles, tout sur la plomberie. Sa thèse centrale reprend Tomasz Tunguz : le harnais compte plus que le cheval. Ce qui fait réussir ou échouer une initiative agentique, c'est le contexte, les permissions, l'orchestration, les évals et le coût, pas le choix du LLM. À la question « comment choisir son modèle ? », sa réponse est : mauvaise question, ça ne se voit que dans les évals.
Bonne nouvelle : ce discours valide l'essentiel de notre doctrine. Moins bonne nouvelle : il éclaire précisément quatre sujets où nous n'avons rien de formalisé.
2. Les 8 idées à retenir du webinar¶
- Trois mondes coexistent dans un même process : humain, déterministe (script, mêmes entrées = mêmes sorties), probabiliste (LLM). La bonne question à chaque étape : lequel des trois ? Et dans quel ordre -> déterministe d'abord, LLM en fallback sur les edge cases, pour contrôler les coûts (leur exemple : matching de noms par distance de Levenshtein, LLM seulement si ça échoue).
-
Quatre archétypes d'agents dans les opérations : généraliste (support N0), expert (OCR, analyse de transaction), orchestrateur (dispatch du travail à la bonne entité au bon moment), copilote (ne décide pas, accompagne). Mixables sur un même workflow.
-
Critères de choix du process à agentiser : coûteux (en euros ou en temps humain), avec historique (indispensable pour backtester), mature (leur test : envoyer le process à 3 personnes et voir si elles font la même chose, on surestime tous la clarté de nos procédures), avec du jugement ou de l'analyse dedans. Bottom line : si toi tu ne sais pas le faire, ton agent ne saura pas le faire.
-
Permissions dans l'infra, jamais dans le prompt. Le « ne va surtout pas lire cette donnée » en prompt, c'était il y a un an ; le probabilisme ne garantit rien. Les permissions vivent dans la stack. Règle d'or régulateur : un agent ne doit jamais avoir plus de droits que l'opérateur final qui l'utilise, sinon l'humain accède à des données interdites par ricochet. Leur pratique : traduire les sets de permissions humains existants (IDP, RBAC) pour les agents, plus API tokens scopés avec approbation humaine pour certaines actions.
-
Observabilité à trois niveaux : (0) log des lectures/actions, (1) rationale, un paragraphe justifiant chaque décision, (2) chain of thought complet, quel outil appelé, avec quelles valeurs, où ça a échoué. La demande des régulés bascule vers le niveau 2. Et un angle mort : qui a le droit de voir les logs est un sujet de permission en soi.
-
L'orchestration temporelle est leur « arme secrète » : quand lancer un agent et quand donner le travail à qui. Leur exemple : onboarding déposé à 3h du matin, analysé par l'agent à 3h05, mais le client modifie son dossier à 5h -> l'humain de 10h relit une analyse périmée sans le savoir. La qualité perçue s'effondre sur un problème de timing, pas d'intelligence.
-
Socle produit vs configuration ops. Le socle (permissions, audit, évals) appartient à l'équipe produit, mais les opérationnels doivent pouvoir ajuster seuls certains paramètres (leur exemple : seuil de fraude de 500 à 250 € pendant une semaine de vague de fraude). Sinon ils arrêtent de demander et contournent l'agent, et l'adoption meurt. Ne pas sous-estimer l'imagination des équipes ops / customer facing pour faire des workarounds.
- Le coût redevient un vrai sujet : les prix des tokens ne baissent plus (certains remontent), et les modèles récents consomment nettement plus de tokens par tâche. Leur recommandation : un coût par dossier / par décision, segmenté happy path vs escalades, comparé à une baseline humaine explicite (BPO à 25-35 €/h). Pas encore de standard de marché sur ces KPI. Et ne pas oublier que tester un agent sur l'historique coûte aussi des tokens.
Le framing qui résume tout : on n'installe pas un outil, on onboarde un nouveau membre d'équipe. Fiche de poste (mapping de process), moyens (data, tools), badge (permissions), horaires (orchestration), autonomie (configuration, HITL), salaire (coût). « Il ne faut pas penser construire un agent, il faut designer l'organisation autour pour que l'agent fonctionne. »
3. Où en est Bricks OS, thème par thème¶
| Thème webinar | Ce qu'on a | Verdict |
|---|---|---|
| Mix déterministe / probabiliste | Règles P0/P1 déterministes + agents LLM ; ADR-020 (extraction locale d'abord, OCR en fallback) est exactement leur pattern « déterministe d'abord, LLM en secours » ; mémo LIDAR sur le découpage procédural | ✅ En avance |
| Fiabilité de l'output | ADR-001 cascade convergence -> judge -> HITL, anti consensus corrélé. Le webinar n'aborde même pas la convergence multi-approches | ✅ En avance |
| Évals & self-learning loop | Tables golden_references / eval_campaigns / eval_results, ADR-022 (périmètre égal + couverture), capture passive (ADR-018, ADR-014), rule_feedbacks + /scan-feedback hebdo |
✅ En avance |
| Baseline de coût | Anchor Manus ~10-12 €/dossier vs pipeline 6-7 min, benchmark trimestriel acté | ✅ Au niveau, voir §4 |
| Observabilité | ADR-021 LangSmith (traces = leur niveau 2), mémo par section avec sources (niveau 1) | ✅ Au niveau |
| HITL & risk appetite | ADR-004 friction délibérée, marges explicites (VALIDATION MANUELLE entre REFUS et OK) = notre risk appetite formalisé | ✅ Au niveau |
| Permissions agents | Rien de formalisé. 14 agents sur une DB Neon partagée, pas de scoping par agent, pas de réponse écrite à « que voit quel agent » | 🔴 Trou |
| Configuration ops | Seuils Cédric dans le repo + table rules ; un changement de seuil passe par un cycle dev |
🟠 Partiel |
| Orchestration temporelle | DAG custom déclenché au lancement d'analyse ; pas de stratégie de re-run quand le dossier évolue après coup | 🟠 Partiel |
| Coût segmenté | Un anchor global, pas de coût par dossier segmenté happy path / escalade / re-run | 🟠 Partiel |
Lecture d'ensemble : sur la doctrine (fiabilité, évals, boucle d'apprentissage, benchmark), on est devant ce que le marché raconte. Les trous sont tous du côté « boring » : permissions, configuration, timing, coût. Exactement les sujets qu'on ne choisit jamais spontanément parce qu'ils ne font pas avancer le mémo comité.
4. Axes de réflexion à discuter (pas un backlog)¶
À passer au filtre des étapes 1-2 de l'algorithme (qui l'exige, est-ce que ça doit exister) avant d'en faire des tickets. Formulés en questions pour le mardi 14h30.
Axe 1 — Permissions et badge des agents. Aujourd’hui, les droits de lecture et d’action des agents ne sont pas décrits dans une preuve simple et auditable ; la réponse dépend encore d’une lecture du code. La règle Forest (agent ≤ droits de l'opérateur, garanti par l'infra, pas par le prompt) est peu coûteuse à adopter tant qu'on a 14 agents et 2 services. Question : est-ce qu'on écrit un ADR « badge agent » maintenant, à froid, ou est-ce qu'on attend que la question nous soit posée de l'extérieur ?
Axe 2 — Ce que Cédric et les analystes peuvent régler sans nous. Les seuils vivent dans wiki/status/regles-metier.md et la table rules, mais bouger une marge de 10 à 12 % passe par nous. Le warning Forest est crédible : le jour où l'ajustement est trop lent, les analystes contourneront l'outil, et les utilisateurs reviennent à des outils parallèles lorsque l’outil ne suit pas. Attention symétrique : une UI de configuration des seuils est aussi une porte d'entrée vers les règles niveau B du mémo LIDAR. Question : quel sous-ensemble de paramètres (seuils A uniquement ?) mérite d'être self-serve, avec audit trail, sans ouvrir la boîte de Pandore ?
Axe 3 — Fraîcheur de l'analyse. Le scénario « analyse à 3h, dossier modifié à 5h, analyste à 10h » est structurellement le nôtre : les dossiers PDP évoluent (documents ajoutés, réponses aux auto-questions) après le run d'analyse. Est-ce que l'analyste sait aujourd'hui que ce qu'il lit est périmé ? Un simple marqueur de staleness (« analyse basée sur l'état du dossier au JJ/MM, 2 documents ajoutés depuis ») est peut-être le 80/20, bien avant tout re-run automatique (étape 5, en dernier).
Axe 4 — Coût par dossier segmenté. L'anchor Manus nous couvre pour l'instant, mais deux signaux du webinar méritent surveillance : les tokens ne baissent plus, et les nouveaux modèles consomment plus par tâche. Notre ratio 10-12× peut s'éroder sans qu'on le voie. LangSmith a déjà la donnée token par trace. Question : est-ce qu'on ajoute le coût par dossier (segmenté happy path vs HITL vs re-run) aux métriques anchors, en respectant « less is more » (un chiffre par synchro, pas un dashboard) ?
Un cinquième sujet, mineur : leur pratique « règles vs exemples » dans le contexte (enlever des règles, mettre des exemples de référence, mesurer) est un protocole d'éval prêt à l'emploi pour notre prompts-library, et converge avec « ajoute 20 exemples au golden dataset, pas une règle ».
5. Conclusion¶
Ce webinar est un bon point de calibration marché : ce qu'un acteur crédible vend comme méthode d'industrialisation à des fintechs régulées, on l'a déjà en doctrine et en partie en prod, avec un cran d'avance sur la fiabilité et les évals. Le différentiel n'est pas conceptuel, il est opérationnel : badge, configuration, timing, coût. Quatre sujets ennuyeux, quatre sujets d'audit. La maturité qui nous manque n'est pas celle qui impressionne en démo, c'est celle qu'on nous demandera le jour où quelqu'un d'externe regardera comment ça tourne.
À discuter mardi 14h30 (synchro macro). Si un axe est retenu, le formaliser via /add-adr plutôt que de laisser ce mémo faire autorité.