Architecture IA à trois niveaux

Pour les fonctionnalités IA en production, j’ai développé une approche à trois niveaux qui équilibre fiabilité et intelligence. Trop d’équipes sautent directement aux LLMs pour tout, alors que des approches plus simples et plus prévisibles serviraient mieux. À l’inverse, les équipes qui évitent complètement l’IA passent à côté d’opportunités énormes. La clé est de savoir quel niveau appliquer où.

Après avoir construit des fonctionnalités alimentées par l’IA à travers plusieurs produits — des plateformes SaaS entreprise à la health tech — ce framework a constamment guidé de bonnes décisions architecturales.

Niveau 1 : Règles déterministes

Quand utiliser : Logique métier qui doit être exacte, auditable et 100% prévisible.

Vérifications de conformité, règles de validation, calculs réglementaires, transformations de données avec des schémas connus, alertes basées sur des seuils. Ceux-ci ne devraient jamais être délégués à des modèles probabilistes. Ils sont rapides, testables, auditables et prévisibles. Quand un régulateur demande “pourquoi avez-vous fait X ?”, la réponse doit être une règle claire, pas “le modèle a pensé que”.

Caractéristiques :

Zéro ambiguïté dans les entrées et sorties
Doit être explicable aux auditeurs et régulateurs
Critique en performance (sous-milliseconde)
Le comportement doit être identique d’une exécution à l’autre
Les changements nécessitent une approbation humaine explicite

Exemples concrets (SaaS entreprise) :

Calcul de prix : Quantité de la commande * prix unitaire = montant total attendu. Pas d’IA nécessaire, pas d’IA souhaitée.
Détection de doublon (correspondance exacte) : Même numéro de document + même client + même montant = signaler comme doublon. Comparaison de hash déterministe.
Règles de validation : Valeur attendue = valeur réelle dans les seuils de confiance configurés. Arithmétique pure.
Vérifications de conformité : Ce client est-il sur la liste de sanctions ? La transaction est-elle dans le seuil approuvé pour cet approbateur ? Recherches binaires.
Validation de format : Ce document a-t-il tous les champs requis ? La date est-elle parseable ? Le code devise est-il valide ?

Implémentation :

Logique métier standard dans votre code applicatif
Moteurs de règles (Drools, DSL personnalisé) pour les jeux de règles complexes que les utilisateurs métier configurent
Contraintes et triggers de base de données pour l’intégrité des données
Piloté par la configuration (pas déployé dans le code) quand les utilisateurs métier doivent ajuster les seuils

Coût : Essentiellement zéro par transaction. Le coût de développement est la logique de la règle elle-même.

Niveau 2 : Modèles ML entraînés

Quand utiliser : Reconnaissance de patterns sur des données structurées où vous disposez d’une vérité terrain historique et où le problème a un résultat mesurable et borné.

Classification, scoring, détection d’anomalies, recommandation, prévision. Ces modèles sont entraînés sur vos données spécifiques, évalués avec des métriques ML standard et déployés avec monitoring. Ils sont plus performants que les règles mais restent bornés et mesurables.

Caractéristiques :

Vous avez des données d’entraînement labellisées (ou pouvez en générer)
La sortie est une classification, un score ou une prédiction — pas du texte libre
Vous pouvez définir et mesurer l’accuracy, la précision, le recall
Le modèle doit s’améliorer au fil du temps en voyant plus de données
Les exigences de latence sont modérées (millisecondes à quelques secondes)

Exemples concrets (SaaS entreprise) :

Scoring de fraude : Cette transaction a une probabilité de 94% d’être frauduleuse basée sur 47 features (anomalie de montant, changement de comportement client, patterns temporels, irrégularités de format). Entraîné sur des cas de fraude historiquement confirmés.
Classification de documents : Est-ce une commande, un avoir, un relevé ou un rappel ? Classifieur entraîné sur la structure et le contenu des documents.
Scoring de risque client : Score composite basé sur l’historique de transactions, la fréquence de changement de coordonnées, les facteurs de risque géographique. Modèle gradient boosted sur des données client structurées.
Détection d’anomalie de montant : Ce montant de commande est à 3,7 écarts-types de la moyenne historique du client. Modèle statistique, pas LLM.
Prévision de la demande : Volume de commandes prévu par catégorie pour les 30 prochains jours. Modèle de séries temporelles pour la planification de capacité.

Implémentation :

XGBoost/LightGBM pour les données tabulaires (toujours le meilleur choix en 2026 pour les features structurées)
PyTorch pour les patterns complexes (classification de documents basée sur l’image, modèles de séquence)
Feature stores (Feast, Tecton) pour un serving de features cohérent
MLFlow ou W&B pour le suivi des expériences et le registre de modèles
Monitoring : Evidently AI ou dashboards personnalisés pour la détection de dérive

Coût : Calcul d’entraînement (périodique), calcul d’inférence (faible par prédiction) et labellisation continue des données.

Niveau 3 : Agents LLM

Quand utiliser : Compréhension du langage naturel, raisonnement complexe, workflows multi-étapes et problèmes où l’espace d’entrée est trop large ou non structuré pour les deux premiers niveaux.

Les LLMs excellent quand vous avez besoin de flexibilité, de créativité ou de la capacité à gérer des entrées nouvelles avec grâce. Mais ils nécessitent des garde-fous, des frameworks d’évaluation et des mécanismes humain-dans-la-boucle.

Caractéristiques :

Les entrées sont non structurées (langage naturel, formats de documents variés)
La tâche nécessite du raisonnement, pas juste de la reconnaissance de patterns
Des entrées nouvelles sont attendues et doivent être gérées gracieusement
La qualité peut être évaluée mais ne peut pas être réduite à une simple métrique
La tolérance au coût et à la latence est plus élevée

Exemples concrets (SaaS entreprise) :

Extraction de données de document : Lire un document PDF non structuré et extraire le nom du client, le numéro de document, la date, les lignes, les montants, la taxe, la devise. La variation dans les formats de documents rend cela impraticable avec des règles ou du ML traditionnel. Les LLMs gèrent les nouveaux formats en zero-shot.
Assistance à la résolution d’exceptions : “Cette commande d’Acme Corp a un écart de prix de 15% sur la ligne 3. Voici le contrat original, la confirmation et la liste de prix du client. Quelle est l’explication probable et l’action recommandée ?” Raisonnement multi-documents.
Communication client : Rédiger un email à un client demandant un document corrigé, en référençant l’écart spécifique et les numéros de commande pertinents. Génération de langage naturel avec contexte domaine.
Imputation des coûts pour les commandes ad hoc : “Ceci est une commande d’un cabinet de conseil pour ‘services de conseil stratégique T4 2025’. Basé sur les patterns d’imputation historiques et la structure des coûts, recommander le centre de coûts et la catégorie.” Nécessite de comprendre à la fois le contenu de la commande et la structure organisationnelle.
Résolution de requêtes helpdesk : “Pourquoi ma commande a-t-elle été rejetée ?” Nécessite de comprendre l’historique de la commande spécifique, les règles métier applicables et d’expliquer en langage courant.

Implémentation :

Claude Opus/Sonnet via API pour les tâches de raisonnement complexe
GPT-4o ou Gemini 2.5 Flash pour les tâches à haut volume et moindre complexité
Serveurs MCP pour l’intégration d’outils (recherches en base, requêtes systèmes backend, envoi d’emails)
Sortie structurée (JSON schema) pour une extraction de données fiable
Pipeline RAG pour ancrer les réponses dans les données organisationnelles
Garde-fous : validation des sorties, seuils de confiance, humain-dans-la-boucle pour les décisions à enjeux élevés
Évaluation : suites de tests automatisées, LLM-as-judge, échantillonnage humain

Coût : Significativement plus élevé par transaction que les niveaux 1 et 2. Coûts de tokens, latence (secondes, pas millisecondes) et infrastructure d’évaluation.

Le framework de décision

La hiérarchie est intentionnelle : commencez toujours au niveau 1 et ne montez que quand le problème le nécessite réellement. Chaque niveau ajoute des capacités mais aussi de la complexité, du coût, de la latence et de l’imprévisibilité.

Le problème peut-il être résolu avec des règles déterministes ?
├── OUI → Niveau 1. Arrêtez-vous ici. Ne sur-ingénierisez pas.
└── NON → Y a-t-il des données structurées avec des résultats labellisés ?
    ├── OUI → Niveau 2. Entraînez un modèle. Monitorez-le.
    └── NON → Cela nécessite-t-il une compréhension linguistique ou du raisonnement ?
        ├── OUI → Niveau 3. Utilisez un LLM avec des garde-fous.
        └── NON → Repensez le problème. Peut-être qu'il n'a pas besoin d'IA.

Erreurs courantes

Sur-nivellement : Utiliser un LLM pour quelque chose qu’une regex pourrait gérer. J’ai vu des équipes utiliser GPT-4 pour valider des formats d’email. Ne faites pas ça.

Sous-nivellement : Écrire 5 000 règles pour gérer quelque chose qui est intrinsèquement un problème de reconnaissance de patterns. Si votre jeu de règles a grandi à des centaines de branches if/else avec une précision décroissante, il est temps de passer au niveau 2.

Sauter le niveau 2 : Passer directement des règles aux LLMs parce que le ML “semble plus difficile”. Les modèles entraînés sont considérablement moins chers, plus rapides et plus prévisibles que les LLMs pour les tâches de classification et de scoring. L’investissement dans les données d’entraînement et le MLOps se rentabilise rapidement.

Pas de chaîne de fallback : Les meilleurs systèmes de production utilisent les niveaux comme chaîne de fallback. Le niveau 1 gère les cas faciles (60% du volume). Le niveau 2 gère les cas analysables par patterns (30%). Le niveau 3 gère le reste complexe (10%). Le LLM ne voit que les cas qui nécessitent véritablement ses capacités, ce qui maintient les coûts gérables et la qualité élevée.

Interactions entre niveaux en pratique

Les niveaux n’opèrent pas en isolation. Dans un système réel :

Le document arrive → Niveau 1 valide le format, vérifie les doublons par correspondance exacte
Extraction de données → Niveau 3 (LLM) extrait des données structurées d’un document non structuré
Scoring de fraude → Niveau 2 (modèle ML) note les données extraites par rapport aux patterns historiques
Validation → Niveau 1 effectue la validation par règles avec des règles déterministes
Routage des exceptions → Niveau 1 (règles) route selon le type d’exception et les workflows configurés
Résolution des exceptions → Niveau 3 (LLM) assiste les reviewers humains avec analyse et recommandations
Approbation → Niveau 1 (règles) applique la matrice d’approbation basée sur le montant et l’entité

Chaque niveau fait ce qu’il fait le mieux. La couche d’orchestration est déterministe (niveau 1) — vous voulez toujours un flux de contrôle prévisible, même quand des étapes individuelles utilisent du ML ou des LLMs.

Comparaison de coût et performance

	Niveau 1 : Règles	Niveau 2 : ML	Niveau 3 : LLM
Latence	<1ms	1-100ms	1-30s
Coût/transaction	~0 $	~0,001 $	0,01-0,50 $
Précision	100% (pour les cas définis)	90-99% (mesurable)	85-98% (plus difficile à mesurer)
Gestion d’entrées nouvelles	Échoue sur les cas non définis	Dégrade gracieusement	Gère bien les entrées nouvelles
Explicabilité	Parfaite	Modérée (SHAP, LIME)	Faible (peut expliquer, mais peut confabuler)
Coût de mise en place	Faible	Moyen (données + entraînement)	Faible (appel API)
Maintenance	Mise à jour des règles	Ré-entraînement, monitoring	Versionnage des prompts, évaluation

Les meilleurs systèmes IA en production utilisent les trois niveaux travaillant ensemble, avec des frontières claires et des points de transfert entre eux. Commencez simple, ajoutez de l’intelligence uniquement là où c’est nécessaire, et ayez toujours un fallback déterministe.