Gauthier est VP Product chez Forest depuis cinq ans. Forest construit l'infrastructure opérationnelle de Qonto, Spendesk, Swan, Swile, Mastercard et Modern Treasury, des environnements régulés où une erreur d'agent peut coûter un agrément. Il partage la méthode que son équipe a construite en deux ans pour faire passer des agents du POC à la production, sans jamais parler du dernier modèle sorti.
1. Le boring AI fait le make or break
Gauthier annonce la couleur en ouverture. Il ne parlera pas du dernier modèle sorti ni des modèles chinois moins chers.
"Ce n'est pas tant de jouer avec un modèle, trouver le bon prompt et tester. Une fois qu'on le met en prod, c'est tout le sujet de plomberie autour."
Le contexte de Forest explique cette obsession. Leurs clients sont des entreprises régulées : fintechs, santé, paiement. Des opérations critiques, avec un régulateur au bout de la chaîne qui peut retirer un agrément bancaire.
Forest a pivoté d'un back office vers une infrastructure de gestion des opérations. La société s'appelait Forest Admin et s'est rebrandée en Forest il y a environ un mois et demi.
Trois sujets dominent leurs conversations clients en ce moment : l'arbitrage entre déterminisme et probabilisme, la self-learning loop, et l'optimisation des coûts.
"Il y a certains cas où l'humain est moins cher que l'IA."
2. Trois mondes qui coexistent dans un workflow
Dans les opérations, il y avait deux mondes. Il y en a maintenant trois.
L'humain, qui décide, dans une UI ou dans une interface conversationnelle. Le déterminisme, où les mêmes entrées donnent les mêmes sorties : un script Python, un workflow n8n sans agent. Le probabilisme, où on fait appel à un LLM.
Ces trois mondes vont continuer à coexister. Dans un même process, on passe de l'un à l'autre.
Son exemple est un onboarding bancaire. Une néobanque doit vérifier qu'un siret correspond bien à l'entreprise déclarée et qu'un dirigeant porte bien le nom annoncé. Comparer deux chaînes de caractères, c'est du pur déterministe. Gérer les variantes d'orthographe, on le faisait avant avec une distance de Levenshtein, à moins de cinq pour cent d'écart on valide.
Mais quand on empile les accents, les cédilles, les tirets et les prénoms composés, la machine à états ne tient plus. C'est là que le probabiliste prend le relais.
L'ordre compte, y compris pour le budget. On teste d'abord l'égalité stricte. Si elle échoue, on appelle l'agent.
3. Les quatre types d'agents en opérations
La terminologie que Forest utilise avec ses clients.
L'agent généraliste. Le support de niveau zéro qui traite les demandes simples, réinitialisation de mot de passe, accès à une facture. Dès que la demande se complexifie ou que l'utilisateur met de l'émotion, il escalade.
L'agent expert. Il ne sait faire qu'une chose mais il la fait très bien. Lire une carte d'identité et en extraire l'OCR, analyser une transaction.
L'orchestration. Un agent qui met le travail à la bonne entité au bon moment, humain ou agent.
Le copilot. Il ne prend pas de décision, il accompagne un humain qui décide.
Ces quatre profils peuvent cohabiter sur un même workflow, avec des impacts différents sur la chaîne de valeur.
4. Choisir l'objectif, le process, faire le mapping
Trois étapes, toujours dans cet ordre.
L'objectif. Dans les opérations, il se résume presque toujours à trois choses : réduire le coût opérationnel, réduire le temps de traitement d'un dossier, ou améliorer la qualité en baissant les faux positifs et les faux négatifs. Le temps de traitement compte double, parce qu'un onboarding lent génère de l'impatience et donc du support.
Le process. Forest recommande quatre critères. Il doit être coûteux, pas forcément en argent, six heures de temps humain suffisent. Il doit avoir de l'historique, avec un set de données de test exploitable. Il doit être mature. Et il doit comporter du jugement ou de l'analyse, la zone où l'IA apporte de la valeur.
Sur la maturité, leur test est simple : envoyer le process à trois personnes différentes chez le client et voir si la même chose se produit.
"On a tous tendance à surestimer la clarté de nos process et nos procédures."
Le mapping. Des rectangles et des flèches. Gauthier aime le BPMN, Business Process Modeling Notation, mais précise qu'un Whimsical, un FigJam ou même des carrés dans Excel suffisent. Le but est d'identifier où va le probabiliste et où reste le déterministe.
"Si toi, tu ne sais pas faire quelque chose, ton agent ne saura pas le faire et il ne va pas improviser."
5. Donner les moyens à l'agent
Un opérateur humain a le produit, le CRM, le ticketing, les providers, son navigateur, et un système de permissions qui va avec. Il faut donner l'équivalent à l'agent.
Le CRM est souvent accessible via API ou MCP, mais la qualité de la donnée à l'intérieur est inégale. La donnée de qualité, celle du produit et de la base de prod, n'est en général pas accessible directement. Il faut exposer des API ou des MCP et décider comment les consommer.
La maturité des serveurs MCP est un sujet à part entière. Sur certains, retrouver une information demande une cascade de calls mal documentés. Plus il y a de calls, plus ça coûte cher et plus c'est lent.
Le pricing réserve des surprises. Une interface humaine se facture au siège, autour de vingt dollars par mois. Une API se facture à l'usage. Gauthier cite un registre luxembourgeois ou suisse où le coût par API est vingt à trente fois supérieur à une consultation dans l'interface. Dans ces cas, Forest reste sur de l'humain.
Dernière décision : comment charger la donnée. Si l'agent a besoin de deux informations connues d'avance, on les lui donne en contexte au démarrage. Inutile de lui faire faire les calls. En revanche, un agent qui analyse une transaction, remonte au compte du destinataire, puis à ses cartes, puis à ses litiges, doit disposer d'outils de recherche, parce qu'on ne peut pas anticiper son chemin.
6. L'agent harness
Le concept vient de Tomasz Tunguz. Gauthier le résume ainsi.
"Le harnais est plus important que le cheval."
Autrement dit, tout ce qui entoure le LLM a plus d'impact sur le résultat que le modèle lui-même.
Le contexte et la mémoire. Où placer une règle, où placer un exemple. Forest a testé sur sa propre feature d'éditeur drag and drop, qu'ils voulaient rendre vibe-codable. Avec beaucoup de règles, ils atteignaient environ quatre-vingts pour cent du résultat visé. Ils ont ajouté des exemples de workspaces dont ils sont fiers, ça a monté. Ils ont retiré des règles, ça a encore monté. Ils ont retiré des exemples, ça a encore monté. Le sujet est autant du test and learn que de la gouvernance : qui, du produit ou des opérations, gère le contexte.
Les outils. Comment récupérer l'information et comment agir dessus.
L'orchestration et l'état. Que se passe-t-il en cas d'erreur à l'étape sept. On reprend à l'étape huit, on retente, on appelle un humain, ou on appelle un agent spécialisé.
L'observabilité. Gauthier décrit trois niveaux. Le niveau zéro consigne quelle donnée a été lue et quelle action a été prise. Le niveau un ajoute un rationale, un paragraphe où l'agent explique sa décision. De plus en plus, les clients demandent le chain of thought complet : quel outil appelé, avec quelle valeur, quel résultat, où ça a échoué.
Les permissions. Deux angles. Qui a le droit de voir la donnée, et qui a le droit de voir les logs. Si un agent a plus de droits que l'opérateur final, l'opérateur accède indirectement à des données interdites. Un sujet de backdoor très surveillé par les régulateurs français.
"Les permissions, ça doit être dans ton infra et dans ta stack, tu ne mets rien dans l'agent. Dans l'agent, c'est des guidelines, mais tu ne peux pas contraindre des permissions dans un agent."
Il précise que Forest en est revenu. Il y a un an, la pratique consistait à écrire dans le prompt de ne pas aller chercher telle valeur. Le probabilisme ne garantit pas ce genre de consigne.
7. L'orchestration, la botte secrète
Gauthier la présente comme le levier dont ils n'avaient pas anticipé l'impact sur les KPIs clients. Il s'agit de déterminer quand lancer un agent et comment répartir le travail entre agents et humains.
Si le KPI est le temps, tout doit être prêt quand l'humain arrive. Si le KPI est le coût, on appelle le moins d'agents possible et seulement au moment nécessaire.
Son exemple. Un client démarre son onboarding à trois heures du matin. Les opérateurs sont actifs à dix heures. Dans le monde idéal, les agents préparent l'analyse pendant la nuit et l'humain valide à dix heures. Sauf que le client peut revenir modifier son dossier à cinq heures. Soit on relance une analyse et ça coûte, soit l'architecture ne déclenche qu'au premier trigger et l'humain reçoit une analyse périmée, ce qui dégrade la qualité.
Le timing devient donc un objet de design à part entière : quand appelle-t-on qui, et à quel moment lui donne-t-on du travail.
8. Le socle de configuration et la self-learning loop
Un agent doit évoluer. Forest distingue le socle, qui reste la propriété de l'équipe produit, et le niveau de configuration, qui doit revenir aux opérationnels.
L'exemple est parlant. Une vague de fraude arrive, le seuil à cinq cents dollars doit descendre à deux cent cinquante, mais seulement pendant une semaine. Si cette demande doit passer par la roadmap produit, les ops arrêteront vite de la formuler.
"Il ne faut pas sous-estimer l'imagination de nos équipes opérationnelles de pouvoir faire des workarounds autour de tout."
Sa recommandation : donner aux opérationnels la main sur la configuration, dans le respect du socle, avec les permissions, les audit logs et les evals. C'est selon lui ce qui décide de l'adoption sur la durée. L'agent fonctionnera toujours dans le cas nominal, mais l'adoption tombe quand le monde change et que rien ne suit.
La self-learning loop suit la même logique. Avant la mise en production, on backteste l'agent sur l'historique, cent ou mille derniers cas, en gardant en tête que tester coûte des tokens. Ensuite on le teste face à l'humain, avec deux options.
En parallèle : l'humain continue son travail, l'agent tourne à côté, on compare à la fin. Cette méthode ne biaise rien mais demande des data scientists pour l'analyse.
En suggestion : l'agent propose et on regarde si l'humain accepte. Plus simple, mais ça crée des biais et ça peut faire baisser la qualité.
Une fois en production, chaque décision alimente la boucle. Elle indique quelle étape améliorer, quel prompt corriger, quelle donnée ajouter, ou quelle information sortir de l'agent pour la traiter en déterministe en amont.
9. Le coût réel d'un agent
Le token maxing est terminé.
"De toute façon, les tokens, ça ne fait que baisser. Donc, pour l'instant, tu prends sur ta marge."
Deux choses ont changé. Les prix des tokens ne baissent plus et remontent parfois légèrement. Et les modèles récents consomment davantage de tokens à tâche équivalente.
La référence de comparaison, dans les opérations, ce sont les BPO, les business process outsourcing. Gauthier donne les ordres de grandeur : entre vingt-cinq et trente-cinq euros de l'heure, vingt-cinq avec de gros volumes et une bonne négociation. À quatre KYC par heure, on arrive autour de dix euros le KYC. C'est cette baseline qu'il faut comparer au coût du process agentisé.
Le calcul est plus subtil qu'il n'y paraît. On l'établit souvent sur le happy path, alors que les escalades et les cas d'erreur coûtent ailleurs dans l'organisation. Et le temps libéré chez un humain crée de la valeur autre part.
La recommandation Forest : raisonner en coût par dossier, par décision ou par process, et segmenter selon le happy path et le nombre d'escalades. Gauthier reconnaît qu'il n'existe pas encore de standard de marché sur ce calcul.
10. Designer l'organisation, pas l'agent
La métaphore qui structure toute la méthode : déployer un agent, c'est onboarder une nouvelle équipe.
Le poste, c'est le mapping de process. Les moyens, ce sont les données et les outils. Le titre et le badge, ce sont les droits, l'autonomie, et la présence ou non d'un human in the loop. Les horaires, c'est l'orchestration, le moment où on déclenche et où on dispatche. Le salaire, c'est le coût final.
Sur le human in the loop, Forest va plus loin que l'escalade classique. Le travail peut passer d'un agent à un humain, d'un agent à un autre agent, ou d'un humain à un agent. Un process peut commencer en déterministe, passer par une phase humaine, et se terminer par une catégorisation agentique. Ce sont ces moments de passage de main qu'il faut optimiser.
"Il ne faut pas penser à construire un agent, il faut plutôt penser à designer l'organisation autour pour que l'agent fonctionne bien dans ses process à lui."
Cette logique a aussi transformé le produit Forest. Le back office était pensé pour du travail synchrone, un humain qui clique. Ils l'ont ouvert au travail asynchrone, où les agents consomment la donnée avec le même control plane, permissions, audit logs et business logic.
"Ton produit, tu le fais pour des humains, mais tu dois aussi, comme tu avais de l'empathie pour tes humains, maintenant tu le fais pour des agents, et tu dois avoir de l'empathie pour tes agents, de comment ils vont consommer ça."
Sur le taux d'erreur acceptable : pas de réponse universelle. Forest anime un workshop dédié au risk appetite en début de mission. Le curseur dépend du use case, de l'environnement réglementaire, et même du moment dans le cycle d'audit.
Sur le choix du modèle : Gauthier considère que c'est la mauvaise question. Le modèle n'a d'impact réel que sur les evals et l'optimisation du contexte. Sur l'open source, il observe que le sujet remonte surtout par l'angle de la souveraineté et de la maîtrise des données.
Sur la définition d'un agent : sa version, en assumant qu'elle ne fait pas consensus, c'est un serveur qui a des instructions et qui, à un moment, fait appel à un LLM.