L’IA dans Dvore : architecture, choix techniques et questions ouvertes

Un constat s’impose depuis quelques mois dans les discussions autour de l’IA appliquée aux produits : la tentation de réduire l’architecture à sa couche la plus visible. Un LLM, un prompt, une interface conversationnelle, et le tour est joué. Notre lecture est différente. Les modèles de langage reconfigurent profondément la façon d’interagir avec les systèmes, mais ils ne se substituent pas aux architectures sous-jacentes. Ce post décrit comment on structure cette réflexion chez Dvore, ce qu’on a appris empiriquement, et les questions qui restent ouvertes.

Un programme R&D structuré 

Dvore développe depuis 2019 un outil SaaS de pilotage décisionnel pour les réseaux de restauration. À partir de 2021, les problématiques qu’on cherchait à résoudre ont franchi un seuil : il n’était plus possible d’avancer sans adopter une démarche expérimentale formalisée.

Les deux axes de travail identifiés à cette époque restent les mêmes aujourd’hui :

• Prédiction : modéliser les indicateurs clés (chiffre d’affaires, fréquentation, ratios RH) en intégrant des facteurs endogènes (historique d’activité, promotions, réservations) et exogènes (météo, jours fériés, événements locaux)
• Interprétation : automatiser les tâches d’un contrôleur de gestion, détection d’anomalies, génération d’alertes, recommandations d’actions, sans nécessiter de paramétrage expert en amont

Pour structurer ce travail, on a recruté Elhadi Belghache, docteur en informatique spécialisé en intelligence artificielle et systèmes multi-agents adaptatifs (thèse IRIT / équipe SMAC, Toulouse), dont les travaux portent notamment sur le traitement de données massives de façon non-centralisée et adaptative. Ce programme a obtenu le statut Jeune Entreprise Innovante, reconnaissance formelle d’une démarche R&D..

Ce qu’on a appris sur les données réelles

Le premier chantier concret : prédire le chiffre d’affaires, restaurant par restaurant.

On a benchmarké une dizaine de méthodes sur des données réelles, plusieurs centaines de restaurants, des historiques allant de quelques mois à plusieurs années, avec intégration de variables externes. Le protocole expérimental a suivi les bonnes pratiques de la littérature sur l’analyse de séries temporelles.

Le résultat est contre-intuitif mais cohérent avec ce que la littérature signale sur les séries temporelles quasi-aléatoires à faible volume : les réseaux neuronales profonds (technique d’apprentissage à la pointe de l’IA) n’arrivent pas à extraire de caractéristiques exploitables, pour de bonnes prédictions, quand les données sont insuffisantes en volume et en diversité et donc sous performent comparés à des algorithmes statistiques avancés (moins gourmands en données et plus efficaces).

Ce constat a une implication directe sur notre approche produit : la performance d’un modèle prédictif dépend d’abord de la qualité et de la structuration de la donnée, pas toujours de la sophistication de l’algorithme. Et prédire, c’est déjà le problème le moins complexe. Le vrai défi est d’extraire automatiquement des règles métiers, des patterns qui expliquent pourquoi un restaurant bascule d’un état rentable à un état en difficulté, sans connaissances expertes codées en dur, sur des données qui évoluent en continu.

C’est ce constat qui a conduit à l’architecture qu’on construit aujourd’hui.

L’architecture cible : 4 couches

Le benchmark sur les données réelles de restauration a confirmé quelque chose qu’on pressent depuis le début : la valeur n’est pas toujours dans la sophistication du modèle. Elle est dans ce qu’on lui donne à traiter, et dans la façon dont on encadre ce qu’il peut faire.

C’est exactement le problème qu’on observe aujourd’hui avec les LLM et les agents. Un modèle de langage exposé directement à un ensemble de données hétérogènes, sans contexte formalisé ni interfaces définies, produit des résultats statistiquement plausibles mais métier incorrects, et surtout, imprévisibles. La démo fonctionne. La production, non.

La conclusion qu’on en tire est simple : un agent IA n’est pas une solution en soi. C’est une couche dans une architecture. Et la qualité de ce qu’il produit est entièrement conditionnée par la qualité de ce qui est en dessous de lui. Réfléchir à l’usage de l’IA sans réfléchir à l’architecture complète revient à optimiser la couche de présentation d’une application dont la base de données est mal modélisée.

C’est sur cette conviction qu’on structure notre approche, autour de quatre couches distinctes, avec des responsabilités non délégables d’une couche à l’autre.

Couche 1 | Data

Ingestion multi-sources (caisses, RH, réservations, plateformes de livraison), normalisation, historisation, application des règles métiers explicites. C’est la fondation. Actuellement les LLM ne nettoient pas les données de façon autonome, elles n’ont pas forcément tous les éléments pour réaliser les arbitrages sur les règles à appliquer pour rendre les données propres. C’est en travaillant directement avec chaque client sur la compréhension de ses process internes que l’on peut au final fiabiliser cette base. Si cette couche est fragile, tout ce qui est au-dessus l’est aussi, et de façon opaque, ce qui est pire.

Couche 2 | Sémantique

C’est la couche la plus sous-estimée dans les architectures qu’on voit déployées en production. Son rôle : formaliser les concepts métier (qu’est-ce qu’un “site en rentabilité limitée” ? à partir de quel seuil un ratio RH devient-il une anomalie ?), contextualiser les indicateurs et les événements, créer un pont entre langage humain et données (#exemple d’une question complexe pour trouver un dashboard avec beaucoup de filtrage ). Sans cette couche, un agent manipule des données dont il ne comprend pas la sémantique, et génère des sorties statistiquement plausibles mais incorrectes d’un point de vue métier.

Couche 3 | MCP / API

L’exposition des données via des interfaces stables, documentées et gouvernées. L’agent n’accède jamais directement à la donnée brute, il appelle des services qui encapsulent la logique métier, garantissent la traçabilité des accès, et permettent d’appliquer des règles de sécurité et de gouvernance. Le protocole MCP (Model Context Protocol) s’impose progressivement comme standard pour cette exposition, il permet à un agent externe de découvrir et d’appeler des outils métier de manière structurée, sans accès non contrôlé aux sources.

Couche 4 | AI

LLM pour le raisonnement en langage naturel et la génération, agents pour l’orchestration de tâches complexes, interfaces conversationnelles. C’est la couche la plus visible, et paradoxalement la moins déterminante si les trois premières sont bien construites. Un LLM exposé à une couche sémantique propre et à des APIs bien définies peut être extrêmement efficace. Le même LLM exposé directement à des données brutes mal structurées produit des résultats imprévisibles.

Le principe central : les agents et les LLM sont une couche d’interprétation et d’orchestration, pas une source de vérité. Un LLM ne garantit pas la cohérence temporelle d’une série de données. Il ne reconstruit pas un modèle métier fiable à partir de données incomplètes. C’est pour ça que les architectures robustes convergent vers de la mémoire structurée, des appels MCP typés, des garde-fous explicites, et non vers une logique entièrement portée par le prompt.

Agents internes vs agents externes

La distinction est importante sur le plan architectural.

Les agents externes, copilots généralistes intégrés via API, offrent une puissance de raisonnement réelle et un déploiement rapide. Leurs limites en production : gouvernance de la donnée difficile à garantir dès qu’on manipule des données clients sensibles, futur coût des token difficile à prévoir à l’échelle, traçabilité limitée des décisions, quasi-impossibilité de tester de manière déterministe une chaîne de raisonnement.

Les agents internes, spécialisés, intégrés directement dans le produit, répondent à ces contraintes : accès aux APIs métier via une architecture contrôlée, traçabilité complète, coûts modélisables. On peut raisonner sur le coût d’un agent interne comme sur un coût RH : onboarding (définition des outils et du contexte), formation (évaluation et ajustement), productivité mesurée, maintenance continue. C’est un changement de paradigme opérationnel, pas seulement technique.

Notre approche : les deux modèles cohabitent. On développe actuellement un agent interne spécialisé contrôle de gestion, ancré dans notre verticale métier. Les premiers usages sont actuellement en bêta test chez nos clients.

Parallèlement, on construit une interface MCP avec une couche sémantique propre pour que des agents externes puissent s’appuyer sur des fondations fiables quand ils interagissent avec nos données.

Questions ouvertes

Tout n’est pas stabilisé, et c’est le propre d’une démarche R&D honnête que de le dire.

Les questions sur lesquelles on travaille activement :

• Quel niveau d’autonomie accorder à un agent en production, sur des décisions qui ont un impact opérationnel réel ?
• Comment garantir la traçabilité complète d’une décision issue d’une chaîne agent + LLM ?
• Quel degré de non-déterminisme est acceptable dans un système de recommandation métier ?
• Comment construire une suite de tests robuste sur une architecture où une partie de la logique est apprise et non codée explicitement ?
• Où placer la frontière entre règles explicites et logique déléguée à un modèle, et comment cette frontière évolue-t-elle avec la maturité des données ?
• Quels outils et structures de représentation de données sont les plus adaptés aux agents ?

Ce sont précisément ces questions qui définissent le périmètre de notre R&D en cours. On documente les expérimentations, les résultats et les impasses, parce que sans cadre théorique solide, l’expérimentation empirique seule ne produit pas de connaissances transférables.

Conclusion

L’IA ne simplifie pas les architectures logicielles. Elle en déplace la complexité, moins dans l’interface, plus dans la structuration des données et la définition des services. Dans ce contexte, la question opérationnelle pertinente n’est pas “comment ajouter de l’IA à notre produit ?” mais “sur quelles fondations techniques cette IA va-t-elle s’appuyer ?”. Chez Dvore, ces fondations sont en construction depuis le début, imparfaites et challengées en permanence, mais pensées pour tenir dans le temps en production.