la mise en œuvre

Plateformes IA et agents en production

Je vous aide à construire une plateforme LLM ou à mettre un agent IA en production, avec vos équipes et à partir de votre système existant.

deux formats d’intervention

Socle de plateforme IA

Un accès commun aux modèles, avec les permissions, le suivi des coûts et les outils nécessaires à leur exploitation.

voir le périmètre complet

Concevoir le socle commun aux modèles hébergés, sous contrôle client ou auto-hébergés : routage, identité, observabilité, évaluations et exploitation au quotidien.

architecture de plateformestratégie hébergée, sous contrôle client ou auto-hébergéepasserelle de modèlesauthentification et contrôle d'accèsroutage, quotas et budgetsinférence GPU sur Kubernetesqualification des modèlesobservabilitéinfrastructure d'évaluationjournalisation d'auditmodèle de coûts et de capacitéfeuille de route de livraison

Sprint de mise en production agentique

Faire fonctionner un agent sur un processus métier précis, avec des actions autorisées, des validations humaines et une reprise en cas d’échec.

voir le périmètre complet

Partir d'un processus mêlant humains et code, ou d'un prototype d'agent. Affecter chaque étape au code déterministe, à un appel LLM structuré, à une boucle agentique bornée ou à une approbation humaine, puis les relier par des contrats typés et des évaluations.

observation et décomposition du processuschoix de l'exécuteur : code / LLM / agent / humaincontrats d'entrée et de sortie typéssocle d'exécution et contrôle des outilspermissions et approbation humaineexécution durablejeu d'évaluations et seuils de mise en productionboucle traces → évaluationsgestion des échecs et de la repriseplafonds de coût et d'itérationsobservabilitéarchitecture de déploiement

Explorez l’architecture, couche par couche

Une carte de référence pour relier usages, agents, modèles et contrôles.

Survolez un bloc : la question que je pose pendant une revue de plateforme LLM et agents.

Du modèle à la preuve

Touchez une couche, puis un composant, pour voir la question posée pendant une revue.

Question de revue
Que l’agent a-t-il le droit de décider seul, et où s’arrête exactement son autonomie ?

Travailler ensemble

appel de cadrage de 30 min

Nous précisons la plateforme LLM ou le workflow agentique existant, le résultat attendu et le premier jalon vérifiable.

ou commencer par la revue de preuves

Si le système existe déjà, la revue établit son architecture et hiérarchise les écarts. Le chantier est ensuite défini à partir de constats documentés.

J’interviens personnellement, pour une mission ciblée ou un accompagnement de plusieurs mois. Le périmètre se précise lors du premier échange.

Réalisations et contact

réserver un appel de cadrage de 30 min →commencer par la revue de preuves

Pour approfondir

Ma démarche, avec un exemple de workflow

Deux chantiers possibles : construire le socle LLM commun ou mettre un workflow agentique métier en production.

Indépendamment de tout fournisseur de modèles ou plateforme agentique : choisir quoi acheter, construire ou conserver sous contrôle, puis rendre un workflow LLM ou agentique borné, reprenable et reconstructible de façon indépendante.

// discipline de conception

Du processus réel au workflow agentique fiable.

On ne plaque pas un agent sur une procédure. Chaque décision revient au mécanisme le moins autonome suffisant, puis son autorité augmente uniquement lorsque les preuves le permettent.

01PROCESSUS RÉELobserver le travail exécuté
02FRONTIÈRESisoler confiance et conséquence
03MÉCANISME MINIMALcode · LLM · agent · humain
04PREUVEStester trajectoire et reprise
05AUTORITÉ BORNÉEdéléguer sans abandonner

EXEMPLE · SLICE LOCAL EXÉCUTÉUn incident d’inférence devient un effet borné, vérifié puis réversible.

signal

observer

diagnostic

autoriser

agir

vérifier / reprendre

L’investigation reste en lecture seule. La politique d’exécution accorde une capacité révocable. Un reçu et une nouvelle observation de la cible établissent le résultat.

6 scénarios de fiabilité · aucune revendication cloud

Un plan de contrôle modulaire relie plusieurs entrées de données à des chemins de déploiement managé, hybride et sous contrôle client — Un même plan de contrôle relie identité, politiques, évaluations et preuves, quel que soit le mode d'inférence.

capacités mises en place selon le besoin

plan de contrôle commun

des traces aux évaluations

Les incidents et les trajectoires réelles deviennent des tests de non-régression qui bloquent une version défaillante avant son déploiement.

contrôle de l'accès aux outils

Les permissions et les politiques s'appliquent avant que l'appel n'atteigne le serveur d'outils.

approbation humaine

Les actions sensibles proposées par l'agent attendent une validation humaine, consignée avec l'identité de la personne et les éléments qui ont motivé sa décision.

fiabilité de la recherche documentaire

La recherche respecte les autorisations et vérifie les citations lorsque toute réponse non sourcée constitue un incident.

audit et SIEM

Les appels de modèles, appels d'outils et approbations sont consignés dans un journal en ajout seul et chaîné par hachage, afin de rendre une altération détectable, puis exportés dans un format exploitable par l'équipe de sécurité.

passerelle de modèles

Les API managées et les modèles privés passent par un même point contrôlé : routage, bascule, attribution des coûts, quotas et limites d'exécution.

inférence privée

Service auto-hébergé ou déployé dans le VPC du client, quand une API hébergée ne peut pas satisfaire l'exigence de localisation ou de contrôle.

socle de plateforme

Identité, traçage et contrôles communs évitent à chaque équipe de reconstruire ses propres garde-fous.

le déploiement suit l'exigence

API managée

quand ses contrôles natifs suffisent

couche de contrôle LLM indépendante

quand produits et fournisseurs partagent les mêmes règles

VPC client ou sur site

quand résidence, contrôle ou économie mesurée l’imposent

quand l'inférence sous contrôle client est le bon choix

les données client ne peuvent pas quitter un environnement homologué

vos clients grands comptes exigent un déploiement dans leur propre VPC ou en BYOC

vous avez des exigences explicites de localisation des modèles et des données

plusieurs équipes ont besoin des mêmes contrôles au lieu d'en reconstruire chacune une variante

le volume rend le coût de l'offre hébergée difficile à soutenir

une équipe d'exploitation pourra reprendre la plateforme après le transfert

Contexte et limites des réalisations et mesures

Expérience professionnelle en production

Travaux clients anonymisés par secteur.

Moteur de centralisation IFRS17 · Cycle de provisionnement 7 h → 1 h · −40 % d’anomalies sur 90 jours
Suivi SWIFT GPI de bout en bout · 11 pays · 200 corridors

Implémentation open source

Code et historique publics, distincts de l’expérience client et des mesures Vauban.

Ondine · le traitement par lots pour les systèmes agentiques

Mesures contrôlées Vauban

Expériences reproductibles en laboratoire sur une passerelle Vauban active. Elles ne constituent pas des preuves issues d’une production client.

EXP-02 · comparaison des contrôles d'exécution
EXP-04 · mesures de bascule, de budget et de contrôle des clés

quand une couche de plateforme supplémentaire est prématurée

une API managée et ses contrôles natifs répondent déjà à l'ensemble du besoin
les volumes sont faibles, ou encore imprévisibles
aucune équipe plateforme ou d'exploitation ne peut la maintenir dans la durée
la charge de travail est encore au stade expérimental
l'auto-hébergement est présenté comme plus sûr sans modèle de menace précis

Les études professionnelles sont anonymisées par secteur. Les preuves contrôlées Vauban sont liées ci-dessus avec leur périmètre et leurs limites.

Plateformes LLM et agents : préparation à l’évaluation · Pour les équipes réglementées ou à haut risque qui préparent leurs contrôles et leurs preuves à une évaluation indépendante.