04 — Intelligence artificielle

Transformer l’IA
en un système réellement utilisable.

L’IA peut interpréter le langage, rechercher par sens, traiter des documents et assister les utilisateurs. Le véritable défi d’ingénierie consiste à relier ces capacités aux bonnes données, aux bons outils et aux règles métier appropriées, tout en gardant le contrôle sur ce que le système peut lire, produire et déclencher.

01 — Partir du problème

La première question n’est pas
quel modèle utiliser.

La question utile est : quelle tâche cherchons-nous réellement à améliorer ? La recherche, l’accès aux documents, le support, la classification, le routage ou l’interaction en langage naturel peuvent bénéficier de l’IA lorsque l’interprétation constitue la partie difficile du problème.

D’autres besoins sont mieux couverts par des règles de recherche, une automatisation déterministe ou une interface plus claire. AUKIAN distingue ces cas dès le départ : utiliser l’IA là où l’interprétation apporte de la valeur et conserver un logiciel déterministe là où il est plus fiable.

01

Recherche

Retrouver les informations utiles lorsque les utilisateurs ne connaissent pas le vocabulaire exact ou le nom du fichier.

02

Interpréter

Comprendre le langage libre et le transformer en intention ou en données structurées.

03

Assister

Aider les utilisateurs à naviguer dans des informations complexes, des processus ou des systèmes métier existants.

04

Ne pas utiliser l’IA

Conserver les calculs exacts, les permissions et les règles métier connues dans un logiciel déterministe.

02 — Recherche sémantique

Rechercher par sens,
pas seulement par mots exacts.

La recherche sémantique permet de retrouver des documents et des passages conceptuellement proches d’une requête, même lorsque leur formulation diffère fortement du contenu source. Elle est particulièrement utile pour de grandes collections de procédures, de documentation technique, de ressources de formation et de connaissances internes.

Les utilisateurs n’ont plus besoin de connaître le titre exact d’un document ni d’en reproduire la terminologie. Le contenu peut être représenté numériquement et comparé au sens d’une requête.

L’objectif n’est pas de remplacer la documentation, mais de réduire la distance entre une question et les informations nécessaires pour y répondre.

USER QUERY

Que faire lorsqu’un client ne peut plus accéder à son compte ?

↓ semantic similarity ↓
MATCHED DOCUMENT

Procédure de récupération d’accès utilisateur

RAG — Génération augmentée par récupération

Répondre à partir de
connaissances maîtrisées.

Un modèle de langage ne connaît pas automatiquement les procédures ou les documents internes d’une organisation. Le RAG récupère d’abord le contenu pertinent et le fournit au modèle au moment de la requête afin que la réponse puisse s’appuyer sur un corpus maîtrisé.

USER QUESTION natural language request
SEMANTIC RETRIEVAL find relevant passages
SELECTED SOURCES documents / chunks / metadata
LLM question + controlled context
ANSWER grounded response

Dans un usage professionnel, une réponse générée n’a pas vocation à devenir une source de vérité indépendante. Le système peut préserver le lien entre la réponse et les documents ou passages utilisés pour la produire.

L’assistant devient ainsi une nouvelle interface vers les connaissances existantes : les utilisateurs peuvent obtenir une réponse tout en conservant la possibilité de revenir à la procédure, au document technique ou à l’entrée de la base de connaissances correspondante.

01

Procédures

Faciliter la recherche et la consultation des connaissances opérationnelles internes.

02

Documentation technique

Rechercher dans une documentation complexe par intention et par sens plutôt que par formulation exacte.

03

Contenus de formation

Aider les utilisateurs à accéder à la bonne ressource sans avoir à connaître son emplacement exact.

04

Bases de connaissances

Réunir des informations structurées et non structurées derrière une même interface naturelle.

03 — Assistants intégrés aux outils métier

La conversation peut devenir
une nouvelle interface logicielle.

Un assistant devient utile lorsqu’il comprend le contexte dans lequel il intervient. Intégré à une application métier ou à un portail, il peut aider les utilisateurs à retrouver des informations, préparer une action ou naviguer dans un système complexe sans devenir un chatbot déconnecté du reste.

01

Expliquer

Aider les utilisateurs à comprendre les informations déjà présentes dans le système.

02

Retrouver

Retrouver un document, un dossier, une ressource ou une information pertinente.

03

Préparer

Rédiger une réponse, préremplir un formulaire ou préparer une action à valider.

04

Naviguer

Transformer une demande en langage naturel en interaction structurée avec un logiciel existant.

Du langage naturel à l’action

Le modèle comprend le langage.
Le système métier reste responsable de la logique métier.

Lorsqu’un utilisateur demande des données opérationnelles réelles, le modèle n’a pas besoin de connaître lui-même ces données. Il peut interpréter la demande, produire une intention structurée et appeler le service logiciel responsable des règles et des informations réelles.

USER REQUEST "Show me open cases still waiting for validation."
LLM interpret language
STRUCTURED INTENT filters / action / parameters
BUSINESS SERVICES apply rules / query real data
USER RESULT verified operational information

Les calculs exacts, les vérifications de permissions, les règles contractuelles, les modifications de base de données et les décisions d’autorisation restent généralement déterministes. Le modèle peut comprendre ce que souhaite l’utilisateur sans devenir responsable de l’exactitude de ces opérations.

Cette séparation est fondamentale : l’IA interprète le langage, tandis que l’application reste l’autorité pour la logique métier et les données réelles.

01 L’IA interprète.
02 Le logiciel vérifie.
03 Les données répondent.
04 L’utilisateur décide.

IA + outils

Aller au-delà
du chatbot isolé.

Un assistant peut disposer d’un ensemble limité d’outils explicites pour la recherche documentaire, les API métier, l’accès aux données ou le traitement de documents. Il n’a pas besoin d’un accès sans restriction à l’ensemble du système.

BUSINESS API controlled operations
DATA SERVICE structured information
DOCUMENT PROCESSING extract / classify
ASSISTANT select authorized tools

Chaque outil possède un rôle, des paramètres et des permissions définis. Il est ainsi possible de contrôler précisément ce que l’assistant peut faire et de maintenir les opérations sensibles derrière des limites applicatives explicites.

La même approche peut être utilisée pour rechercher des documents, consulter des données, générer un brouillon, préremplir un formulaire ou préparer une action sans donner au modèle un accès sans restriction au système.

Traitement documentaire

Transformer les documents
en informations exploitables.

Les PDF, rapports, procédures, contrats, tableaux et fichiers internes contiennent des informations précieuses qui restent souvent difficiles à intégrer dans les processus logiciels. Des pipelines documentaires peuvent extraire, segmenter, classifier, rechercher ou résumer ces contenus grâce à une combinaison adaptée de règles déterministes et d’IA.

01

Extraire

Extraire du texte, des métadonnées ou des champs exploitables depuis des documents et fichiers.

02

Segmenter

Découper de grandes ressources en éléments recherchables et traçables.

03

Classifier

Transformer du contenu en langage naturel en catégories structurées ou en données d’entrée pour les processus.

04

Valider

Conserver des vérifications humaines ou déterministes lorsque le niveau de fiabilité attendu l’exige.

Langage naturel

Le client ne parvient plus à se connecter depuis hier et pense que son adresse e-mail a peut-être été modifiée.

Informations structurées

TYPEproblème d’accès
ACCOUNTclient
SYMPTOMéchec d’authentification
CAUSEchangement d’adresse e-mail suspecté
DATEdepuis hier

04 — Automatisation contrôlée

Automatiser en fonction
du niveau de risque.

Rechercher une information n’équivaut pas à modifier des données, et préparer un brouillon n’équivaut pas à l’envoyer. Les différentes opérations nécessitent différents niveaux d’autonomie en fonction de leurs conséquences.

Recherche d’informations Automatique

La récupération d’informations à faible impact peut souvent s’effectuer sans validation supplémentaire.

Préparation d’une action Suggestion

Le système peut préparer un brouillon, une classification ou une prochaine étape à vérifier.

Modification des données Confirmation explicite

Les modifications de données réelles peuvent nécessiter une confirmation explicite de l’utilisateur.

Décision sensible Validation humaine

Les actions critiques peuvent rester déterministes ou nécessiter une autorisation humaine explicite.

Cela permet à l’IA d’apporter rapidité et capacité d’interprétation sans devenir automatiquement l’autorité responsable de chaque action.

Le système peut augmenter progressivement le niveau d’automatisation lorsque les conséquences sont comprises et que les contrôles sont adaptés.

Humain dans la boucle

L’assistance n’implique pas
de renoncer à la responsabilité.

L’IA peut rechercher, résumer, préparer et proposer, tandis que l’autorité finale reste humaine lorsque le processus exige une responsabilité explicite ou une expertise métier.

01 Rédiger

Générer une proposition de réponse tout en laissant à un membre de l’équipe la responsabilité de son envoi.

02 Extraire

Identifier les informations importantes d’un document avant leur validation et leur enregistrement dans le système métier.

03 Recommander

Suggérer une action sans accorder à l’assistant la permission de l’exécuter.

Hallucinations

Concevoir en partant du principe
que le modèle peut se tromper.

Un modèle génératif peut produire des informations incorrectes avec une formulation convaincante. Cela doit être considéré comme une caractéristique du composant, et non comme une anomalie exceptionnelle.

L’objectif n’est pas de construire une IA qui ne se trompe jamais. Il est de construire un système dans lequel une erreur du modèle ne devient pas automatiquement une erreur métier.

Des sources de connaissances maîtrisées, des éléments de preuve cités, des vérifications déterministes, un accès limité aux outils et une validation humaine peuvent réduire les conséquences liées à l’incertitude du modèle.

05 — Données, confidentialité & déploiement

Concevoir autour des données
avant de concevoir autour du modèle.

Toutes les informations n’ont pas besoin d’être exposées à un modèle. Les données peuvent être sélectionnées pour chaque requête, séparées par utilisateur ou organisation et limitées aux fonctions et aux sources réellement nécessaires.

01

Minimisation des données

Envoyer uniquement les informations nécessaires à la tâche en cours.

02

Séparation

Maintenir les données des organisations, clients et utilisateurs correctement isolées.

03

Permissions

Restreindre les sources et les outils en fonction du rôle de l’utilisateur et de l’assistant.

04

Choix d’hébergement

Choisir une exécution cloud, dédiée ou locale en fonction de la sensibilité des données, des coûts et des contraintes opérationnelles.

Modèles cloud, locaux & hybrides

Placer chaque traitement
là où il est le plus adapté.

Les modèles cloud offrent un accès rapide à des capacités puissantes. Les modèles locaux ou dédiés peuvent être utiles lorsque les données doivent rester dans un environnement contrôlé ou lorsque les contraintes économiques du déploiement justifient une infrastructure dédiée. Une architecture hybride peut utiliser différents composants selon les tâches.

AI ORCHESTRATION
Modèle local Tâches sensibles

Utile lorsque les informations ou les traitements doivent rester dans un environnement contrôlé.

Modèle cloud Raisonnement complexe

Accéder à de puissantes capacités générales sans avoir à exploiter en interne l’intégralité de l’infrastructure du modèle.

Logiciel classique Tâches déterministes

Conserver les calculs, les permissions et la logique métier exacte dans un logiciel conventionnel.

L’objectif n’est pas de choisir idéologiquement entre le local et le cloud. Il s’agit de placer chaque traitement dans l’environnement qui correspond le mieux à ses contraintes.

Maîtrise des coûts

Un système utile
doit aussi être économiquement viable.

Le coût en production peut dépendre du volume de documents, de la fréquence des requêtes, de la taille du contexte, du choix des modèles et de l’infrastructure. Ces contraintes doivent faire partie de l’architecture, et non être découvertes après l’adoption du système.

01 Mise en cache

Éviter de répéter des traitements coûteux lorsque des résultats précédents peuvent être réutilisés en toute sécurité.

02 Limites d’utilisation

Définir des quotas ou des limites de fréquence lorsque la consommation non contrôlée pourrait générer des coûts inutiles.

03 Routage des modèles

Utiliser des modèles plus petits ou spécialisés pour les tâches simples et réserver les modèles plus puissants aux cas qui en ont réellement besoin.

04 Prétraitement

Indexer les documents et effectuer à l’avance ou de manière asynchrone les traitements non urgents lorsque cela est possible.

Évaluer avant le déploiement

Mesurer le comportement,
ne pas se contenter d’admirer la démo.

La qualité de la recherche, la pertinence des informations récupérées, le comportement de refus, les formats de sortie et le comportement en cas d’informations manquantes peuvent tous être testés sur des cas représentatifs. L’évaluation fait de l’IA un composant qui peut être amélioré et comparé dans le temps.

01

Qualité de la récupération

Vérifier que les bons documents et les bons passages sont réellement sélectionnés.

02

Qualité des réponses

Vérifier que les réponses générées restent utiles et fondées sur le contexte attendu.

03

Comportement de sécurité

Tester explicitement les refus, les informations indisponibles et les opérations restreintes.

04

Contrôle des régressions

Détecter les changements de comportement lorsqu’un modèle, un prompt ou un composant du pipeline est mis à jour.

Observabilité

Exploiter l’IA
comme le reste du système.

Une fois en production, il doit être possible de comprendre quels modèles et outils sont utilisés, comment se comporte la récupération d’informations, combien coûtent les requêtes, où surviennent les erreurs et si les temps de réponse restent acceptables.

01 Appels aux modèles

Savoir quels modèles sont appelés et pour quelles catégories de tâches.

02 Utilisation des outils

Suivre les services et opérations autorisés qui sont sélectionnés.

03 Comportement de la récupération

Mesurer si les recherches fournissent suffisamment de contexte pertinent pour la tâche.

04 Coût & latence

Surveiller le coût par requête et le temps de réponse afin que l’utilisation réelle reste soutenable.

Une architecture IA maîtrisée

Le LLM n’est
qu’un composant parmi d’autres.

Le véritable produit comprend l’orchestration, les permissions, les sources de connaissances, les outils métier, la sélection des modèles, la validation, l’audit et la sécurité. C’est cet ensemble qui transforme un simple appel à un modèle en un système logiciel maîtrisé.

USERS question · document · business request
AI ORCHESTRATION intent · context · permissions · tool selection
KNOWLEDGE documents · vector search · databases
BUSINESS TOOLS APIs · services · workflows
AI MODELS local · cloud · specialized
CONTROL LAYER validation · permissions · audit · security
RESULT / ACTION answer · draft · verified data · controlled operation

Cas d’usage concrets

Des problèmes concrets,
pas un chatbot générique.

L’IA peut intervenir derrière la recherche, le traitement documentaire, le support, les logiciels métier ou les interfaces en langage naturel. L’architecture pertinente dépend du problème à résoudre et du niveau de contrôle nécessaire.

01

Recherche sémantique

Rechercher dans la documentation interne par sens plutôt que par mots-clés exacts.

02

Assistants de connaissances

Répondre aux questions à partir d’une base de connaissances maîtrisée avec des sources traçables.

03

Assistants intégrés

Intégrer l’interaction en langage naturel directement dans un portail client ou une application métier.

04

Intelligence documentaire

Extraire, classifier, résumer et rechercher les informations contenues dans des fichiers et des rapports.

05

Interfaces en langage naturel

Transformer des demandes humaines en opérations structurées exécutées par des logiciels existants.

06

Assistance au support

Préparer des réponses, router les demandes ou enrichir les tickets tout en conservant une validation lorsque cela est nécessaire.

07

Préparation contrôlée des actions

Préparer des formulaires, des classifications ou des actions qui restent soumises à une approbation explicite.

08

Pipelines hybrides

Combiner règles métier, données, modèles et services existants au sein d’un même processus maîtrisé.

Adoption progressive

Valider la valeur
avant d’augmenter l’autonomie.

Une organisation n’a pas besoin de commencer par un assistant connecté à l’ensemble de son système d’information. La recherche peut être validée d’abord, puis le RAG, puis les données métier et enfin des actions soigneusement contrôlées.

01

Recherche

Indexer un ensemble maîtrisé de documents et mesurer la qualité de la recherche sémantique.

02

RAG

Générer des réponses à partir des informations récupérées dans le corpus maîtrisé.

03

Données métier

Connecter une sélection de données et de services réels derrière des limites applicatives explicites.

04

Actions contrôlées

Ajouter des outils et des permissions sélectionnés uniquement après avoir compris leur valeur et les risques associés.

Quand l’IA n’est pas la bonne solution

Parfois, un logiciel classique
est tout simplement préférable.

Lorsque les règles sont connues, que les données d’entrée sont structurées et que le résultat attendu doit être exact, un logiciel déterministe peut être plus simple, plus rapide, moins coûteux et plus fiable.

L’IA est particulièrement utile lorsque le problème implique le langage, le sens, des documents, des informations non structurées ou des demandes difficiles à formaliser à l’avance. Savoir quand ne pas utiliser l’IA fait partie d’une bonne intégration.

L’IA comme composant d’un système plus large

L’objectif n’est pas
d’ajouter de l’IA à un produit.

Les capacités d’IA les plus utiles ne sont pas toujours les plus visibles. L’IA peut intervenir derrière un moteur de recherche, un traitement documentaire, un processus métier ou une interface conversationnelle donnant accès à des services existants.

AUKIAN aborde l’IA avec la même logique d’ingénierie que le reste du système : comprendre le besoin, définir les responsabilités, maîtriser les échanges, anticiper les erreurs et construire une architecture capable d’évoluer.

L’objectif est de construire un meilleur produit lorsque l’IA permet réellement d’y parvenir.

Un cas d’usage IA à évaluer ?

Partir des données,
des utilisateurs et du problème.

Décrivez les informations disponibles, les utilisateurs concernés et la tâche à améliorer. La première étape consiste à déterminer où l’IA peut créer de la valeur — et où elle n’est pas nécessaire.

Parler d’un projet IA