CTO startup IA France 2026 : les vrais défis techniques de l'IA B2B (interview)

Antoine Ferrière

CTO & cofondateur, startup IA B2B, Lyon

• 33 ans, ingénieur INSA Lyon
• 8 ans d'expérience en ML et architecture cloud
• Plateforme d'automatisation du reporting industriel
• Contributeur open source Ollama
• Intervenant French Tech Auvergne-Rhône-Alpes

La French Tech n'est pas Paris. Antoine Ferrière en est la preuve vivante. Depuis le quartier de la Confluence à Lyon, il dirige la technique d'une startup qui automatise le reporting opérationnel pour des PME industrielles : traitement de données capteurs, génération automatique de rapports de conformité, alertes prédictives. Un produit concret, des clients réels, une techno IA en production depuis 18 mois. On voulait savoir ce que ça donne vraiment de construire de l'IA B2B en France, avec les contraintes réglementaires, budgétaires et humaines qui en découlent.

Avant de plonger dans ses retours d'expérience, un contexte utile : l'écosystème des LLM open source que son équipe utilise au quotidien est au coeur de ce que nous avons couvert dans notre guide d'installation des LLM open source locaux avec Ollama. Et pour les implications de l'IA sur la transformation digitale des entreprises, l'intelligence artificielle : guide complet 2026 donne le cadre de référence.

Pourquoi choisir les modèles open source plutôt que GPT

Comment avez-vous décidé de baser vos produits sur des modèles open source plutôt que sur GPT-4 ou Claude, qui semblent plus simples à intégrer ?

Antoine Ferrière : La décision s'est imposée assez vite pour deux raisons que nos clients industriels nous ont clairement exprimées dès les premiers démos. Première raison : la donnée ne sort pas. Nos clients dans l'agroalimentaire, la chimie et l'industrie de process ont des données opérationnelles très sensibles — certaines sont des secrets de fabrication, d'autres sont couvertes par des contraintes réglementaires sectorielles. Il n'était tout simplement pas envisageable pour eux que leurs données de production passent par les serveurs d'OpenAI ou d'Anthropic, même avec les garanties contractuelles de ces entreprises. Deuxième raison : la prévisibilité des coûts. Nos clients payent pour un SaaS à prix fixe par mois. Si nous sous-jacent sur GPT-4 Turbo et que les coûts d'inférence triplent — ce qui est arrivé entre 2023 et 2024 — notre marge s'effondre. Avec des modèles hébergés en propre, nous contrôlons notre structure de coût.

La contrepartie, c'est la complexité opérationnelle. Maintenir une infrastructure d'inférence, gérer les mises à jour des modèles, monitorer les performances — c'est un métier en soi qui demande des compétences que nous avons dû développer en interne.

RAG vs fine-tuning : notre approche pour l'industrie

RAG versus fine-tuning : c'est le débat central de l'IA B2B. Quelle est votre approche pour vos cas d'usage industriels ?

Antoine Ferrière : On a commencé avec du fine-tuning et on a perdu six mois. Pas parce que le fine-tuning est mauvais, mais parce qu'on a mal évalué ce dont on avait besoin à ce stade. Nos clients ont des terminologies très spécifiques — des noms de machines, de processus, de codes produits — et on pensait qu'un fine-tuning sur leurs données internes allait magiquement créer un modèle qui "comprend" leur entreprise. Ce n'est pas comme ça que ça marche.

Aujourd'hui notre architecture est RAG-first. Pour chaque client, on indexe leur documentation technique, leurs historiques de rapports, leurs fiches produits dans une base vectorielle. Quand le système génère un rapport, il récupère les passages pertinents et les injecte dans le contexte. Le résultat est meilleur, plus traçable (on peut citer les sources), et surtout plus maintenable. Si un client met à jour sa documentation, on re-indexe — pas besoin de re-entraîner.

On utilise du fine-tuning uniquement pour un composant spécifique : la classification des anomalies. Là, on a des milliers d'exemples labélisés par les opérateurs, une taxonomie stable, et un besoin de latence très faible. C'est le cas d'usage idéal pour le fine-tuning. Mais c'est l'exception, pas la règle.

Gérer la conformité RGPD avec des modèles IA

Comment gérez-vous concrètement la conformité RGPD quand les données clients entrent dans vos modèles IA ?

Antoine Ferrière : On a travaillé avec un DPO externe dès le début, et c'est un investissement qui a payé. Notre architecture respecte trois principes. D'abord, la résidence des données : toute notre infrastructure tourne sur des serveurs en France — OVHcloud principalement. Aucune donnée client ne sort du territoire européen. Deuxièmement, l'isolation par client : chaque client a son propre namespace dans notre base vectorielle, son propre contexte d'inférence. Pas de contamination croisée possible entre clients. Troisièmement, la minimisation : on ne stocke pas les logs bruts des conversations IA par défaut. On stocke uniquement les méta-données nécessaires au monitoring (latence, tokens, modèle utilisé) et les rapports finaux générés.

Le point le plus délicat, c'est les sous-traitants. Même si on n'appelle pas OpenAI, on utilise des services cloud pour notre infrastructure. On a une liste précise de tous nos sous-traitants avec leurs certifications (ISO 27001, HDS pour le médical le cas échéant), et ça fait partie du DPA qu'on signe avec chaque client. Les enjeux RGPD dans un contexte NIS2 sont bien couverts dans le guide NIS2 pour les PME — c'est une lecture que je recommande à nos clients qui découvrent ces contraintes.

Le vrai coût d'inférence d'un modèle IA en production

Quel est le vrai coût d'inférence d'un modèle IA en production, entre l'API cloud et l'hébergement propre ?

Antoine Ferrière : Je vais vous donner des chiffres réels sur notre produit. Nous générons environ 400 rapports par mois, chacun nécessitant en moyenne 3 appels LLM de 3 000 tokens en input et 1 500 tokens en output. Ça fait 1 200 appels, environ 5,4 millions de tokens input et 1,8 million de tokens output par mois.

Sur GPT-4o API, au tarif de mars 2026, ça représenterait environ 35 à 50 dollars par mois — ce qui reste abordable au premier abord. Mais nos clients ont un volume qui peut tripler d'un mois à l'autre lors des audits annuels. Et surtout, pour nos traitements de données capteurs, on parle de contextes bien plus larges — jusqu'à 32 000 tokens parfois. Là le coût explose.

Sur notre infrastructure propre (deux serveurs GPU loués chez OVHcloud, 3 000 euros par mois en incluant storage et réseau), le coût marginal par token est quasi nul. Nos 400 rapports nous coûtent peut-être 50 euros en électricité et compute variable. L'amortissement est rentable à partir de 80 000 tokens input par mois — on l'a atteint dès le troisième client.

Les erreurs techniques de nos premiers produits

Quelles erreurs techniques avez-vous faites dans vos premiers produits IA, celles dont vous avez le plus appris ?

Antoine Ferrière : La première et la plus coûteuse : croire que la qualité d'un LLM sur un benchmark est prédictive de sa performance sur nos données industrielles. On a choisi notre premier modèle de base sur des leaderboards publics. En production, il hallucinait régulièrement des valeurs numériques — des températures, des pressions, des concentrations — qui n'existaient nulle part dans les données. Dans un contexte industriel, une valeur inventée dans un rapport de conformité c'est potentiellement une infraction réglementaire grave. On a dû rappeler des rapports chez deux clients. C'était la leçon la plus douloureuse.

La deuxième erreur : ne pas avoir de monitoring de qualité dès le premier jour. On mesurait la latence et le taux d'erreur technique, mais pas la qualité des réponses. On a découvert que notre système se dégradait progressivement avec des requêtes edge case uniquement parce qu'un client nous a signalé des anomalies après trois mois. Maintenant on a un pipeline d'évaluation automatique sur un jeu de test doré, lancé à chaque déploiement.

Troisième erreur : avoir fait confiance à nos intuitions sur ce que les clients voulaient plutôt que de le mesurer. On avait imaginé une interface riche avec visualisations et drilldown. Nos clients voulaient juste un PDF bien formaté dans leur boîte mail. Six semaines de développement front à jeter. Validez avant de construire.

Évaluer la fiabilité d'un modèle avant de le mettre en production

Comment évaluez-vous la fiabilité d'un modèle avant de le mettre en production sur un produit client ?

Antoine Ferrière : Notre processus d'évaluation comporte trois couches. Première couche : les benchmarks sectoriels. On a constitué un jeu de test doré de 200 cas réels tirés de rapports que nos clients ont validés. Chaque candidat modèle passe ce benchmark, on mesure l'exactitude sur les données numériques, la cohérence avec les sources (pas d'hallucination), et la qualité du formatage. Un modèle qui passe en dessous de 90 % d'exactitude numérique est éliminé.

Deuxième couche : les red teaming internes. On essaie activement de faire échouer le modèle : prompts adversariaux, données aberrantes, cas limites de notre domaine. On cherche les hallucinations, les raisonnements circulaires, les inventions de chiffres.

Troisième couche : le pilote client contrôlé. Avant tout déploiement général, on fait tourner le nouveau modèle en parallèle de l'ancien sur un client volontaire pendant deux semaines. Un opérateur chez le client compare les deux sorties sur ses vraies données. C'est le seul vrai test qui compte — les benchmarks artificels ne remplacent jamais la production réelle.

Recruter des profils ML à Lyon

Comment recrutez-vous des profils ML et IA à Lyon, en dehors des hubs tech parisiens où la concurrence est féroce ?

Antoine Ferrière : La localisation à Lyon est devenue un avantage, pas un handicap — à condition de le valoriser correctement. Paris, c'est le salaire le plus haut mais aussi le coût de la vie le plus élevé, le temps de transport le plus long, et la concurrence des GAFAM et des grandes licornes qui font de la surenchère permanente. À Lyon, on propose des salaires légèrement inférieurs à ceux de Paris mais un package global bien supérieur en qualité de vie. On recrute des profils qui veulent construire quelque chose de concret, pas juste grossir le bilan d'un grand groupe.

Notre pipeline de recrutement passe principalement par trois canaux. Première source : l'INSA Lyon et l'École Centrale — on maintient des partenariats actifs, on encadre des projets de fin d'étude, et on convertit régulièrement des stagiaires en CDI. Deuxième source : la communauté open source. Deux de mes développeurs ML sont des contributeurs actifs à des projets comme Ollama ou LangChain — je les ai repérés sur GitHub. Troisième source : les meetups French Tech AuRA et PyData Lyon, où on présente régulièrement nos travaux. Les personnes qui viennent nous parler après une présentation sont généralement bien qualifiées et déjà intéressées par ce qu'on fait.

Ollama en production : viable ou gadget ?

Ollama est très populaire dans la communauté. Est-ce un outil viable pour la production ou plutôt un outil de développement ?

Antoine Ferrière : Ollama est excellent pour le développement et les prototypes — on l'utilise massivement dans nos environnements dev et pour les démos clients. Il a la simplicité parfaite pour ça. En production, ses limites deviennent visibles assez vite. Le principal problème : il traite les requêtes séquentiellement par défaut. Quand 10 utilisateurs envoient des requêtes simultanément, les 9 premiers attendent. Pour un produit SaaS avec des SLA de réponse, c'est problématique.

On a migré vers vLLM pour notre stack de production il y a 8 mois. vLLM supporte le continuous batching — il traite plusieurs requêtes simultanément en optimisant l'utilisation du GPU — et la latence moyenne de nos rapports a baissé de 40 %. La configuration est plus complexe mais le résultat en vaut la peine. Ollama en production reste utilisable pour des charges faibles (moins de 5 requêtes simultanées) ou des usages internes non critiques. Pour un SaaS B2B en croissance, vLLM ou TGI de HuggingFace sont mieux adaptés.

Idées reçues sur les startups IA (5 vrai/faux)

"Les startups IA ont besoin de GPU A100 pour commencer." — FAUX. Les modèles 7B-13B open source tournent très bien sur des RTX 3080 ou 4080 grand public en développement. En production, des serveurs GPU mutualisés chez OVHcloud ou Hetzner sont accessibles dès 500 euros par mois. Les A100 sont nécessaires pour le fine-tuning de modèles larges — ce n'est pas la première priorité d'une startup.

"Les clients B2B ne font pas confiance à l'IA générative pour des décisions critiques." — DE MOINS EN MOINS VRAI. En 2024-2025, oui. En 2026, les industriels commencent à intégrer l'IA dans leurs processus réels, avec des garde-fous (validation humaine sur les alertes critiques, traçabilité des sources). La confiance se construit par des résultats mesurables et une transparence sur les limites.

"Il faut être à Paris pour lever des fonds en France." — FAUX depuis 2022. Les investisseurs B2B industriels regardent les KPIs, pas l'adresse. Bpifrance, les fonds régionaux et les CVs industriels investissent très activement en dehors de Paris. Notre seed a été levé entièrement avec des investisseurs lyonnais et rhône-alpins.

"L'IA va rendre les développeurs de ma startup inutiles." — FAUX dans notre contexte. L'IA a rendu notre équipe plus productive, pas plus petite. On produit deux fois plus de features avec la même équipe. Mais quelqu'un doit toujours concevoir l'architecture, évaluer la qualité, gérer l'infrastructure. Le développeur devient chef d'orchestre plutôt qu'exécutant.

"Une bonne API suffit à faire un bon produit IA." — FAUX. L'API est 10 % du produit. Les 90 % restants, c'est la gestion des erreurs, le monitoring, l'UX, les intégrations clients, le support, la conformité réglementaire. Les startups qui traitent l'IA comme une feature additionnelle d'un produit SaaS classique ont plus de succès que celles qui construisent autour de la techno IA.

Quel conseil pour un développeur qui veut lancer sa startup IA aujourd'hui ?

Quel conseil donneriez-vous à un développeur qui veut lancer sa startup IA aujourd'hui, en s'inspirant de votre parcours ?

Antoine Ferrière : Trouvez un problème avant de trouver une solution. Pas "je vais faire une startup IA" — mais "je vais résoudre ce problème précis dans ce secteur précis, et je vais utiliser l'IA parce que c'est la meilleure approche". La tech IA est fascinante mais elle ne fait pas un business seul. La douleur client fait un business.

Commencez avec une API cloud pour valider votre cas d'usage. Passez à l'open source en local quand les contraintes de coût ou de confidentialité l'imposent. Ne sur-ingénieriez pas votre premier produit — un prototype RAG sur LangChain + Mistral + une interface simple peut suffire à valider votre marché en 4 semaines. Pour les entreprises qui cherchent des solutions logicielles métier prêtes à l'emploi plutôt qu'un développement sur-mesure, Softaid illustre bien comment des outils bien ciblés peuvent répondre à des besoins opérationnels concrets sans passer par une startup IA.

Impliquez des clients dans votre développement dès le premier jour. Pas des amis qui font semblant d'utiliser votre produit — de vrais clients qui payent ou qui s'engagent à payer dès la sortie du MVP. Le feedback de quelqu'un qui a payé est infiniment plus précieux que celui de quelqu'un qui utilise gratuitement.

Et apprenez à mesurer. Chaque décision technique devrait être basée sur des métriques, pas sur des intuitions. Latence, qualité, coût, satisfaction client — si vous ne mesurez pas, vous naviguez à l'aveugle. Pour les implications en matière de recrutement IA et de transformation des organisations, notre guide sur l'IA dans les RH et le recrutement donne un éclairage complémentaire utile. Et si vous vous demandez comment les PME qui seront vos clients gèrent la cybersécurité de leurs systèmes IA, l'interview de Sarah Maubert, RSSI PME, vous donnera leur perspective.