Offre · intégration profonde
Intégration IA dans vos applications .NET : RAG, agents et Semantic Kernel dans votre SI
Pour les ETI et les éditeurs dont le SI vit en .NET et SQL Server : l'IA développée dans votre applicatif (extraction documentaire, agents, classification) avec vos règles métier, votre architecture, votre code. Pas un outil de plus à côté du SI : une capacité nouvelle dedans. Je travaille dans votre repo, avec vos développeurs, aux standards de votre équipe.
Votre application .NET, votre dépôt
- Vos écrans ceux que vos utilisateurs connaissent
- Vos règles métier Capacité IA extraction · RAG · agents
- SQL Server données, habilitations, index vectoriel
C'est fait pour vous si…
- Votre SI ou votre produit repose sur un patrimoine .NET / SQL Server que l'IA doit enrichir, pas contourner.
- Vous visez une capacité IA native : extraction documentaire, classification, assistants métier, directement dans l'applicatif que vos utilisateurs connaissent.
- Votre contexte est exigeant : industrie, banque, santé, environnements régulés, où traçabilité et conformité RGPD / AI Act ne sont pas négociables.
- Vous avez une équipe technique qui veut un interlocuteur capable de parler architecture, pas seulement prompt.
Ce que je livre
-
Extraction documentaire en production
Scans et documents entrants transformés en données structurées : moteur d'extraction interchangeable (Azure Document Intelligence, Mistral OCR, Docling), règles métier, import transactionnel.
-
RAG sur vos données SQL Server
Vos documents et vos données interrogeables depuis l'applicatif, avec des réponses sourcées : index vectoriel dans SQL Server (type VECTOR) ou Azure AI Search à côté de la base, découpage qui suit la structure métier, habilitations du SI respectées.
-
Agents intégrés au SI
Semantic Kernel et Microsoft Agent Framework, sur Azure OpenAI ou un autre fournisseur : des agents qui interrogent vos données et agissent dans votre applicatif, avec les droits et la traçabilité de votre SI.
-
Architecture propre
Clean Architecture, DDD, tests : du code que votre équipe peut relire, maintenir et étendre. Livré dans votre repo, sous votre CI/CD.
-
Réversibilité totale
Aucune dépendance à GiLabs : documentation, transfert de compétences, et des abstractions qui permettent de changer de fournisseur IA sans réécrire.
Le déroulé
La méthode d'un projet logiciel sérieux, appliquée à l'IA, parce que c'en est un.
-
Revue d'architecture
Votre SI, vos flux, vos contraintes de sécurité et de conformité. On décide ensemble où l'IA s'insère et où elle n'a rien à faire.
Livrable : dossier d'architecture validé par votre équipe technique.
-
Développement itératif
Sprints courts sur vos données réelles, revues de code avec votre équipe, montée en qualité mesurée à chaque itération.
Livrable : incréments testés et déployables, dans votre repo.
-
Production et transfert
Mise en production dans votre infrastructure, monitoring, documentation, formation de l'équipe qui reprend la main.
Livrable : la capacité IA en production, maîtrisée par vos développeurs.
Investissement
C'est l'étage le plus engageant, et celui qui crée un actif durable : une capacité IA que votre équipe possède, dans un code qu'elle maîtrise, sans rente à verser à un éditeur de plus.
Investissement
Au forfait
Cadré en revue d'architecture, selon la profondeur d'intégration. Périmètre, prix et critères d'acceptation fixés avant la première ligne de code.
Questions fréquentes
Nos développeurs sont bons. Pourquoi ne pas le faire en interne ?
Souvent vous le pouvez, et c'est la bonne réponse une fois le premier projet passé. Ce qui manque rarement, c'est la compétence .NET ; ce qui manque, c'est d'avoir déjà mis une chaîne IA en production et de savoir où elle casse : seuils, reprises sur erreur, dérive des modèles, coût au document. Le signe le plus fréquent est une entreprise qui recrute en même temps un développeur .NET et un data scientist, alors qu'elle cherche un seul profil. Je travaille dans votre dépôt, avec votre équipe, et le transfert de compétences fait partie du forfait.
Comment travaillez-vous avec notre équipe technique ?
Dans votre dépôt, sous votre CI/CD, à vos standards, avec revues de code croisées. Clean Architecture, DDD et tests ne sont pas des arguments commerciaux ici : c'est ce qui rend le code relisable par vos développeurs. Le projet commence par une revue d'architecture qui décide avec eux où l'IA s'insère, et surtout où elle n'a rien à faire.
Nos données sortent-elles de l'entreprise, et de l'Europe ?
C'est une décision d'architecture, tranchée avant la première ligne de code, pas une conséquence subie du choix d'un modèle. Selon vos contraintes, le traitement reste sur votre infrastructure, sur des services hébergés en Europe, ou sur des services américains sous encadrement contractuel. Pour les environnements régulés et les professions au secret professionnel, la règle par défaut est stricte : traitement en Europe ou sur site. La traçabilité exigée par le RGPD et par l'AI Act se prépare dans la conception, pas après.
Serons-nous enfermés sur un fournisseur de modèle ?
Non, et c'est un choix d'architecture explicite. Les briques d'extraction et d'inférence sont derrière des abstractions : changer d'Azure Document Intelligence à Mistral OCR ou à Docling, ou d'un fournisseur de modèle à un autre, se fait sans réécrire vos règles métier. C'est ce qui rend la capacité durable dans un domaine où l'état de l'art bouge tous les six mois.
Semantic Kernel ou Microsoft Agent Framework ?
Microsoft présente Agent Framework comme le successeur de Semantic Kernel pour les agents. Le code Semantic Kernel en production continue de fonctionner : la vraie question est de savoir quand migrer, pas s'il faut tout réécrire. Ma règle par défaut : les nouveaux agents partent sur Agent Framework, le code Semantic Kernel existant migre quand un chantier le touche, jamais en une seule fois. La revue d'architecture tranche selon votre patrimoine.
Faut-il changer de base de données pour faire du RAG ?
Non. La source de vérité de vos données et de vos habilitations vit déjà dans votre SQL Server : l'index vectoriel s'y ajoute (SQL Server 2025 et Azure SQL ont un type VECTOR), ou vit à côté dans Azure AI Search quand le volume ou la recherche hybride le justifient. Dans les deux cas, pas de copie divergente de vos données dans une base de plus.