IA appliquée et agents
Les modèles d’IA ouvrent des possibilités considérables. Mais ils ne sont jamais le point de départ.
Le point de départ, c’est le métier : le problème à résoudre, la décision à améliorer, l’usage à rendre possible et les contraintes qui vont avec. Le choix d’un modèle, d’un agent ou d’une architecture vient ensuite.
C’est particulièrement vrai avec les LLMs. Une démonstration convaincante peut tenir dans un bon prompt. Un système qui doit fonctionner tous les jours, avec de vraies données et de vraies conséquences, demande beaucoup plus : une architecture, des garde-fous, une manière de mesurer ses erreurs et une responsabilité claire sur ce qu’il produit.
Une pratique de l’IA qui précède les LLMs
Notre expérience avec les modèles ne commence pas avec ChatGPT.
Nous travaillions déjà avec les premiers transformers, GPT-1, GPT-2 et GPT-3, ainsi qu’avec des modèles NLP comme spaCy, Word2Vec ou Sense2Vec, entraînés ou adaptés à des problématiques métier très spécialisées.
Une partie de l’équipe Vezero vient par ailleurs de l’équipe technique initiale d’Owkin, où modèles de machine learning, produit et données étaient déjà étroitement mêlés. Cette expérience a fortement influencé notre manière d’aborder les systèmes intégrant de l’IA : un modèle n’a de valeur que dans le système qui l’entoure et dans la décision qu’il permet de prendre.
Depuis, nous avons continué à travailler sur des problématiques très différentes : modèles de langage spécialisés, expériences conversationnelles, agents, interfaces temps réel, analyse de données, outils métiers et systèmes d’aide à la décision. Les missions Vezero couvrent notamment des sujets en medtech, industrie, énergie, cosmétique, agroalimentaire et logiciels B2B.
Quatorze projets intégrant des modèles d’IA sont aujourd’hui en production.
Le métier avant le modèle
Nous commençons rarement par demander quel modèle utiliser.
Nous cherchons d’abord à comprendre ce qui doit réellement fonctionner : quelle information est disponible, ce que l’utilisateur cherche à obtenir, quelles erreurs sont acceptables, quelles décisions peuvent être automatisées et lesquelles doivent rester sous contrôle humain.
À partir de là seulement viennent les choix techniques.
Un modèle plus puissant n’est pas toujours une meilleure réponse. Un agent n’est pas toujours préférable à un workflow déterministe. Un système multi-agent n’a d’intérêt que si le problème exige réellement plusieurs capacités capables de coopérer ou de se sélectionner dynamiquement.
De la démonstration à la production
Un système IA qui fonctionne en démonstration et un système IA qui tient en production sont deux objets différents.
La démonstration cherche surtout à montrer qu’un comportement est possible.
La production doit répondre à d’autres questions : le système produit-il toujours quelque chose d’acceptable ? Peut-on comprendre pourquoi il échoue ? Peut-on mesurer l’impact d’un changement de modèle ou de prompt ? Que se passe-t-il lorsque les données sont incomplètes ? Quelle information peut être envoyée à quel fournisseur ? Quel niveau d’autonomie peut-on réellement accorder au système ?
Ces questions structurent notre manière de travailler.
| Démonstration | Production |
|---|---|
| Un prompt convaincant | Une architecture |
| Quelques cas testés | Une évaluation continue |
| Des données préparées | Des données réelles |
| Une erreur visible | Une erreur observable |
| Un humain devant l’écran | Des garde-fous |
| Un coût négligeable | Un coût à l’échelle |
Données et contexte
Un modèle ne connaît que ce qu’on lui donne.
Il faut donc savoir d’où viennent les données, si elles sont fiables et suffisamment fraîches, comment elles sont sélectionnées, ce que chaque utilisateur est autorisé à voir, et comment le contexte envoyé au modèle est construit.
Dans certains cas cela passe par du RAG, dans d’autres par des modèles spécialisés, des outils métier ou simplement une préparation plus rigoureuse de l’information.
La bonne architecture dépend du problème.
Évaluation
Avec un système probabiliste, « ça marche bien » n’est pas une mesure suffisante.
Nous cherchons à définir des cas métier représentatifs, des comportements attendus et des erreurs importantes avant de faire évoluer le système.
Cela permet de comparer les versions, les modèles ou les prompts sur autre chose qu’une impression.
Plus la sortie du système influence une décision importante, plus cette capacité à évaluer devient centrale.
Garde-fous et autonomie
La question n’est pas seulement de savoir ce qu’un modèle peut faire, mais ce qu’il doit avoir le droit de faire seul.
Certaines tâches peuvent être entièrement automatisées. D’autres nécessitent une validation explicite, une règle déterministe ou un retour vers l’utilisateur.
Nous cherchons à adapter le niveau d’autonomie aux conséquences d’une erreur.
Un agent qui propose une formulation de texte et un agent qui modifie une donnée métier critique ne doivent pas être conçus de la même manière.
Observabilité
Lorsqu’un système s’appuie sur des modèles externes ou probabilistes, il faut pouvoir comprendre ce qu’il s’est passé.
Prompts, réponses, appels d’outils, erreurs, latence, coûts, version des modèles : ces informations doivent être observables lorsque le contexte l’exige.
Sans cela, améliorer un système devient vite une succession d’intuitions.
Performance et coût
La qualité de la réponse n’est qu’une partie du problème.
Une interaction peut devenir inutilisable si elle met dix secondes à répondre. Un modèle très performant peut être disproportionné pour une tâche simple. Un agent peut multiplier les appels, et donc la latence et le coût.
Nous arbitrons donc modèle, parallélisation, cache, streaming, outils et architecture en fonction de l’expérience attendue et de l’économie réelle du produit.
Les agents, quand le problème les justifie
Nous ne construisons pas un agent lorsqu’un workflow classique suffit. Et nous ne construisons pas dix agents lorsqu’un seul suffit.
Une architecture agentique devient utile lorsqu’un système doit interpréter une situation, choisir parmi plusieurs capacités, utiliser différents outils ou adapter sa trajectoire selon les résultats intermédiaires.
Chaque degré d’autonomie apporte cependant de nouveaux chemins d’exécution, donc davantage de choses à tester, observer et sécuriser.
Nous l’avons constaté en développant une plateforme conversationnelle temps réel. Elle nous a amenés à travailler sur l’orchestration dynamique de nombreux agents spécialisés, sur leur sélection en fonction du contexte, et sur les contraintes de latence nécessaires pour conserver une expérience conversationnelle naturelle. Cette technologie a ensuite été intégrée dans plusieurs produits clients.
Vers le bas : plus d’autonomie, d’incertitude, de coût et d’observabilité nécessaire
Ce que nous avons déjà construit
Nos projets couvrent plusieurs familles de problématiques.
Modèles appliqués à des métiers spécialisés
Nous travaillons notamment avec Predicity sur des outils destinés à l’industrie de la parfumerie et de la cosmétique, intégrant des modèles de langage spécialisés dans des environnements métier exigeants. D’autres missions concernent l’agroalimentaire, l’industrie ou la medtech.
Orchestration et expériences conversationnelles
Gustav et Generous nous ont amenés à concevoir des expériences où plusieurs capacités IA interviennent dans une même interaction, avec des contraintes de temps réel et d’interface.
IA et interfaces temps réel
Des projets comme Kyutai ou Aircall nous ont confrontés à des problématiques où la qualité du modèle ne suffit pas : latence, lisibilité de la recommandation, confiance et interaction avec l’utilisateur deviennent tout aussi importantes.
IA intégrée à un produit métier précis
Sur Decante, l’IA reste volontairement limitée à certains usages où elle apporte une valeur claire. Le reste du produit repose sur des mécanismes déterministes classiques. C’est aussi notre manière de concevoir l’IA appliquée : utiliser un modèle là où il améliore réellement le produit, pas parce qu’il est disponible.
Machine learning à forte contrainte métier
L’expérience acquise notamment chez Owkin ou sur des projets comme Deeplife nous a appris qu’un modèle ne peut pas être séparé des données, de l’interface et des conséquences opérationnelles de sa sortie.
Des modèles aux produits
Nous travaillons avec des modèles propriétaires comme open source, des modèles généralistes comme spécialisés, et avec les différentes briques nécessaires pour les intégrer dans des produits réels.
Le choix de la technologie vient après celui de l’architecture et du niveau d’autonomie attendu.
Notre travail ne consiste donc pas à défendre un fournisseur, un framework ou une manière unique de construire des systèmes IA.
Il consiste à choisir les composants adaptés au problème, puis à faire en sorte que l’ensemble reste observable, maintenable et exploitable dans la durée.
Notre façon de cadrer, d’arbitrer et de nous engager est décrite en détail dans la méthode Vezero.