Le logiciel reste le système. L’IA devient une capacité du système.

Une application métier doit toujours gérer des utilisateurs, des droits, des données, des états, des règles, des erreurs, des historiques et des intégrations. Rien de cela ne disparaît avec un LLM. L’IA vient ajouter des fonctions difficiles à coder de manière purement déterministe : interpréter un document, retrouver une information, classer un texte, résumer un dossier ou choisir une prochaine action parmi plusieurs possibilités.

Une architecture en six couches

1. Interface

Écrans, formulaires, tableaux, espace de validation et restitution. L’utilisateur doit comprendre ce que le système sait, ce qu’il propose et ce qu’il attend de lui.

2. Logique métier

Règles déterministes, statuts, permissions, calculs, contrôles et workflow. Tout ce qui peut être certain et testable doit le rester.

3. Données

Base métier, documents, historiques, métadonnées et droits d’accès. La qualité de cette couche conditionne souvent plus la valeur du système que le choix du modèle.

4. Services IA

LLM, embeddings, OCR, vision, classification ou modèles spécialisés. Cette couche doit pouvoir évoluer sans imposer une reconstruction complète du logiciel.

5. Orchestration

Enchaînement des étapes, appels d’outils, gestion des erreurs, timeouts, retries, validations et éventuelle logique agentique.

6. Supervision

Logs, coûts, temps de réponse, qualité, traces, feedback utilisateur, incidents et versions des modèles ou prompts.

Choisir la brique la plus simple qui résout le problème

Automatisation classique

Pour calculer, vérifier une règle, déplacer un fichier, appeler une API ou exécuter une séquence stable.

LLM ponctuel

Pour extraire, reformuler, résumer, classifier ou générer à partir d’une entrée clairement délimitée.

RAG

Pour répondre à partir d’un corpus interne ou injecter une connaissance actualisable dans la génération.

Agent

Lorsque le système doit choisir plusieurs actions, consulter des outils et adapter son chemin en fonction du contexte.

Le piège fréquent

Utiliser un agent pour un workflow connu augmente souvent la variabilité, les coûts et la difficulté de test sans créer de valeur supplémentaire.

Le processus de conception

  1. Décrire le travail actuel. Entrées, sorties, règles, exceptions, utilisateurs, volumes et irritants.
  2. Découper le processus. Ce qui est déterministe, ce qui demande interprétation et ce qui nécessite une décision humaine.
  3. Tester la fonction IA isolément. Avant de construire toute l’application, vérifier qu’elle atteint un niveau de qualité acceptable.
  4. Construire le workflow complet. Inclure validations, erreurs, droits, historique et intégrations.
  5. Évaluer en situation réelle. Le test porte sur le processus, pas uniquement sur la qualité d’une réponse individuelle.
  6. Superviser après déploiement. Coût, qualité, usage, erreurs, modifications du modèle et évolution du besoin.

Exemples possibles

Achats

Comparaison de catalogues fournisseurs

Logiciel d’import et de normalisation classique, avec IA pour rapprocher les descriptions difficiles à comparer.

Support

Copilote de réponse

Workflow de ticketing classique, RAG sur la documentation et LLM pour proposer une réponse validée par l’agent.

Contrats

Analyse documentaire

Extraction structurée, règles de contrôle et génération d’une synthèse avec liens vers les clauses sources.

Opérations

Traitement de dossier

Classification IA pour comprendre la demande, puis workflow déterministe pour les contrôles et validations.

Le critère de réussite : l’IA disparaît derrière l’usage

Lorsque le logiciel est bien conçu, l’utilisateur n’a pas besoin de penser au modèle. Il voit une fonction métier plus efficace, avec des résultats compréhensibles, des sources lorsque nécessaire et un mécanisme clair de validation ou de correction.