IA & Agents
Agents IA, RAG, MCP et intégration LLM : je conçois et connecte des solutions IA à vos applications, vos données et vos outils métier existants.
Brancher un LLM sur une interface de démonstration prend une après-midi. Le faire tenir dans un système réel demande de traiter les droits d’accès, la qualité des réponses, les cas d’échec, la traçabilité, les coûts et l’exploitation. C’est là que les projets s’arrêtent.
Un POC IA est facile. L’intégrer de façon fiable dans un système d’information réel est un problème d’architecture logicielle. C’est précisément mon métier depuis quinze ans.
Utilisateur
collaborateur, client ou opérateur
Application ou copilote
votre produit, votre interface
Orchestration IA
contexte, routage, politiques d’usage
LLM ou agent
raisonnement et sélection des outils
Outils, MCP, APIs
actions exposées, avec leurs permissions
SI, données, services métier
vos bases, vos APIs, vos documents
Les demandes se ramènent presque toujours à l’un de ces besoins. Aucun ne se règle en ajoutant un chatbot sur une page.
Retrouver une réponse dans des milliers de pages de documentation, de contrats ou de comptes rendus, avec la source citée et les droits de lecture respectés.
Un assistant qui connaît vos procédures, vos produits et vos règles, branché sur vos outils plutôt que sur une base figée.
Lire des factures, des devis, des dossiers ou des e-mails, en extraire des champs structurés et les router vers le bon traitement.
Interroger et mettre à jour vos données existantes via la couche applicative, avec les mêmes contrôles que le reste du produit.
Enchaîner des étapes qui mobilisent aujourd’hui une personne : préparation, vérification, rédaction, transmission.
Produire un premier jet (courrier, réponse, compte rendu, fiche produit), relu et validé par un humain avant d’être utilisé.
Traiter les demandes récurrentes en première ligne, avec une escalade explicite vers un humain quand le modèle n’est pas sûr.
Un modèle rapide pour trier, un modèle plus capable pour raisonner, vos propres services pour agir. Le bon outil à chaque étape, pas le même partout.
Un cas d’usage utile se reconnaît à trois signes : le besoin existait avant l’IA, quelqu’un perd du temps dessus toutes les semaines, et le résultat se vérifie.
La bonne solution n’est presque jamais « mettre ChatGPT partout ». Certains besoins se règlent mieux par une requête SQL, une règle métier ou un formulaire mieux conçu, et je le dis quand c’est le cas. Quand l’IA est pertinente, huit décisions suivent, dans cet ordre.
Qui perd du temps, sur quoi, combien de fois par semaine, et à quoi ressemble une réponse juste.
Ce qui existe réellement, dans quel état, qui a le droit de le lire, et ce qu’il faut reconstruire avant tout le reste.
Où l’IA s’insère dans le système existant, ce qu’elle appelle, et ce qui reste déterministe.
Capacité, latence, coût, hébergement. Choisi après le reste, et conçu pour rester remplaçable.
Cloisonnement, permissions, secrets, données sensibles, journal d’audit. Décidé à la conception, pas ajouté après.
APIs, outils métier, systèmes tiers : ce que le modèle peut appeler, et ce qu’il ne doit jamais appeler.
Comment l’utilisateur comprend ce qui est généré, le vérifie, le corrige et reprend la main.
Traces, qualité des réponses, coût par usage. Sans cela, un service IA devient impossible à exploiter.
POC d’abord, industrialisation ensuite. Un POC sert à trancher une incertitude en quelques jours ; il n’est pas une version 1 en attente de déploiement. Le passage en production se décide à la vue de ses résultats.
Vous avez déjà une application ou un SaaS. J’ajoute des fonctionnalités IA à l’intérieur du produit et je les relie au backend et aux données déjà en place.
Permettre au modèle de s’appuyer sur votre documentation, vos données métier et vos documents internes, plutôt que sur ce qu’il croit savoir.
Des agents capables de raisonner sur une tâche, de choisir un outil, d’appeler vos services et d’enchaîner des actions, en demandant une validation quand l’enjeu le justifie.
Exposer vos APIs, vos outils internes et vos services métier à un assistant ou à un agent, de façon contrôlée. Le protocole importe moins que ce qu’on autorise et ce qu’on trace.
La différence entre une démonstration réussie et un service que vous pouvez exploiter tient à des sujets d’ingénierie classiques.
Des formats courts pour décider sur pièces plutôt que sur une présentation.
Analyse des processus, du système d’information et des données pour identifier les cas d’usage IA réellement pertinents et leur faisabilité.
Livrable : Cas d’usage priorisés, faisabilité et prérequis techniques.
Audit d’une architecture LLM, RAG ou agent déjà en place : qualité des réponses, sécurité, coûts, observabilité et capacité à passer en production.
Livrable : Points de rupture identifiés et chemin vers la production.
Prototype fonctionnel connecté à une application, à des documents, à des APIs ou à des outils métier existants, pour décider sur pièces.
Livrable : Prototype exécutable et note d’architecture cible.
Exposition sécurisée de vos APIs et services métier à un assistant ou à un agent, avec les permissions et les limites qui vont avec.
Livrable : Connecteur fonctionnel, documenté et testé.
Ces interventions peuvent se prolonger en développement, en architecture ou en accompagnement d’équipe si le sujet le justifie.
Chegou est un produit que je conçois et développe moi-même : une PWA qui aide des étrangers en France dans leurs démarches administratives. L’IA y analyse des documents, répond à des questions situées, prépare des courriers et génère un plan d’action, le tout adossé à un backend, à des droits et à un modèle de coûts réels. C’est l’exemple le plus direct de ce que je décris ici.
Voir le projet ChegouRarement. Dans la grande majorité des cas, une bonne récupération d’information et un contexte bien construit suffisent, pour un coût et un délai sans commune mesure. Je ne suis pas data scientist et je n’entraîne pas de modèles : mon apport est l’architecture d’intégration.
Non. Le choix dépend de vos données, de vos contraintes de confidentialité, de la latence attendue et des coûts. Je conçois les intégrations pour que le fournisseur reste remplaçable.
C’est un critère de conception, pas une option ajoutée après. Cloisonnement, permissions, journalisation et choix d’hébergement se décident au moment de l’architecture, en fonction de votre niveau d’exigence.
L’IA est une extension récente de mon travail, pas quinze ans de pratique. Mes quinze ans portent sur le développement, l’architecture et la mise en production de systèmes logiciels, y compris industriels. C’est justement ce qui manque à la plupart des projets IA qui échouent au moment d’entrer en production.
Si le besoin n’est pas encore tranché, l’audit IA et métier cadre les cas d’usage, les données et la faisabilité avant tout développement.
Si votre sujet est la visibilité de votre marque dans les assistants IA, c’est un autre métier : l’audit SEO et GEO.
Un échange de 30 minutes suffit généralement à distinguer ce qui est faisable de ce qui ne l’est pas encore.
Me contacter