Recherche
Retrouver les informations utiles lorsque les utilisateurs ne connaissent pas le vocabulaire exact ou le nom du fichier.
04 — Intelligence artificielle
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 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.
Retrouver les informations utiles lorsque les utilisateurs ne connaissent pas le vocabulaire exact ou le nom du fichier.
Comprendre le langage libre et le transformer en intention ou en données structurées.
Aider les utilisateurs à naviguer dans des informations complexes, des processus ou des systèmes métier existants.
Conserver les calculs exacts, les permissions et les règles métier connues dans un logiciel déterministe.
02 — Recherche sémantique
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.
Que faire lorsqu’un client ne peut plus accéder à son compte ?
Procédure de récupération d’accès utilisateur
RAG — Génération augmentée par récupération
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é.
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.
Faciliter la recherche et la consultation des connaissances opérationnelles internes.
Rechercher dans une documentation complexe par intention et par sens plutôt que par formulation exacte.
Aider les utilisateurs à accéder à la bonne ressource sans avoir à connaître son emplacement exact.
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
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.
Aider les utilisateurs à comprendre les informations déjà présentes dans le système.
Retrouver un document, un dossier, une ressource ou une information pertinente.
Rédiger une réponse, préremplir un formulaire ou préparer une action à valider.
Transformer une demande en langage naturel en interaction structurée avec un logiciel existant.
Du langage naturel à l’action
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.
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.
IA + outils
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.
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
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.
Extraire du texte, des métadonnées ou des champs exploitables depuis des documents et fichiers.
Découper de grandes ressources en éléments recherchables et traçables.
Transformer du contenu en langage naturel en catégories structurées ou en données d’entrée pour les processus.
Conserver des vérifications humaines ou déterministes lorsque le niveau de fiabilité attendu l’exige.
Le client ne parvient plus à se connecter depuis hier et pense que son adresse e-mail a peut-être été modifiée.
04 — Automatisation contrôlée
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.
La récupération d’informations à faible impact peut souvent s’effectuer sans validation supplémentaire.
Le système peut préparer un brouillon, une classification ou une prochaine étape à vérifier.
Les modifications de données réelles peuvent nécessiter une confirmation explicite de l’utilisateur.
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’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.
Générer une proposition de réponse tout en laissant à un membre de l’équipe la responsabilité de son envoi.
Identifier les informations importantes d’un document avant leur validation et leur enregistrement dans le système métier.
Suggérer une action sans accorder à l’assistant la permission de l’exécuter.
Hallucinations
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
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.
Envoyer uniquement les informations nécessaires à la tâche en cours.
Maintenir les données des organisations, clients et utilisateurs correctement isolées.
Restreindre les sources et les outils en fonction du rôle de l’utilisateur et de l’assistant.
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
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.
Utile lorsque les informations ou les traitements doivent rester dans un environnement contrôlé.
Accéder à de puissantes capacités générales sans avoir à exploiter en interne l’intégralité de l’infrastructure du modèle.
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
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.
É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é.
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.
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.
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
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.
Vérifier que les bons documents et les bons passages sont réellement sélectionnés.
Vérifier que les réponses générées restent utiles et fondées sur le contexte attendu.
Tester explicitement les refus, les informations indisponibles et les opérations restreintes.
Détecter les changements de comportement lorsqu’un modèle, un prompt ou un composant du pipeline est mis à jour.
Observabilité
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.
Savoir quels modèles sont appelés et pour quelles catégories de tâches.
Suivre les services et opérations autorisés qui sont sélectionnés.
Mesurer si les recherches fournissent suffisamment de contexte pertinent pour la tâche.
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 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é.
Cas d’usage concrets
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.
Rechercher dans la documentation interne par sens plutôt que par mots-clés exacts.
Répondre aux questions à partir d’une base de connaissances maîtrisée avec des sources traçables.
Intégrer l’interaction en langage naturel directement dans un portail client ou une application métier.
Extraire, classifier, résumer et rechercher les informations contenues dans des fichiers et des rapports.
Transformer des demandes humaines en opérations structurées exécutées par des logiciels existants.
Préparer des réponses, router les demandes ou enrichir les tickets tout en conservant une validation lorsque cela est nécessaire.
Préparer des formulaires, des classifications ou des actions qui restent soumises à une approbation explicite.
Combiner règles métier, données, modèles et services existants au sein d’un même processus maîtrisé.
Adoption progressive
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.
Indexer un ensemble maîtrisé de documents et mesurer la qualité de la recherche sémantique.
Générer des réponses à partir des informations récupérées dans le corpus maîtrisé.
Connecter une sélection de données et de services réels derrière des limites applicatives explicites.
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
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
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 ?
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.