En quelques semaines, on peut avoir un prototype qui impressionne, qui passe les démos, qui fait des choses qu'on n'aurait pas crues possibles il y a trois ans. Le vrai sujet commence après : faire quelque chose qui se comporte exactement comme prévu, qui ne surprend pas les clients de la mauvaise façon, qui tient en production sous la charge et sur des données réelles. C'est ce dont parle Marianne Borzic-Ducournau dans ce live. Pas de la recherche, pas du vibe coding. Du Machine Learning en production, bout en bout, pour cinq cent mille entreprises.
1. Une distinction qui change tout
Marianne pose d'emblée une distinction importante : le ML interne (qui aide les équipes Qonto à mieux décider — churn detection, marketing mix modeling) n'est pas son sujet. Son équipe fait du Product ML : des features ML intégrées directement dans l'interface que les clients utilisent.
"On n'est pas une équipe de R&D. On ne publie pas de papier. Les seules publications que je fais, ce sont des blog posts Medium. On ship vraiment des features ML en production pour des clients, et on monitore tout de bout en bout."
La distinction change les exigences. Côté ML interne, les utilisateurs finaux sont des équipes internes — plus indulgentes, boucles de feedback plus courtes. Côté Product ML, ce sont les cinq cent mille entreprises clientes. "Ce scale change tout. Les exigences de fiabilité sont bien plus élevées. Le cycle de feedback est plus long. L'impact client est plus direct."
Son équipe : environ quinze Machine Learning Engineers, dont le titre évolue progressivement vers AI Engineer. Rattachée à la data, mais de plus en plus proche des équipes back-end pour acquérir les compétences software engineering qui manquaient traditionnellement aux MLE.
2. De l'image à des données structurées en moins de deux secondes
Le premier produit est l'extraction automatique d'informations depuis des documents financiers (factures, reçus, tickets de caisse). Le problème : une PME qui reçoit cinquante factures par mois doit extraire manuellement le montant, la date d'échéance, l'IBAN du bénéficiaire. C'est long, répétitif et source d'erreurs.
La solution : un pipeline en deux étapes. D'abord, un OCR (Paddle OCR, open source, hébergé sur AWS) qui extrait la couche de texte depuis l'image. Ensuite, un modèle MT5 fine-tuné sur environ six millions de documents, plus dix mille documents annotés manuellement, qui vient parser la couche de texte et en extraire les champs utiles : montant, date d'échéance, IBAN, nom du bénéficiaire.
MT5 est un modèle multilingue de Google Research, publié en open source. Il gère le français, l'allemand, l'italien et l'espagnol — les langues les plus représentées dans les factures Qonto. Résultat : plus de quatre-vingt-quinze pour cent de précision sur les champs principaux, en moins de deux secondes.
Sur le choix de construire en interne plutôt que d'appeler une API externe : "On voulait absolument une friction minimale entre l'upload d'un document et l'extraction des données. Dans la majorité des cas, les données sont extraites en moins de deux secondes. C'est imbattable avec une API externe." Et les coûts d'infrastructure sont minimes — sauf pour le réentraînement, estimé à environ dix mille euros par cycle.
Le coût de réentraînement de MT5 : environ dix mille euros par cycle.
3. Un decision tree pour matcher automatiquement factures et paiements
Deuxième produit : le rapprochement comptable automatique entre documents et transactions. Le problème : une facture reçue en décembre peut être payée en janvier. Sans matching automatique, c'est du travail manuel fastidieux à chaque clôture mensuelle. "Pour boucler votre mois, votre comptable va réclamer toutes les pièces justificatives qui correspondent à vos paiements du mois. Parfois, la facture n'a pas encore été reçue, parfois elle a été reçue plusieurs mois avant."
La solution : un modèle de machine learning basé sur un decision tree, déclenché à chaque nouvel événement (upload de document ou nouvelle transaction). Il score les paires document-transaction sur trois critères principaux : le montant, la date, et le nom du bénéficiaire.
Le modèle retourne trois types de réponses selon son niveau de confiance. En dessous d'un premier seuil : aucune action, le document reste dans le stock. Entre les deux seuils : une suggestion soumise à confirmation utilisateur en un clic. Au-dessus du seuil haut : matching automatique. "L'utilisateur peut toujours dématcher manuellement, et on traque évidemment le taux de dématching — ça fait partie de nos mesures de performance en production."
Sur la construction du jeu de données d'entraînement : les données historiques d'avant la feature (quand les utilisateurs faisaient le matching eux-mêmes) ont fourni le gros de la masse. Après la mise en prod, c'est soit des PM soit des MLE qui annotent des petits datasets. "C'est fastidieux. Trouver parmi ses transactions laquelle correspond à quel document, c'est très difficile, très laborieux."
Sur l'apprentissage continu : les validations et corrections des utilisateurs sont persistées en base. Elles alimentent l'entraînement lors des cycles de réentraînement, qui restent pour l'instant déclenchés manuellement.
4. Un modèle backbone et une couche personnalisée par client
Troisième produit : la catégorisation automatique des transactions. Le problème : sans catégorisation fiable, impossible de répondre à des questions comme "combien j'ai dépensé en logiciels ce trimestre" sans exporter en Excel et faire des calculs manuels. "Beaucoup de PME pilotent leur cash à vue parce que catégoriser à la main, on commence et puis on arrête."
L'architecture est en deux couches. Un modèle backbone FastText (Facebook Research, open source), entraîné sur l'ensemble des transactions Qonto, qui catégorise toute nouvelle transaction dans l'une des cinquante catégories par défaut (fournitures de bureau, impôts, transport, etc.). Par-dessus, un neural adapter par organisation : un petit réseau de neurones entraîné en transfer learning sur les habitudes spécifiques de chaque client. Il permet de prédire des catégories personnalisées créées par le client lui-même.
"Si Office Supply ne vous plaisait pas et que vous avez créé Paris Office Supply et Berlin Office Supply, le modèle backbone ne peut pas prédire ces catégories. Avec le neural adapter, on est capable de le faire." Le réentraînement du neural adapter est quotidien et automatique, déclenché par Airflow.
Les métriques en production : quatre-vingt-cinq pour cent de précision globale, quatre-vingt-cinq pour cent sur les catégories souhaitées par le client, quatre-vingt-quinze pour cent sur les transactions récurrentes — qui représentent un tiers du volume.
5. Du LLM en production dans un contexte financier
Quatrième produit, le plus récent et le plus complexe : un agent conversationnel qui répond à des questions d'analyse financière. "Combien j'ai payé à Uber ce mois ? Est-ce que mes frais de déplacement ont augmenté ce trimestre ?" Des questions dont les données sont dans l'interface, mais qui prennent plusieurs minutes à obtenir manuellement (filtres, export CSV, pivot tables).
L'architecture : un point d'entrée unique conversationnel dans l'interface Qonto, avec un routeur qui redirige les questions analytiques vers un sous-agent dédié. Ce sous-agent utilise une instance DuckDB éphémère — et non Snowflake directement. Raison de sécurité : "Un client pourrait essayer d'accéder aux données d'autres clients, ou tenter d'écrire dans notre base Snowflake. Avec DuckDB, on charge uniquement les données financières du client lui-même."
La difficulté spécifique au contexte financier : une hallucination n'est pas juste une mauvaise expérience utilisateur. "Si vous demandez combien vous avez dépensé en marketing et que l'agent répond trois mille au lieu de trente mille, vous perdez confiance — potentiellement définitivement." D'où un framework d'évaluation particulièrement rigoureux.
Impact mesuré : C-SAT de quatre-vingt pour cent, sur cinq cent mille utilisateurs ayant accès gratuitement à la fonctionnalité. "Ma cible initiale était plus de soixante-dix pour cent, et sous cinquante, il aurait fallu continuer à investir. On est bien au-dessus." Le C-SAT a légèrement baissé en passant d'une alpha avec des early adopters tech-savvy à un déploiement grand public — mais il est stable depuis plusieurs semaines.
La feature offre aussi une capacité de "time travel" : "La balance du trois avril à dix-sept heures vingt-huit. C'est quelque chose qui n'est même pas disponible dans l'UI classique. Et ça, c'est très apprécié."
"Faire un produit qui marche, c'est devenu facile. En quelques semaines, vous pouvez avoir un prototype qui impressionne. Le vrai sujet, c'est ce qui vient après : faire quelque chose qui marche bien, qui se comporte exactement comme prévu, qui va tenir en production sous la charge et sur des données réelles. Et ça, c'est vraiment un autre métier."
6. Cinq dimensions pour distinguer un produit IA qui marche d'un produit IA fiable
Marianne propose une grille de lecture en cinq dimensions pour évaluer si un produit IA est prêt pour la production.
Edge behavior
Que se passe-t-il quand un client uploade une facture en coréen ? Quand une transaction a une description vide ? Quand l'analyste reçoit une question hors périmètre ou une tentative d'accès au schéma de base de données ? "Un produit fiable a une réponse prévue pour tous ces cas. Ce n'est pas un crash, ce n'est pas une réponse absurde."
Graceful degradation
Quand le modèle est incertain, est-ce qu'il dit "je ne sais pas" ou est-ce qu'il invente avec assurance ? "Un modèle qui dit je ne suis pas sûr est bien plus précieux qu'un modèle qui se trompe avec confiance."
Observabilité
Savoir quand ça se passe mal en prod avant que les clients contactent le support. "Très importante, cette observabilité."
Reproductibilité
Sur le même input, est-ce qu'on obtient le même résultat ? Particulièrement difficile et critique pour les LLM, non déterministes par nature.
Résilience au data drift
Comment les performances évoluent-elles quand un nouveau marché est ouvert, quand la distribution des données en production change ?
"Avant de shipper, vous devez poser ces questions sur les cinq dimensions. Ça vous permet de savoir si vous êtes passé du 'ouais, ça marche' à 'c'est fiable, on peut le mettre en prod'."
7. Penser à comment on sait que ça marche avant d'écrire la première ligne
La deuxième clé de lecture porte sur l'évaluation. "Avant d'écrire la première ligne de code, il faut répondre à la question : comment saurons-nous que ça marche ?"
Trois impératifs selon Marianne.
Construire le dataset avant d'entraîner le modèle
Pas après.
Définir l'échec explicitement
"Qu'est-ce qu'un mauvais output ? Si FLEX extrait un montant avec un centime de différence par rapport au document, est-ce que c'est grave ? Est-ce que c'est dans la zone de tolérance ?" La réponse dépend entièrement de l'usage du produit.
Pour les LLM, combiner golden test sets et LLM as a judge
Des questions de test mappées à des scénarios connus, un LLM qui score les outputs d'un autre LLM (pas le même provider) sur plusieurs dimensions : pertinence, exactitude, hallucination. Les tests tournent à chaque changement de code susceptible de modifier le comportement. "Long story short : des tests très fréquents, mais uniquement au moment de merger une PR. Il faut être malin, parce que ça coûte cher."
Sur la génération de données de test par LLM faute de ground truth : "C'est imparfait et ça ne vaut jamais des données de la vie réelle. Mais quand on n'a pas le choix ou quand on est pressé par le temps, ça fait le job. Ça permet de shipper rapidement avec un produit de qualité. Et puis, les points de performance supplémentaires se feront sur des données réelles."
"Pensez à l'évaluation par design. Surtout si vous êtes des software engineers qui s'orientent vers l'IA engineering — j'ai remarqué que ce n'est pas un réflexe qu'ils avaient. Ce n'est pas grave, on évolue tous. Soyez-en conscients et travaillez là-dessus."