Benjamin Godard — Architecte IA

§1Le point de rupture n’est pas le modèle

La démonstration fonctionne. Le passage en production échoue. Dans la quasi‑totalité des cas que j’ai rencontrés, ce n’est pas le modèle qui bloque — c’est l’absence de réponse aux questions que pose un comité d’architecture.

Un prototype LLM se construit en quelques jours : une clé d’API, une bibliothèque d’orchestration, un jeu d’instructions. Il produit une démonstration convaincante et une dette d’architecture invisible. Le trafic passe chez un fournisseur unique, hors du périmètre de conformité. Le coût est proportionnel à l’usage sans plafond ni attribution. Le nom du modèle est inscrit en dur dans la logique métier. Personne ne sait ce qui se passe quand la sortie est fausse, ni qui a autorisé quelle action.

Ces quatre points ne sont pas des détails d’implémentation à traiter plus tard : ce sont des décisions d’architecture, et les reprendre après coup coûte une réécriture. Mon travail consiste à les poser avant, à les documenter, et à laisser une cible que d’autres équipes peuvent construire sans moi.

Position Je n’entraîne pas de modèles et je ne fais pas de recherche. J’interviens sur la couche qui décide quel modèle est appelé, avec quels droits, à quel coût, et sous quel contrôle.

§2Les cinq questions d’un comité d’architecture

Ce sont les questions que reçoit tout projet IA au moment de franchir la porte de la production. Voici les mécanismes par lesquels j’y réponds — des dispositifs vérifiables, pas des engagements.

01

Où partent nos données ?

Plan d’inférence auto‑hébergé par défaut : le trafic courant est traité par des modèles ouverts sur une infrastructure sous votre contrôle. L’appel à un fournisseur externe devient une exception, isolée, déclarée et journalisée — pas le mode nominal. Le périmètre de ce qui sort du réseau est une décision explicite, pas un effet de bord de la bibliothèque choisie.

02

Combien cela coûte, et qui paie quoi ?

Routage par tier. Un classifieur déterministe et peu coûteux évalue chaque requête et l’oriente vers un petit modèle auto‑hébergé ou vers un modèle frontier ; seule une minorité de requêtes justifie le second. En regard : clés virtuelles par entité, budgets plafonnés, et attribution du coût par tier et par usage. Le coût unitaire cesse d’être une surprise de fin de mois pour devenir une ligne pilotable.

03

Que se passe‑t‑il quand le modèle se trompe ?

Le modèle se trompera — la question est ce que le système en fait. Sortie structurée et contrainte plutôt que texte libre reparsé ; garde‑fous sur les actions sortantes appliqués côté passerelle, hors de portée du modèle ; validation humaine obligatoire sur les actions irréversibles ; et jeu d’évaluation rejoué avant tout changement de modèle ou d’instruction, pour que « on a mis à jour le modèle » ne soit plus une mise en production à l’aveugle.

04

Peut‑on changer de fournisseur ?

La logique métier ne connaît jamais le nom d’un modèle. Elle s’adresse à un contrat d’interface stable exprimé en tiers logiques ; le choix du fournisseur et de l’hébergeur devient un paramètre de déploiement. Le socle technique retenu est isolé derrière ce contrat, ce qui permet d’en changer sans toucher aux applications — condition d’un plan de réversibilité présentable en comité.

05

Qui a le droit de faire quoi ?

Aucun credential n’est jamais exposé au modèle, ni à l’orchestrateur. Les secrets vivent dans un coffre côté passerelle, résolus au moment de l’exécution de l’outil, sous une clé scopée par entité qui constitue la frontière de sécurité du système. Chaque appel d’outil laisse une trace horodatée et attribuable : ce que l’agent a fait, pour le compte de qui, avec quel droit.

§3Architecture de référence

Le schéma ci‑dessous est le squelette que j’adapte à chaque contexte. Sa caractéristique principale est la séparation en deux plans — le plan qui choisit et appelle un modèle, et le plan qui expose et exécute des outils. Les confondre est l’erreur d’architecture la plus fréquente, parce qu’elle place les credentials et les actions sortantes du mauvais côté de la frontière de sécurité.

Fig. 1 — Le routeur produit un double choix à partir de la requête : le tier de modèle, qui alimente le plan A, et la famille d’outils, qui restreint en amont l’ensemble d’outils exposé au modèle dans le plan B. Les deux plans partagent une frontière de sécurité unique : la clé scopée par entité. Le schéma emprunte la forme de l’objet qu’il décrit : une voie, une lame d’aiguille, deux directions.

Deux conséquences pratiques. D’abord, le routeur est le seul composant réellement spécifique : la plomberie des deux plans est une commodité disponible sur étagère, et la recoder est un gaspillage. Ensuite, restreindre la famille d’outils en amont réduit simultanément la fenêtre de contexte consommée, le taux d’erreur de sélection d’outil, et la surface d’action exposée au modèle — trois problèmes distincts traités par une seule décision.

Ce que ça implique La question « quel fournisseur de LLM choisir » arrive tard, et beaucoup moins haut qu’on ne le croit dans l’ordre des décisions. Un projet qui commence par là a déjà arbitré, sans s’en apercevoir, la conformité, le coût et la réversibilité.

§4Réalisations

Contextes anonymisés, architectures décrites. Les noms de clients ne figurent pas sur ce document : la même règle s’appliquera à votre mission.

R1

Passerelle LLM multi‑tenant avec routage par tier

Éditeur SaaS — CRM agentique multi‑tenant

Contrainte: Résidence des données imposée par la base clients européenne, coût d’inférence non maîtrisé, et impossibilité d’exposer un credential de tenant à un modèle.
Conception: Architecture à deux plans (cf. §3). Routeur maison produisant le double choix tier / famille d’outils, en cascade : scoring lexical déterministe d’abord, scorer sémantique derrière la même interface pour les cas que le lexical rate, avec seuil de confiance et escalade. Socle de proxy open source auto‑hébergé, isolé derrière un contrat d’interface. Ségrégation par clé scopée comme unique frontière de sécurité des deux plans.
Effet: Le trafic d’inférence courant reste dans le périmètre auto‑hébergé. Le coût devient attribuable par tenant et par tier. Le choix du fournisseur frontier redevient réversible.

routage par tier clés virtuelles RGPD / résidence RAG d’outils multi‑tenant

R2

Orchestration d’agents avec point de contrôle humain

Plateforme interne — production de livrables assistée par agents

Contrainte: Des agents produisant du code et des communications sortantes, sans qu’aucune action irréversible ne puisse partir sans arbitrage humain.
Conception: Machine à états explicite plutôt qu’une boucle d’agent libre : chaque transition est nommée, persistée et rejouable. Un conteneur jetable par unité de travail, sans accès latéral. Les actions irréversibles s’arrêtent sur une file d’attente et repartent sur validation humaine via un canal de messagerie. Scoring LLM en amont pour n’engager du calcul que sur ce qui a une probabilité de succès suffisante.
Effet: Un incident reste borné à un conteneur. Le comportement du système est auditable a posteriori état par état, et non reconstitué à partir de journaux de conversation.

machine à états human‑in‑the‑loop isolation par conteneur rejouabilité

R3

Serveur d’outils MCP multi‑tenant et coffre de credentials

Éditeur CRM — exposition d’un système métier à des clients agentiques

Contrainte: Un même serveur d’outils desservant des instances cloud et des instances auto‑hébergées chez le client, chacune avec ses propres credentials.
Conception: Résolution des credentials déléguée à un fournisseur d’authentification abstrait, ce qui découple le code des outils de la source des secrets : démarrage en mono‑tenant local, bascule vers un fournisseur multi‑tenant hébergé sans réécrire un seul outil. Détection de secrets en pré‑commit sur l’ensemble du dépôt.
Effet: La trajectoire mono‑tenant → multi‑tenant devient un changement de configuration, pas un chantier.

MCP coffre de secrets mono → multi‑tenant

R4

Ingestion continue et RAG sur corpus hétérogène

Aide à la décision sur données économiques et de marché

Contrainte: Sources publiques hétérogènes et bruitées, flux continu, exigence de traçabilité de chaque affirmation jusqu’à sa publication d’origine.
Conception: Chaîne ingestion → normalisation → classification → indexation, un service par source pour que la défaillance d’une source n’arrête pas la chaîne. Moteur de recherche en socle, restitution en trois modes — synthèse périodique, alerte sur événement, question‑réponse à la demande. Aucune synthèse sans renvoi aux sources qui l’ont produite.
Effet: La sortie du système est contestable et vérifiable, condition d’usage dans un cadre où la responsabilité de la décision reste humaine.

RAG ingestion continue traçabilité des sources OpenSearch

R5

Chaîne de production éditoriale à double modèle

Éditeur CRM — génération de campagnes avec validation étape par étape

Contrainte: Volume élevé de génération à coût contenu, et une charte graphique client à respecter strictement dans le rendu final.
Conception: Modèle local en primaire, modèle frontier en secours uniquement sur les étapes où le premier échoue de façon mesurée — la bascule est une donnée observée, pas une intuition. Point d’arrêt humain entre chaque étape du pipeline (scoring, rédaction, rendu), l’état étant persisté pour permettre la reprise.
Effet: Le coût marginal d’une campagne devient prévisible, et aucune sortie n’atteint un destinataire sans avoir été vue.

cascade de modèles modèle local validation par étape

§5Décider, et laisser la trace de la décision

Un livrable d’architecture n’est pas un schéma : c’est une suite de décisions datées, argumentées et opposables. J’écris chaque arbitrage structurant sous forme d’ADR — contexte, options réellement envisagées, critères pondérés, décision, et ce qui la remettrait en cause. Extrait anonymisé d’un arbitrage build‑vs‑buy sur le plan d’inférence :

ADR‑0001 — Socle du plan d’inférence
Critère	Poids	Socle open source auto‑hébergé	Passerelle managée	Développement intégral
Délai de mise en valeur	fort	✓	✓	✗
Résidence des données / RGPD	fort	✓	!	✓
Modèles auto‑hébergés & sortie contrainte	fort	!	!	✓
Clés virtuelles & budgets par entité	fort	✓	✓	✗
Attribution du coût par tier	moyen	✓	✓	✗
Réversibilité derrière contrat d’interface	moyen	✓	!	✓
Charge de maintenance	moyen	moyenne	faible	forte

Décision Socle open source auto‑hébergé, isolé derrière un contrat d’interface — la plomberie est réutilisée, la politique de routage reste propriétaire. Réserve documentée : le modèle open‑core du socle fait migrer certaines fonctions vers une édition commerciale ; les fonctions concernées sont identifiées une par une, avec leur contournement, et le contrat d’interface garantit la sortie.

C’est le format dans lequel je livre. Un successeur reprenant le dossier six mois plus tard comprend non seulement ce qui a été choisi, mais pourquoi les autres options ont été écartées — et à quelle condition il faudrait rouvrir le sujet.

§6Parcours

Vingt ans d’ingénierie d’infrastructure et de fiabilité, majoritairement dans des environnements contraints par la régulation, la souveraineté ou la disponibilité. C’est de là que vient ma lecture des systèmes IA — la partie difficile n’a jamais été le composant, mais ce qui l’entoure.

2024 →

Éditeur logiciel — MCO et supervision Outillage interne de gestion de parc, plan de migration, automatisation des procédures récurrentes.

2023 – 2024

Mutuelle d’assurance — plateforme de supervision Migration du socle de supervision, mise en place CI/CD, MCO de l’environnement de production.

2022 – 2023

Opérateur de jeu sous licence — migration de virtualisation à grande échelle Migration KVM vers VMware par HCX, orchestration des bascules par Ansible et GitLab‑CI, outillage Python et Go. Secteur régulé, contraintes de disponibilité et de traçabilité fortes.

2021

Missions indépendantes — sécurité applicative et opérations datacenter Architecture web, sécurité applicative, opérations sur un programme scientifique international de grande échelle.

2018 – 2020

Cloud souverain français — QA sécurité Frameworks de tests automatisés, durcissement système, et contribution à l’obtention de la qualification SecNumCloud (ANSSI) de la plateforme.

2008 – 2018

Équipementier télécom, constructeur automobile, opérateurs, éditeurs Migrations cloud, industrialisation Linux, pipelines CI/CD, automatisation d’infrastructure. Environnements de production critiques, échelle industrielle.

Systèmes IA: Architecture d’agents, MCP, RAG, routage et cascade de modèles, modèles auto‑hébergés, évaluation, garde‑fous, FinOps d’inférence.
Langages: Python, Go, JavaScript / Node.js, Shell, SQL.
Infrastructure: AWS, Kubernetes, Docker, Terraform, Ansible, VMware, KVM, OpenStack.
Exploitation: GitLab‑CI, GitHub Actions, Grafana, ELK, Prometheus, gestion des secrets, durcissement Linux.
Langues: Français (langue maternelle), anglais courant — technique et commercial.

§7Modalités d’intervention

Trois formats, du diagnostic court à l’accompagnement long. Chacun produit un livrable écrit, opposable et réutilisable sans moi.

Audit d’architecture

Lecture d’un système IA existant ou d’un projet en cours de cadrage, à travers les cinq questions du §2. Identification des décisions déjà prises implicitement, et de celles qui coûteront une réécriture si elles ne sont pas reprises maintenant.

Note de synthèse avec risques hiérarchisés
Estimation du coût d’inférence à l’échelle cible
Restitution orale devant l’équipe et ses parties prenantes

3 à 5 jours forfait

Cadrage d’architecture cible

Conception de l’architecture, arbitrages build‑vs‑buy documentés, et trajectoire de mise en œuvre découpée en incréments livrables. Le livrable est fait pour être construit par vos équipes, pas pour créer une dépendance à moi.

Dossier d’architecture et schémas de référence
ADR pour chaque décision structurante (format du §5)
Trajectoire incrémentale et critères de sortie par étape
Prototype de la brique la plus risquée, si nécessaire

3 à 6 semaines forfait ou régie

Mission d’architecte

Accompagnement dans la durée : arbitrages au fil de l’eau, revue des choix d’implémentation, montée en compétence des équipes, et transfert progressif de la propriété de l’architecture.

Temps plein ou temps partagé
Participation aux instances d’architecture
Revue de conception et de code sur les briques sensibles

3 mois et + régie

Architecture de systèmes IA en production