Vous voulez que vos équipes trouvent des réponses dans les documents de l’entreprise. Ou qu’un agent de support consulte une commande, prépare une réponse et mette à jour le bon dossier. Peut-être passez-vous trop de temps à réunir des PDF, des e-mails et des informations publiques pour préparer une analyse.
Chacun de ces besoins peut devenir un projet à cadrer. Chacun demande aussi un travail technique différent : connecter les sources, gérer les accès, choisir le rôle des modèles, intégrer les actions et assurer le fonctionnement du service.
C’est pour relier ces décisions que l’on fait appel à une expertise en architecture IA. Quelqu’un doit traduire le besoin métier en un système cohérent et coordonner les personnes qui le construisent. Cette responsabilité peut revenir à un architecte interne ou à un partenaire de réalisation. Pour comprendre ce qu’elle recouvre, partons des systèmes que vous souhaitez créer.
Vous voulez un assistant qui répond à partir des connaissances de l’entreprise
Un chef de projet demande : « Qu’avons-nous convenu avec ce client, et quel document le confirme ? » Pour répondre, l’assistant doit retrouver le bon accord, dans sa version actuelle, et vérifier que cette personne est autorisée à le consulter.
Une approche courante est le RAG, ou génération augmentée par la recherche : l’application retrouve des informations pertinentes et les transmet au modèle de langage pour qu’il prépare sa réponse. Sa construction porte à la fois sur la recherche et sur la préparation des documents. Le guide de conception RAG de Microsoft détaille ces deux volets.
Le périmètre du projet doit couvrir :
- Les connexions aux sources : identifier les espaces documentaires et outils métier à consulter, puis déterminer quelle source fait référence en cas de désaccord.
- Le traitement et la recherche : extraire le contenu utile, le rendre consultable et prendre en compte les modifications comme les suppressions.
- Les droits d’accès : limiter la recherche aux informations que la personne peut effectivement consulter.
- La présentation des réponses : afficher les sources et rendre visibles les informations absentes ou contradictoires.
- L’évaluation : tester des questions représentatives, des documents modifiés et des restrictions d’accès avant d’élargir l’usage.
Cela mobilise l’ingénierie des données, la recherche d’information, le développement applicatif et la sécurité. Un critère de recette concret : après la modification d’un accord, l’assistant doit retrouver et citer la nouvelle version, tout en respectant les droits de la source. Notre guide pour évaluer une mémoire opérationnelle d’entreprise approfondit ces vérifications.
Vous voulez un agent qui intervient dans vos outils métier
Prenons une demande de support concernant une commande en retard. Vous souhaitez que le système identifie le client, consulte la commande, vérifie les conditions de livraison et prépare la suite dans votre CRM ou votre outil de support.
Le projet introduit alors des actions et leurs conséquences. Il faut définir précisément ce que le système peut lire, proposer et modifier.
- Le processus : préciser l’événement de départ, le résultat attendu et les exceptions qui reviennent à une personne.
- Les intégrations : connecter le CRM, l’ERP ou le support au moyen de leurs API, avec des accès maîtrisés.
- Les autorisations d’action : décider quelles modifications peuvent être automatiques et lesquelles demandent une validation, puis faire appliquer ces limites par le logiciel.
- L’état d’exécution et les reprises : conserver le travail effectué et en attente, gérer les résultats incertains et éviter qu’une relance applique deux fois la même modification.
- L’exploitation : fixer des limites de durée, d’étapes et de dépenses, avec un moyen d’arrêter le traitement et d’examiner un échec.
Un choix d’architecture porte sur la liberté donnée au modèle. Un workflow peut suivre un enchaînement prévu à l’avance ; un agent peut choisir la prochaine étape dans les limites de ses autorisations. La distinction entre workflows et agents proposée par Anthropic aide à poser ce choix.
Pour la commande en retard, un premier périmètre peut s’arrêter à une réponse documentée, prête à être validée. L’envoyer ou modifier la commande ajoute des exigences. Notre cadre d’architecture des agents explique comment relier outils, autorisations et traces d’exécution.
Vous voulez transformer des documents en dossiers exploitables
Étudier des propositions de fournisseurs, préparer une réponse à un appel d’offres ou rassembler des informations sur un prospect : ces tâches partent de matériaux hétérogènes pour aboutir à un dossier qu’une personne pourra examiner.
Commencez par définir le livrable. Pour un dossier fournisseur, il peut s’agir d’une fiche d’entreprise, de caractéristiques techniques extraites, d’une comparaison avec vos exigences et d’une liste de points à éclaircir.
Le système a ensuite besoin de plusieurs fonctions :
- La collecte et l’extraction : accepter les formats utiles, lire le texte et les tableaux, recourir à la reconnaissance optique de caractères lorsque nécessaire.
- Une structure commune : associer chaque information à la bonne rubrique en conservant sa référence documentaire.
- Le rapprochement des informations : signaler les valeurs manquantes, les contradictions et les interprétations incertaines.
- Des étapes définies : attribuer chaque tâche à du code, à un modèle de langage ou à un outil spécialisé d’extraction.
- Une interface de relecture : permettre à une personne de consulter les preuves, de corriger les résultats et de décider de la suite.
Plusieurs modèles peuvent avoir des rôles complémentaires. Ce choix doit découler de tests sur vos documents. L’ajout d’un modèle se justifie lorsqu’il résout un problème observé dans le traitement ; il ajoute aussi un composant à évaluer et à exploiter.
Le test pratique consiste à vérifier qu’une personne peut utiliser le dossier et retrouver l’origine de ses informations importantes sans recommencer toute la collecte.
Vous voulez une plateforme IA commune à plusieurs équipes
L’équipe commerciale souhaite un assistant documentaire, les opérations un traitement de dossiers, le support un agent connecté à ses outils. Certaines briques peuvent être partagées : accès aux modèles, gestion des identités, connecteurs, outils d’évaluation et suivi des usages.
Un projet de plateforme ajoute des responsabilités qui dépassent chaque application :
- Les services communs : décider ce qui peut être réutilisé et ce qui doit rester propre à un processus.
- La séparation des données : préserver les périmètres d’accès entre équipes, clients et projets.
- La capacité et les coûts : gérer la charge, les quotas et l’attribution des dépenses d’exploitation.
- Les mises en production : tester l’effet d’un changement de composant partagé sur les applications qui l’utilisent.
- Les responsabilités : désigner qui exploite la plateforme, qui prend en charge chaque application et comment les incidents sont traités.
Le projet réunit alors ingénierie de plateforme, infrastructure, sécurité et architecture des applications IA. Les principes d’architecture IA de Microsoft montrent comment applications, données et modèles se répartissent en couches distinctes.
Construisez cette base partagée à partir de besoins récurrents et concrets. Si un seul processus est suffisamment compris, définissez-le et testez-le avant de lancer le développement d’une plateforme interne plus large.
Si le cloud privé est une exigence, précisez le périmètre
Chacun de ces systèmes peut devoir conserver certaines données ou certains traitements dans un environnement maîtrisé. Cette exigence doit être explicitée avant de choisir l’infrastructure.
Un cloud privé est une infrastructure réservée à une seule organisation, qui peut être exploitée dans ses locaux ou ailleurs. C’est la définition du NIST. Le projet doit ensuite préciser où s’exécute chaque composant et par où transitent les informations.
Cette cartographie doit inclure le stockage documentaire, l’extraction de texte, la création des représentations utilisées pour la recherche (embeddings), les index, les appels aux modèles et aux outils, les journaux et les sauvegardes. Héberger l’application en interne ne suffit pas à établir qu’aucune donnée n’est transmise à un fournisseur de modèle externe.
Si les modèles doivent eux aussi fonctionner dans votre environnement, leur exploitation entre dans le périmètre : capacité de calcul, mémoire, requêtes simultanées, mises à jour et reprise après incident. L’équipe et le budget d’exploitation doivent couvrir ce travail. Demandez une architecture de déploiement fondée sur vos restrictions réelles et sur la charge attendue.
Ce que l’architecte et l’équipe de réalisation doivent vous remettre
L’architecte relie ces décisions et identifie les compétences nécessaires. Selon le périmètre, la réalisation peut mobiliser des développeurs backend, des ingénieurs données, des designers produit, des ingénieurs infrastructure et des spécialistes de la sécurité.
Au moment de commander le projet, traduisez ces compétences en éléments concrets :
| Travail à mener | Éléments à prévoir dans le périmètre convenu |
|---|---|
| Cadrage métier et produit | Une tâche utilisateur définie, un résultat attendu, des étapes de validation et des critères de recette |
| Architecture et intégration | Un dossier d’architecture décrivant les sources, les composants, les flux de données et les actions autorisées |
| Évaluation des modèles et de la recherche | Des exemples représentatifs, des options comparées, des résultats de tests et des limites connues |
| Développement applicatif | Le processus connecté et l’interface que les équipes utiliseront |
| Déploiement et exploitation | Des procédures de mise en production et de reprise, une supervision et des responsabilités attribuées |
| Coûts et transfert | Des hypothèses de charge, une estimation des coûts récurrents, la documentation et les accès pour l’équipe qui reprend le système |
Maintenir une application à base de modèles de langage alors que ses sources, ses instructions et ses modèles évoluent relève du LLMOps. Cela comprend l’évaluation, le déploiement, la supervision et la prise en compte des retours tout au long de sa vie. La présentation du LLMOps par Microsoft décrit ce cycle.
Convenez d’un premier périmètre utile et de ses critères de recette avant de l’élargir. Notre guide pour choisir un premier projet IA montre comment fixer ce périmètre, son prix et un test de réussite. Un assistant interne et un agent autorisé à modifier des dossiers clients peuvent partager des composants tout en demandant des niveaux différents de validation et de support.
Comment IZZY intervient
Chez IZZY, nous sommes spécialisés dans le développement d’applications et d’agents IA connectés aux processus métier. Notre offre Agents IA & Produits LLM couvre les applications, la recherche d’information, les intégrations, l’évaluation et le suivi en exploitation.
Nous utilisons les modèles pour interpréter, extraire ou synthétiser. Les règles métier explicites restent dans le code ou dans la logique du workflow. Les données et les statuts sont conservés entre les étapes, et les exceptions suivent un circuit de traitement défini. Cette approche est décrite dans nos projets opérationnels publiés.
Un exemple concret : préparer des dossiers de startups
Dans un projet d’analyse préliminaire de startups réalisé par IZZY, la création d’une fiche CRM déclenche une collecte de sources publiques. Lorsqu’un pitch deck est reçu, son contenu est extrait et organisé selon une structure prédéfinie. Des modèles accomplissent des tâches complémentaires. Le système répond aux questions prévues par oui, non ou possible lorsque les éléments le permettent, et signale les informations manquantes. La classification obtenue oriente l’examen humain. La décision d’investissement reste humaine.
Ce cas publié réunit intégration CRM, traitement documentaire, orchestration de modèles et conservation des sources. Il illustre le travail technique derrière une demande précise : préparer un dossier qu’une personne peut évaluer.
Parlons du système que vous souhaitez construire
Décrivez-nous une tâche récurrente, montrez-nous un exemple des informations à traiter et précisez le résultat attendu par votre équipe. Indiquez les outils concernés et les contraintes d’accès, d’action ou d’hébergement. Nous aurons ainsi une base concrète pour discuter de l’architecture, du périmètre de réalisation et des compétences nécessaires à votre projet.