Ce que doit avoir une plateforme IA aujourd’hui

1. Organiser les responsabilités

Une architecture doit permettre de suivre une demande jusqu’à son résultat. L’interface recueille l’objectif et les décisions humaines. Les services métier connaissent les objets, leurs états et les droits. Le moteur d’exécution prépare le contexte, appelle le modèle et conduit les outils. La couche de données conserve les sources et les traces selon leurs règles de rétention.

Ces couches n’imposent pas une technologie ni un découpage en microservices. Elles demandent de savoir qui fait autorité. Un résumé de conversation peut orienter le travail ; l’autorisation de publier un document et l’état de sa version relèvent des services applicatifs.

Pour la DSI, cette séparation rend aussi le parcours des données inspectable : quel contenu part vers un modèle, un OCR ou un service de reclassement ? Sous quelle identité ? Que conserve le fournisseur ? Les mêmes questions s’appliquent aux caches, aux journaux et aux sauvegardes.

2. Définir les objets et les capacités

La plateforme doit distinguer un client, un contrat, une version, une clause et une décision. Un nom de fichier ne suffit pas à identifier la bonne source. Des identifiants stables et des relations explicites permettent de relier une version au contrat concerné et une décision au contenu réellement examiné.

Ce modèle sémantique peut s’appuyer sur un vocabulaire contrôlé et des schémas métier. Une ontologie formelle ajoute des axiomes interprétables par machine lorsque le besoin le justifie. Un graphe de connaissances relie des instances concrètes. Ces dispositifs ont des fonctions différentes : leur pertinence se juge sur les questions à résoudre. Les recommandations SKOS et OWL donnent des repères pour les distinguer.

Les actions suivent la même logique. Un catalogue de capacités décrit ce qu’un outil sait faire, ses entrées, ses sorties et ses effets. « Préparer un brouillon » et « publier la version approuvée » ont des préconditions et des permissions différentes. Une annotation descriptive ne remplace pas leur contrôle dans le serveur.

Quand le catalogue grandit, une recherche de capacités et le chargement de leurs seuls schémas utiles évitent de transmettre tous les outils au modèle. La version découverte doit rester identifiable au moment de l’appel : une mise à jour qui change les permissions ou les effets peut demander une nouvelle revue.

3. Maîtriser le contexte et la mémoire

À chaque appel, le modèle reçoit une sélection d’informations. Cette sélection comprend instructions, objectif, schémas d’outils, historique utile, passages documentaires et résultats déjà obtenus. L’ingénierie du contexte consiste à choisir ce qui doit être présent pour la prochaine étape, dans les limites du modèle.

Quatre couches méritent d’être séparées :

Le budget d’entrée réserve de la place pour la sortie et une marge technique. Les schémas d’outils et les résultats consomment eux aussi des tokens. Il n’existe pas de proportion universelle entre ces postes ; les limites d’entrée, de sortie et de raisonnement dépendent du modèle et du fournisseur.

Lorsque l’historique s’allonge, un compactage peut préserver objectif, contraintes, décisions et questions ouvertes. Il doit garder des références aux messages d’origine. Une correction tardive doit pouvoir remplacer l’ancienne orientation. Les résultats volumineux peuvent être transmis par extraits, avec couverture et continuation explicites.

La mémoire exige aussi une gestion de la fraîcheur. Une préférence de rédaction peut rester utile longtemps ; le statut d’une facture demande une nouvelle lecture dans sa source. Le cache de préfixe proposé par certains fournisseurs réduit le retraitement d’entrées stables, mais ne constitue pas une mémoire métier.

Ces distinctions rejoignent les pratiques d’ingénierie du contexte. Le test révélateur consiste à corriger une contrainte au milieu d’un long échange, puis à vérifier qu’elle est respectée après plusieurs reprises.

4. Retrouver les sources et vérifier leur portée

Le RAG, pour Retrieval-Augmented Generation, fournit au modèle des éléments retrouvés dans des sources externes au moment de répondre. Sa qualité commence par l’ingestion : extraction, OCR si nécessaire, découpage sensible à la structure, versions, locateurs et droits.

La recherche lexicale retrouve termes précis et références. La recherche vectorielle cherche une proximité de sens à partir d’embeddings, des représentations numériques des contenus. Une recherche hybride fusionne leurs classements, puis un reclassement peut sélectionner les meilleurs passages. Les détails du fonctionnement sont décrits notamment dans la documentation de Microsoft sur la recherche hybride.

La méthode dépend de la question. Pour comparer deux versions, il faut consulter chacune d’elles. Pour compter des factures, une requête structurée et un calcul vérifiable sont souvent plus adaptés qu’une sélection d’extraits. Pour explorer des relations ou produire une synthèse globale, un graphe peut être utile, à condition d’en mesurer l’apport.

Les passages non autorisés ne doivent être transmis ni au modèle ni à un reranker externe. Les filtres d’accès font partie du parcours de recherche et doivent rester valides lors de la lecture. La révocation doit aussi s’appliquer aux résultats conservés dans un cache.

Trouver un extrait, lire une source et démontrer une conclusion sont trois opérations distinctes.

Une citation doit identifier la source, sa version et le passage utilisé. L’extraction peut être partielle : parcourir tous les passages indexés ne prouve pas que chaque graphique a été compris. L’absence de résultat ne suffit pas à conclure qu’une clause n’existe pas. La réponse doit conserver les limites de sa couverture.

5. Exposer les outils avec MCP

Le Model Context Protocol standardise des échanges entre un client et des serveurs de capacités. Une plateforme peut consommer des outils tiers et exposer ses propres fonctions à des assistants externes. Il faut vérifier la révision et les primitives effectivement prises en charge.

Les tools décrivent des opérations appelables, les resources des contenus adressables et les prompts des gabarits d’interaction. Un serveur peut n’en implémenter qu’une partie. Le protocole facilite l’interopérabilité ; le sens métier des objets et les règles d’exécution restent dans l’application.

Un bon contrat d’outil précise schéma d’entrée, résultat structuré, effets possibles, erreurs et modalités de continuation. Les annotations, par exemple « lecture seule », sont des indications pour le client. Le serveur applique lui-même les permissions et valide les arguments.

Pour un transport HTTP protégé, le profil d’autorisation MCP s’appuie sur OAuth. Il relie l’accès à un client, un utilisateur et une ressource cible. Les scopes de connexion ne dispensent pas de vérifier les droits actuels sur le document ou l’opération métier.

Une action sensible peut demander une préparation qui fige cible, version et arguments, puis une décision authentifiée selon la politique. Au moment d’exécuter, les droits et préconditions sont revérifiés. Un texte trouvé dans un document, une description d’outil ou une réponse du modèle ne vaut pas approbation.

Le test utile est simple à formuler : préparer une écriture, révoquer le droit, puis tenter de la reprendre. Le serveur doit refuser l’effet concerné. Les bonnes pratiques MCP détaillent les frontières d’autorité et les risques de délégation.

6. Exécuter, reprendre et évaluer

Une opération connue peut relever d’un appel direct ou d’un workflow aux transitions explicites. Un agent devient utile lorsque le chemin doit s’adapter aux résultats. Dans les deux cas, les opérations à effet métier doivent rester contrôlées. Ajouter plusieurs agents ne se justifie que si leur spécialisation apporte un gain mesurable.

L’exécution durable conserve objectif, étapes, versions, décisions et reçus. Après une interruption, le moteur reprend à partir des résultats confirmés. S’il a perdu la réponse après une écriture distante, l’effet peut être incertain : la vérification dans le système cible précède une nouvelle tentative. Une clé d’idempotence aide à dédupliquer dans son périmètre ; elle ne garantit pas à elle seule une transaction « exactement une fois » entre plusieurs systèmes.

Les traces relient recherche, appel modèle, outils et résultat enregistré. Elles servent à comprendre le coût et la latence d’une tâche, avec minimisation des données sensibles. La DSI doit pouvoir identifier qui exploite le service, les objectifs de disponibilité, les délais de restauration et la procédure de traitement d’un résultat incertain.

Ce qu’il faut demander à voir

• Un jeu de tâches indépendant. Des documents et des cas métier représentatifs, y compris les sources manquantes et les demandes auxquelles il faut s’abstenir de répondre.
• Des résultats vérifiés. Rappel des passages attendus, fidélité des réponses, état final dans l’application et temps de relecture nécessaire.
• Des essais d’incident. Révocation avec caches chauds, interruption après écriture et restauration cohérente.
• Une économie par tâche réussie. Coût incluant les tentatives, les outils et la relecture, accompagné des latences et du taux d’échec.

Les règles déterministes, les modèles juges et la revue humaine se complètent. Les juges automatiques nécessitent une calibration ; le résultat réel doit être vérifié indépendamment de ce que déclare l’agent. Les pratiques d’évaluation des agents donnent un cadre pour organiser ces preuves.