Architecte IA
Architecte et ingénieur IA : de l'architecture au système en prod
Je conçois et je livre des systèmes IA en production : données, modèles, agents, MCP, sécurité et coûts. Pour les DSI et CTO qui veulent une architecture qui tient, pas un POC de plus.
Le rôle d'un architecte IA, concrètement
Un architecte IA fait tenir ensemble des briques qui, isolées, ne produisent rien : vos données, le bon modèle pour chaque tâche, des agents qui exécutent, un protocole pour les brancher sur vos outils (MCP), la sécurité et le coût. Le vrai travail n'est pas de choisir le modèle du moment, c'est de faire fonctionner l'ensemble en production, sur vos contraintes à vous.
Et je ne m'arrête pas au schéma. Je conçois l'architecture et j'écris le code qui la fait tourner. C'est le sens du métier chez moi : un seul interlocuteur qui pense le système et le livre, sans plan repassé à une équipe qui le réinterprète en chemin.
- Données : où elles vivent, si elles sont exploitables, ce qu'il faut nettoyer avant de coder.
- Modèles : le bon modèle par tâche (Claude, GPT, open-source), arbitré sur vos données, pas sur le battage.
- Agents et MCP : des agents qui agissent dans vos outils, branchés une fois, réutilisables avec n'importe quel modèle.
- Sécurité : evals, garde-fous et contrôle d'accès pensés dès la conception, pas ajoutés à la fin.
- Coûts : une facture LLM tenue par l'architecture, pas découverte en fin de mois.
Architecture souveraine et on-prem quand les données ne doivent pas sortir
Pour beaucoup d'organisations, les données ne peuvent pas partir chez un tiers. Dans ce cas, je conçois pour que rien ne sorte : le modèle et le serveur MCP qui agit sur vos outils tournent dans votre périmètre, sur un cloud UE ou directement dans votre infrastructure. L'agent lit, décide et exécute sur place ; ni vos documents ni vos requêtes ne transitent ailleurs.
La souveraineté ne se joue pas sur le logo de la facture. Beaucoup de modèles, y compris européens, tournent sur des clouds américains et retombent sous le Cloud Act US. Je vérifie où tournent vraiment le modèle et le connecteur avant de vous conseiller, et je bascule sur de l'on-prem ou du cloud UE quand vos données l'exigent.
Evals, garde-fous et observabilité dès la conception
La différence entre une démo qui impressionne et un système qui tient en production, c'est ce qu'on met autour du modèle. Je l'installe dès le départ, pas une fois que ça a déjà dérivé : des évaluations qui mesurent la qualité réelle avant chaque mise en prod, des garde-fous qui gardent l'agent dans son couloir, et de l'observabilité pour voir ce qu'il fait, ce qu'il coûte et quand la qualité décroche.
Et je teste le système comme le ferait quelqu'un de mal intentionné avant que ça n'arrive pour de vrai : injection de prompt, fuite de données, agent poussé hors de son périmètre. Un système IA en production se conçoit avec sa façon d'échouer, pas seulement sa façon de marcher.
Livrer une archi, ou livrer un système exploité
Un beau schéma n'est pas un système. Beaucoup de missions s'arrêtent au diagramme et à un POC sur un portable ; le vrai travail commence après. Je livre quelque chose qui tourne : déployé, monitoré, documenté, avec la reprise sur incident prévue et le passage de main organisé.
Le fait d'être solo est un atout ici, pas une limite. Un seul interlocuteur pense le système et l'exploite, l'architecture est documentée, le code vous appartient et rien ne vous enferme chez moi. Vous pouvez reprendre en interne ou confier la suite à quelqu'un d'autre quand vous voulez : c'est le contraire d'une dépendance.
Ma stack, sans name-dropping inutile
Je choisis les outils selon votre cas, pas selon mes habitudes. La liste ci-dessous n'est pas là pour impressionner : ce sont les briques que j'utilise vraiment, et chacune sert un problème précis. Si un outil plus simple fait le travail, je le prends ; si le sur-mesure s'impose, je code.
- Modèles : Claude, GPT, modèles open-source déployés en privé (vLLM, Ollama).
- Agents et outils : MCP (fastmcp), LangGraph, tool use, webhooks.
- Données et RAG : Python, pgvector, Qdrant, embeddings, reranking.
- Automatisation : n8n quand c'est le bon niveau, code sur mesure quand la logique le dépasse.
- Déploiement : Docker, Terraform, cloud UE ou votre cloud (AWS, GCP, Azure, Vercel).
- Fiabilité : evals (Promptfoo), observabilité (Logfire, LangSmith), traces et alertes.
Ce que j'ai déjà construit
Quelques systèmes réels, décrits par le travail et non par le client (je ne nomme personne et je n'invente aucun chiffre) : une infrastructure MCP qui donne aux agents l'accès aux outils internes sans ouvrir de brèche, derrière un proxy Zero Trust et du SSO ; un système de détection d'anomalies à trois moteurs, expliqué et priorisé par des agents orchestrés avec LangGraph.
Côté connaissance et observabilité : une chaîne RAG de bout en bout qui alimente un assistant interne, synchronisée en continu avec le code ; et un filtre d'ingestion de logs qui appelle un LLM à la volée pour repérer les anomalies au moment où elles arrivent, en JSON structuré. Le détail de ces réalisations est sur la page dédiée.
Vous codez, ou vous ne faites que des slides ?
Je code. Je conçois l'architecture et j'écris le système qui la fait tourner : agents, RAG, connecteurs MCP, workflows, déploiement. Le schéma sert à décider, pas à facturer un livrable qui s'arrête là. Si vous cherchez seulement un audit ou un cadrage, c'est possible aussi, mais mon métier reste de livrer du logiciel en production.
Comment se passe une mission, et quel est le TJM ?
Ça dépend du périmètre et du mode (mission au forfait, régie, renfort d'équipe). Je donne un ordre de grandeur dès le premier appel, gratuitement, une fois le besoin cadré. Je préfère être franc sur le budget tôt plutôt que de découvrir un désaccord à la fin.
Vous travaillez à distance ? En dehors de la France ?
Oui. Je travaille à distance pour des clients en France et dans l'UE, avec des points réguliers et sur place quand c'est utile. Je suis indépendant et basé en France, ce qui simplifie la contractualisation et la facturation dans l'UE.
À qui appartient le code et l'architecture ?
À vous. Le code, l'architecture documentée et les accès vous reviennent, sans dépendance à moi ni à un fournisseur unique. Le choix du MCP va dans ce sens : vous pouvez changer de modèle ou reprendre la suite en interne sans tout recâbler.
Pouvez-vous venir en renfort d'une équipe existante ?
Oui, c'est fréquent. Je m'intègre à vos développeurs et à votre DSI, je prends en charge la partie IA (architecture, agents, evals, sécurité) et je transmets au fur et à mesure pour que l'équipe reste autonome après moi. Je peux aussi reprendre un système IA que vous avez déjà commencé et le faire passer de la démo à la production.
Architecte ou ingénieur IA : quelle différence dans votre cas ?
Dans les grandes structures, l'un dessine et l'autre construit. Étant solo, je fais les deux, et c'est justement l'intérêt : la personne qui décide de l'architecture est celle qui l'écrit et la maintient, donc rien ne se perd entre le plan et la prod.
Contact
Prêt à passer de la démo à la production ?
Réponse sous 24 h · premier échange gratuit et sans engagement.