Conseil et réalisation pour les équipes techniques
Ingénierie des agents IA
Intégrer les agents de code au travail de votre équipe, ou construire un agent qui agit sur vos données et vos outils. Du diagnostic à la mise en service, avec un périmètre défini, des résultats vérifiables et un transfert à votre équipe.
Leebr Data Consulting est un cabinet de conseil indépendant basé à Levallois-Perret. Il met des assistants IA en production, reliés aux outils et aux données de l'entreprise, avec Claude, Mistral ou un modèle ouvert installé sur votre infrastructure, pour des entreprises d'Île-de-France et à distance.
Vos agents produisent du code, mais le contexte est reconstruit à chaque session, les revues s’allongent ou les changements restent difficiles à vérifier.
Ce que la mission peut livrer
Un diagnostic sur un dépôt et un workflow représentatifs.
Un contexte de travail versionné : architecture, conventions, instructions et outils. C’est l’ingénierie du contexte, ou context engineering.
Un workflow piloté par des spécifications, avec revue de code assistée, décision humaine et tests exécutables.
Des outils ou skills pour les tâches récurrentes, et leur intégration au développement et à la CI/CD.
Un cas réel traité avec l’équipe : fonctionnalité, refactorisation ou migration, puis documentation et transfert.
Construire et fiabiliser un agent IA
Un prototype doit passer en production, un assistant doit accéder à vos systèmes, ou il faut rendre ses réponses, ses actions et ses coûts vérifiables.
Ce que la mission peut livrer
Des outils métier exposés par MCP ou des appels de fonctions avec entrées validées.
Un contexte, un harnais, une boucle d’exécution et une orchestration d’agents adaptés au cas d’usage.
Un banc d’évaluation sur des cas réels, rejoué à chaque changement de prompt, d’outil ou de modèle.
Des contrôles de sécurité, des traces d’exécution, un suivi du coût par usage et des alertes.
Le déploiement, la documentation et le transfert, avec Claude ou un autre fournisseur, ou sur un modèle ouvert installé chez vous.
Le cadrage sélectionne les livrables utiles à votre situation et définit leurs critères de validation.
Comment commence la mission
1. Partir de votre situation
L’équipe concernée, un dépôt ou un système, les difficultés rencontrées et le résultat attendu. Votre activité tourne déjà : on cherche l’endroit précis où un modèle apporterait quelque chose dans vos outils et vos processus, pas un cas d’usage copié ailleurs. Le premier échange permet de vérifier si l’accompagnement correspond au besoin.
2. Définir un périmètre vérifiable
Le cadrage fixe un cas représentatif, les livrables, les accès nécessaires et les critères de réussite. La durée et le chiffrage sont établis sur ce périmètre.
3. Construire, vérifier, transmettre
Des changements livrés par étapes, vérifiés sur le cas convenu, puis documentés pour que votre équipe puisse les utiliser et les faire évoluer.
Des travaux que vous pouvez examiner
Projets, code public et retours de terrain montrent les choix techniques et leurs limites.
L’assistant de ce site, à essayer maintenant
Le chat de la page contact tourne sur Claude via AWS Bedrock en région européenne, avec des règles de qualité sur les données saisies et un banc de treize scénarios rejoué à chaque changement. C’est le même dispositif que le cabinet installe chez ses clients.
Des plugins publics pour le droit, la comptabilité, la stratégie et la défense contre l’injection de prompt. Des exemples de contexte et d’outils spécialisés pour les agents de code.
Un retour de terrain sur le serveur MCP d’Energy Data Platform : passage au SDK officiel et au fonctionnement sans état, avec les changements et les difficultés rencontrées.
Pour le détail des compétences (contexte, orchestration, évaluation, sécurité et exploitation), consultez la page Expertise.
Questions fréquentes
Mes données doivent-elles sortir de l'entreprise ?
Non, si c'est la contrainte. Un modèle ouvert peut tourner sur votre infrastructure ; sinon, Claude via AWS Bedrock en région européenne, où les données sont traitées en Europe et, par défaut, non conservées par le service.
Comment savoir si l'assistant est fiable avant de le déployer ?
Par un banc d'évaluation sur des cas réels, rejoué à chaque changement de prompt, d'outil ou de modèle. C'est lui qui décide de la mise en production, pas une démonstration. Le cabinet fait tourner ce banc chaque nuit sur un SaaS en service.
Combien de temps avant un premier résultat ?
Une à deux semaines de cadrage pour fixer un cas d'usage, ses données, ses risques et un critère de succès mesurable, avec une estimation du coût de fonctionnement.
Êtes-vous liés à un seul fournisseur de modèles ?
Non. Les applications du cabinet changent de fournisseur par configuration : API Anthropic, AWS Bedrock ou Mistral, et modèles ouverts avec llama.cpp.
Quelle machine faut-il pour un modèle ouvert chez nous ?
Pour un banc ou un usage individuel, un poste avec 64 Go de mémoire et une carte graphique modeste fait tourner un modèle ouvert de 35 milliards de paramètres : c'est la configuration du banc du cabinet. Pour un service partagé en production, il faut un serveur avec une ou plusieurs cartes graphiques dimensionnées au cadrage, ou un cloud privé en Europe. Le cabinet mesure le modèle sur votre matériel avant toute promesse.
Quel travail voulez-vous confier aux agents ?
Intégrer les agents à votre développement, reprendre un workflow difficile à contrôler, connecter un assistant à vos outils ou fiabiliser un prototype : décrivez votre situation et le résultat attendu.