Comment Batch a construit l'architecture IA derrière AI Assist ?

Les intégrations IA dans les outils CRM du marché sont souvent décevantes : un champ texte libre, un appel API vers un modèle, la réponse brute affichée à l'écran. Un wrapper autour d'un seul LLM, sans orchestration ni contrôle qualité. Et ça se voit dans le résultat. C'est précisément ce que la stack de Batch évite.

Ce que vous voyez dans Batch AI Assist, et pourquoi cette IA générative est différente

Dans Batch AI Assist, les agents ne discutent pas : ils exécutent. Rédiger des variantes de contenu, adapter le ton et les emojis, traduire une campagne dans 30 langues, générer des tests A/B/N, nommer automatiquement les étapes d'un scénario d'automatisation.

La vraie valeur de ce produit tient à un principe : l'intelligence se trouve là où le travail se fait. Pas dans une fenêtre de chat à côté de votre outil. Pas dans un assistant externe à qui vous devez réexpliquer votre contexte à chaque fois. Dans l'interface, au moment précis de l'action, avec le contexte déjà fourni.

Assist prend deux formes. Des agents ponctuels, déclenchés en zéro ou un clic, intégrés exactement au point de travail. Exemple public : le Step Name Generator dans l'Automation Builder, qui génère automatiquement un libellé descriptif pour chaque étape d'un scénario depuis son contenu réel. Et un agent opérateur sur la page Intelligent Home, qui pousse des recommandations et des alertes de façon proactive, avec une interface de chat pour dialoguer.

Un assistant externe ou une connexion MCP impose de réinjecter manuellement le contexte qu'un agent intégré possède déjà. C'est précisément ce que l'architecture d'Assist évite.

Pourquoi Batch a construit sa propre gateway IA

Pourquoi c'est important : les fonctionnalités IA sortent vite dans tout le produit, et restent stables quand le paysage des modèles change toutes les deux semaines. C'est la raison d'être de notre gateway : la couche intermédiaire qui connecte tous les agents produit aux modèles IA, sans que chaque équipe ait à parler directement à Anthropic, OpenAI ou Google.

Batch a d'abord regardé ce qui existait sur le marché, puis a choisi de construire sa propre gateway. Les solutions disponibles étaient coûteuses, et auraient de toute façon dû être intégrées de force à notre système d'utilisateurs et d'entreprises. Repartir d'une page blanche s'est imposé comme l'option la plus logique.

La gateway maison repose sur trois briques.

Une abstraction unifiée pour les squads produit. Une seule interface interne, calquée sur un standard largement adopté dans l'industrie (celui d'OpenAI). Chaque squad développe contre un endpoint unique au lieu d'apprendre l'API de chaque fournisseur. Quand un nouveau modèle sort chez Anthropic, OpenAI ou Google, nos experts font la veille et lissent les différences entre les modèles, pour que les équipes n'aient jamais rien à réapprendre.

L'aliasing des noms de modèles. Les agents font référence à des alias lisibles, découplés des identifiants versionnés des modèles. On met à jour le modèle sous-jacent sans casser un seul agent ni toucher au code applicatif. Quand un fournisseur déprécie un modèle, il suffit de changer l'alias en configuration : aucun chantier de migration à lancer.

La gouvernance native. Limites d'usage définies par utilisateur et par entreprise, journalisation des requêtes, suivi des coûts au token : voilà une infrastructure gouvernée, pensée dès sa conception pour opérer à l'échelle de centaines de clients.

Le bon modèle IA pour le bon usage marketing

La différence entre "un bouton IA" et un agent qui produit un résultat publiable sans relecture lourde, c'est ici que ça se joue.

Chaque agent tourne sur un modèle de pointe sélectionné pour son usage précis. Anthropic, OpenAI, Google (Gemini), Mistral : un mélange est en production. Et le prompt est conçu autour de ce modèle spécifique.

Changer de modèle n'est pas un réglage de configuration. Un prompt optimisé pour un modèle perd en performance dès qu'on le bascule sur un autre. Un modèle moins adapté placé sur le mauvais usage dégrade directement la qualité perçue par le marketeur.

Ce point mérite d'être posé clairement : un éditeur dont l'argument de vente est "apportez votre propre clé d'API, utilisez n'importe quel modèle" admet implicitement que ses agents sont agnostiques au modèle. Ce qui veut souvent dire sous-optimisés. Choisir un modèle par usage traduit un engagement de qualité assumé.

Évaluer la qualité d'un agent IA : comment Batch mesure et sécurise ses résultats

Une IA peut impressionner sur une démo unique et décevoir en usage quotidien. L'évaluation systématique garantit la seconde, pas seulement la première.

Les LLM sont non déterministes : à entrée identique, la sortie varie. Et elle change dès qu'on touche au modèle, à ses réglages internes qui pilotent sa créativité et sa précision, ou à la formulation de la consigne qu'on lui donne. Sans mesure de la qualité, impossible de savoir si une mise à jour améliore le produit ou le dégrade en silence.

Batch évalue à trois moments.

1. Au moment du choix. On tranche entre modèles et prompts sur un jeu de données rigoureux, pas en regardant deux ou trois exemples à l'oeil.

2. À chaque changement dans le temps. Un fournisseur sort un nouveau modèle, en déprécie un ancien, ou l'équipe améliore un prompt. On lance une évaluation comparative pour confirmer que c'est une amélioration, pas une régression.

3. En production. On échantillonne des traces d'exécution réelles et on surveille en direct avec des alertes. Les entrées des vrais utilisateurs ne sont jamais totalement prévisibles.

Cette mécanique repose sur un outil spécialisé, Langfuse, qui centralise les prompts, les jeux de test, l'exécution des contrôles qualité, la notation des réponses et le suivi de chaque appel en production.

La méthode repose sur quatre piliers.

Un jeu de données de référence de 100 à 1 000 exemples représentatifs et variés, appariant entrées et sorties attendues. Généré par IA puis vérifié par un humain, ce qui ramène l'annotation de plusieurs mois à quelques jours. Chaque révision est tracée et versionnée comme du code, avec possibilité de comparer deux versions et de revenir en arrière.

Le versioning des prompts. Chaque prompt est versionné et associé à un alias de modèle. Avant de promouvoir un changement, on rejoue une éval sur l'ancienne et la nouvelle version. L'historique reste disponible pour un rollback immédiat si une régression passe en production.

Des évaluateurs de code déterministes. Contrôles durs et calculables : conformité du format, présence des champs requis, parité des tokens.

Des évaluateurs automatiques, pilotés par un second modèle qui joue le rôle de relecteur. Il note chaque réponse d'un échantillon selon des critères précis et explique son raisonnement, un peu comme un correcteur qui justifierait sa note. Subtilité importante : ce relecteur automatique peut tourner sur un modèle plus puissant que celui qui sert la fonctionnalité. La première passe tourne sur un modèle rapide et économique ; la relecture est confiée à un modèle plus capable.

Un exemple concret d'IA générative dans le CRM: la traduction d'emails

La fonctionnalité de traduction d'email est un bon cas d'école, parce que les enjeux sont à la fois qualitatifs et opérationnels.

Elle est validée par une batterie d'évaluateurs sur les deux types.

Côté relecture automatique : fidélité de la traduction, justesse de la langue cible, fidélité de l'objet et du preheader, préservation des entités (noms de marques, produits, variables de personnalisation). Chaque dimension est notée de 1 à 5 avec raisonnement : fluidité et naturel, justesse terminologique, accord de registre et de ton.

Côté code déterministe : présence de l'objet, présence du preheader, comptage des tokens, parité des tokens. Ce dernier point est critique : chaque token de personnalisation présent dans la source doit l'être aussi dans la traduction. Une traduction qui perd un token, c'est un prénom absent, répété dans des milliers d'emails envoyés à vos contacts.

Ces relecteurs automatiques couvrent le sens, ce qu'un relecteur humain irait vérifier. Les évaluateurs de code couvrent la structure, ce dont dépend concrètement l'envoi d'une campagne. Un bouton "traduire avec l'IA" concurrent n'a aucun de ces garde-fous.

Vos données clients ne quittent jamais votre contrôle, même avec l'IA

Vous obtenez la qualité d'un modèle de pointe sans confier les données de vos clients à un fournisseur de modèles de pointe.

La couche générative d'Assist ne reçoit jamais les données personnelles de vos clients. Les agents travaillent sur des métadonnées techniques : noms de campagnes, contenu de la plateforme. Jamais sur des données personnelles de clients finaux.

Deux faits ancrent ce principe. Les données du client A ne servent jamais le client B. Pour Assist, Batch n'entraîne aucun modèle sur les données client : Batch fournit du contexte au modèle pour générer une réponse, pour ce même client. Pour les métadonnées techniques qui transitent, les fournisseurs sont des acteurs de pointe (Anthropic, OpenAI, Google), et Batch reste responsable de traitement pour ces données limitées et non personnelles.

À titre de contraste : Predict repose sur un autre socle, du machine learning entraîné par client, opéré par Batch sur une infrastructure contrôlée par Batch en Europe.

Ce principe répond sur le fond à l'objection "un modèle américain, c'est non". Quand aucune donnée personnelle ne transite, la préoccupation de souveraineté sur la couche générative se dissout en grande partie.

Prochaine étape pour l'IA CRM : l'inférence souveraine

Pour les organisations les plus sensibles à la souveraineté, l'objectif est un CRM agentique où rien de votre activité ne dépend d'un cloud américain.

La philosophie de Batch : confidentialité et souveraineté radicales des données, sur une infrastructure que Batch contrôle (bare metal). Aujourd'hui, aucune donnée personnelle ne sort pour la couche générative, donc les modèles de pointe américains sont sûrs à utiliser pour les métadonnées techniques limitées concernées.

La direction que Batch explore : faire tourner des modèles open source sur ses propres GPU loués, dans les datacenters où Batch héberge déjà ses serveurs. En pratique, cela signifie utiliser une infrastructure cloud européenne comme OVHcloud pour faire tourner la couche générative en dehors de toute dépendance aux fournisseurs américains. Pour que même les métadonnées techniques limitées restent sur une infrastructure que Batch contrôle.

La minimisation des données existe déjà chez Batch, la prochaine étape : l'inférence souveraine auto-hébergée.

Et ensuite : d'où vient le contexte de l'IA dans votre CRM ?

Cet article a volontairement laissé de côté une question centrale : comment les agents reçoivent-ils leur contexte ? Ils sont ancrés dans des années d'expertise CRM, dans le contenu de la plateforme de chaque client, dans la structure de leur CRM. Mais comment ce contexte leur parvient-il ?

Ce sujet sera abordé dans un futur article : retrieval, RAG, semantic engine, et comment on maintient ce contexte ancré, précis, et privé.

Capabilities we built ourselves. Rigor we measure. Trust by design. Sovereignty on the horizon. N'importe qui peut ajouter un bouton IA. Peu d'acteurs peuvent assumer ce qui en sort.