Une architecture compréhensible
Les composants, données, flux, responsabilités et frontières de sécurité peuvent être expliqués sans dépendre d’un fournisseur.
← Toutes les expertises
Expertise 03
Concevoir une solution IA qui s’intègre au SI et reste maîtrisable.
Une architecture guidée par les flux métier, les données, les droits et les contrôles nécessaires — avant le choix du modèle ou de l’outil.
Pour qui
- DSI et architecture
- Responsables produit
- Directions métier
- Sécurité et conformité
Le sujet, concrètement
L’architecture commence par un contrat de fonctionnement.
Avant de parler de modèle, il faut savoir ce que le système reçoit, ce qu’il doit produire, d’où viennent les informations, qui peut les consulter et ce qui se passe lorsque la réponse est incertaine. Une solution IA utile n’est jamais isolée : elle dépend d’identités, de documents, d’API, de règles métier, de journaux et d’interfaces utilisées par de vraies équipes.
La conception rend ces dépendances explicites. Elle sépare ce qui relève de la recherche, de la génération, des règles déterministes et de la validation humaine. Elle organise aussi les mécanismes d’évaluation, de repli et de supervision nécessaires pour que la solution puisse évoluer sans devenir opaque.
Ce que vous obtenez
Des résultats qui permettent d’avancer et de décider.
Des contrôles intégrés
Droits, sources, validation humaine, journalisation et gestion de l’incertitude sont prévus dès la conception.
Des choix réversibles
Les dépendances les plus coûteuses sont identifiées et les interfaces permettent de faire évoluer les briques dans le temps.
Quand intervenir
Quand l’architecture devient le sujet principal
Cette expertise intervient dès qu’un prototype doit accéder au SI, manipuler des données sensibles ou devenir un service maintenable.
- 01
Le cas d’usage dépend de plusieurs applications ou sources documentaires.
- 02
Les droits d’accès varient selon le rôle, le client ou le dossier.
- 03
Le système doit citer ses sources ou justifier les règles appliquées.
- 04
Plusieurs modèles ou fournisseurs sont envisagés.
- 05
Une validation humaine doit être conservée pour certains cas.
- 06
Les équipes doivent diagnostiquer les erreurs et suivre la qualité dans le temps.
La méthode
Concevoir du parcours métier jusqu’aux composants techniques.
L’architecture est travaillée dans les deux sens : à partir de l’expérience attendue et à partir des contraintes réelles du système d’information.
- 01ProductionContrat fonctionnel et scénarios d’erreur
Définir le contrat d’usage
Préciser les utilisateurs, entrées, sorties, niveaux de confiance, décisions autorisées et chemins de repli.
- 02ProductionCartographie des flux et responsabilités
Cartographier données et intégrations
Identifier les systèmes sources, propriétaires, fréquences, droits, formats et écritures éventuelles dans le SI.
- 03ProductionArchitecture logique et contrats d’interface
Découper les capacités
Séparer orchestration, règles, recherche, modèles, stockage, évaluation, observabilité et interfaces utilisateur.
- 04ProductionDossier de décision d’architecture
Arbitrer la cible
Comparer les options selon la sécurité, la performance, la maintenabilité, la réversibilité et le coût complet.
Livrables
Les éléments nécessaires pour construire sans ambiguïté.
Les schémas sont accompagnés de décisions et de responsabilités ; une architecture purement illustrative ne suffit pas à guider l’implémentation.
Architecture fonctionnelle
Parcours, capacités, règles, validations et comportements attendus selon les scénarios.
Architecture logique
Composants, interfaces, flux de données, identités, stockage et dépendances externes.
Modèle de sécurité
Droits, isolation, secrets, données sensibles, journaux et responsabilités d’exploitation.
Registre de décisions
Choix structurants, alternatives écartées, hypothèses, conséquences et points à réévaluer.
Principes de travail
Les qualités d’une architecture IA durable
Traçable
Une sortie importante peut être reliée à ses sources, règles, versions et validations.
Observable
L’équipe peut suivre les erreurs, la latence, les coûts, les usages et la qualité métier.
Évolutive
Le modèle, la base documentaire ou l’interface peuvent changer sans reconstruire tout le système.
Questions fréquentes
Les points à clarifier avant de commencer.
Faut-il choisir le modèle avant de concevoir l’architecture ?
Non. Il faut d’abord définir les capacités et contraintes. Des essais de modèles peuvent éclairer certains choix, mais l’architecture doit éviter de confondre le service rendu avec une technologie particulière.
Comment limiter la dépendance à un fournisseur ?
En isolant les appels aux modèles, en conservant les données et évaluations dans des formats maîtrisés, et en documentant les fonctionnalités réellement spécifiques au fournisseur.
L’architecture couvre-t-elle aussi l’expérience utilisateur ?
Oui. La présentation des sources, des incertitudes, des actions possibles et des validations fait partie du fonctionnement du système, pas d’une finition ajoutée après coup.
Peut-on partir d’un prototype existant ?
Oui. Le prototype permet d’identifier les choix implicites et les dépendances. L’objectif est ensuite de décider ce qui peut être conservé et ce qui doit être reconçu avant la production.
Parlons de votre contexte
Poser les bonnes frontières avant d’ajouter de la complexité.
Vous avez un cas d’usage, un prototype ou une architecture à challenger ? Examinons les flux, les contrôles et les décisions qui conditionnent sa mise en œuvre.