Un modèle n’est pas une encyclopédie

Un modèle de langage produit du texte à partir de la demande et du contexte dont il dispose. Il a appris des régularités pendant son entraînement, mais cela ne veut pas dire qu’il consulte une source fiable à chaque réponse. Une réponse bien formulée peut être inexacte.

Des possibilités qui changent

De nouveaux modèles et de nouvelles fonctions apparaissent, tandis que des noms, limites ou tarifs peuvent changer. Une explication de principe reste utile, mais ne suffit pas à confirmer la disponibilité d’une fonction aujourd’hui. Pour comparer deux modèles ou choisir un réglage, vérifie la documentation actuelle du service et essaie des cas fictifs comparables. Cette page n’affiche aucune liste garantie des modèles du portail IA interne.

Pourquoi préciser sa demande ?

Le contexte aide à comprendre l’objectif, le public et le format attendus. « Écris un message » laisse davantage à deviner que « Rédige trois phrases courtes pour accueillir un collègue fictif ». Même une demande précise ne garantit pas une réponse exacte.

À retenir

Distingue ce que le modèle rédige, ce qu’un document effectivement consulté étaye et ce qu’un outil connecté réalise. Demande des preuves adaptées aux décisions importantes.

Un token n’est pas forcément un mot

Un modèle découpe le texte en unités appelées tokens. Le nombre d’unités dépend du texte et du modèle. Une longue procédure, la conversation et la réponse attendue utilisent une partie du contexte disponible. Il n’existe pas de nombre de mots universel à appliquer à tous les modèles.

Si le contexte devient trop long

Selon le service, une demande peut être tronquée, refusée ou traitée autrement. Ne présume pas que le modèle se souvient de tout ce qui a été écrit. Pour une procédure volumineuse, pose une question ciblée, vérifie ce qui a été réellement transmis ou retrouvé et contrôle le passage pertinent.

Limites de ce parcours

Cette page ne confirme ni la taille de contexte, ni le mode de découpage, ni la facturation ou les limites des modèles dans le portail IA interne. Un token de texte n’est pas un jeton secret d’accès.

Partir du travail à accomplir

Un modèle peut mieux convenir à une tâche qu’un autre selon la qualité des réponses observées, la rapidité, les formats acceptés, les limites de contexte et les conditions d’usage. Le nom du modèle ne suffit pas à conclure, et un résultat mesuré aujourd’hui peut évoluer avec la configuration et les versions. Compare plusieurs modèles avec les mêmes cas fictifs, les mêmes instructions et les mêmes sources accessibles.

Une grille de comparaison simple

Éviter le piège

Une base mal indexée ou une instruction ambiguë ne se corrige pas forcément en choisissant un modèle différent. Il faut d’abord savoir si l’échec vient de la récupération, des permissions, du raisonnement ou de la présentation.

Rechercher ou traiter directement ?

Une Knowledge Base est un ensemble de documents à rechercher. Le RAG désigne une approche où des passages pertinents sont récupérés pour aider à répondre. Une pièce jointe sert plutôt à traiter le fichier disponible pour la tâche, si son utilisation est autorisée. Le modèle ne retrouve pas nécessairement le bon passage, même lorsqu’une base est connectée.

Le cas de la procédure d’accueil fictive

Pour demander l’étape suivante, il faut trouver la bonne procédure, sa version et le passage qui répond à la question. Une procédure peut aussi contenir une consigne générale. La garder comme source ne garantit pas que sa consigne sera appliquée à chaque demande. Si elle doit toujours guider l’agent dans les tâches concernées, l’exprimer également dans ses instructions et tester le comportement.

Ce qu’il faut vérifier

Vérifie les droits avant le dépôt ou la recherche, la version du document, les passages réellement retrouvés et la réponse. La simple présence d’un titre dans la base n’est ni une autorisation ni une preuve de justesse.

Un chat, un agent et un outil

Un chat peut suffire pour une demande ponctuelle. Un agent ajoute une mission et des consignes préparées. Une connexion API peut permettre une action dans un autre service, si elle est configurée et autorisée. Sa présence et son fonctionnement ne sont pas démontrés par cette page. Écrire « envoie ce fichier » ne veut pas dire qu’un envoi a eu lieu.

Sous-agents dans le portail IA interne

Portail IA interne propose Select Sub-agents. L’interface précise des conditions de sélection liées aux Skills, aux outils de codage, à Coding/Canvas et à Server Sandbox. La présence de l’option ne démontre pas qu’une délégation a été exécutée. Commence avec un seul agent si cela suffit, puis définis les données, droits et contrôles avant toute délégation.

Hooks et workflows

Un workflow est l’ordre d’étapes, de choix et d’erreurs possibles. Un Hook est un concept de déclencheur technique à un moment d’un flux. Un document décrivant ces étapes ne les automatise pas. La disponibilité de Hooks pour cet agent n’a pas été établie.

Une consigne permanente ou une méthode réutilisable ?

Le prompt courant décrit la tâche du jour. Les instructions permanentes définissent le rôle et les obligations applicables aux demandes concernées. Un Skill décrit une méthode à utiliser pour certaines tâches, avec un déclencheur et des exclusions. Une obligation qui doit toujours s’appliquer ne peut pas dépendre seulement du rappel d’un Skill ou d’un passage de document retrouvé.

Créer un Skill sans confondre sa méthode et une obligation

Partir d’une tâche répétable précise. Donner au Skill un déclencheur, des exclusions et des étapes observables, puis prévoir sa sortie et ses garde-fous. Pour le format utilisé dans ce projet, le fichier SKILL.md contient name et description dans son en-tête, puis Purpose, Trigger, Exclusions, Procedure, Output et Guardrails. Le portail IA interne propose la création de Skills. La liste des Skills déjà présents peut varier selon le compte. Leur menu de gestion propose aussi « Share ». Un Skill partagé reste une méthode dont le déclenchement dans un agent doit être vérifié avec un cas pertinent et un cas hors sujet. Partager la méthode ne donne pas pour autant accès aux documents qu’elle pourrait mentionner.

Les fichiers ne s’activent pas par leur nom

Des noms comme rules.md, agent-review.md ou hooks/ servent à organiser un projet. Il faut vérifier comment l’environnement lit ou déclenche réellement ces contenus. Un Skill destiné au projet du portail IA interne utilise un fichier SKILL.md avec son format prévu.

Avant de faire produire du code

Une règle métier décrit ce qui doit se passer dans une situation, avec les droits, les données et les erreurs possibles. Exemple fictif : une personne sans droit ne peut pas confirmer une demande. Le critère observable serait un refus sans modification. Identifier d’abord les décisions à faire valider.

Différents contrôles, différentes preuves

Une évaluation de l’agent observe sa réponse à des cas préparés. Un test unitaire vérifie une logique isolée lorsqu’elle existe. L’intégration vérifie l’échange de composants accessibles ; un test E2E suit un parcours réellement configuré ; des tests smoke vérifient rapidement quelques fonctions critiques. Une question posée au modèle n’est pas automatiquement un test unitaire.

Ne pas surpromettre

Indique les tests exécutés, leurs résultats et preuves. Si tu n’as testé que le fichier dans un conteneur Python, cela ne prouve pas les droits du portail IA interne ou l’expérience au clavier dans un vrai navigateur. Un test prévu reste « non exécuté » tant qu’il n’a pas été lancé.

L’accès doit être imposé avant la réponse

Si des procédures sont réservées à certains magasins, demander au modèle de « ne pas les afficher » n’est pas un contrôle d’accès. Il faut vérifier que les documents interdits ne sont pas retrouvés puis transmis au modèle. Cette capacité n’a pas été vérifiée pour ce portail dans ce parcours.

Une phrase ne remplace pas un mécanisme

Dire « ne conserve pas le fichier » dans une instruction ne prouve pas sa suppression technique. Écrire « validation humaine requise » sur un brouillon ne bloque pas une diffusion. Ces points demandent des réglages, autorisations et tests distincts.

Pour une règle interne, RGPD ou AI Act

Ce parcours pédagogique ne donne aucune autorisation. Une réponse portant sur une politique ou une règle applicable doit s’appuyer sur la source approuvée, sa portée et, si possible, sa version. Quand elle manque, demander une validation humaine et ne pas inventer de réponse.

Commencer par la mission, pas par les dossiers

Qui posera la question ? Quel résultat attend-on ? Quelles informations sont autorisées ? Quelles décisions doivent rester humaines ? Pour une tâche ponctuelle, un chat peut suffire. Pour une mission répétée, prépare des instructions et les ressources utiles, puis vérifie le résultat. N’ajoute ni sous-agent, ni API, ni dossier hooks/ simplement parce qu’une option existe.

Une arborescence pour préparer le travail

projet-exemple/
├── besoin.md               # mission et décisions ouvertes
├── regles-metier.md        # règles à valider
├── instruction-agent.md    # texte à saisir dans l’outil
├── references/             # documents autorisés à connecter
├── skills/                 # méthodes au format requis
└── tests.md                # cas prévus et résultats observés

Ce dessin ne charge aucun document et n’active aucune fonction. Un rules.md ou un agent-review.md peut décrire une responsabilité dans un projet de code, mais le nom du fichier ne donne pas d’instructions au portail IA interne. Demande quel environnement est utilisé avant de proposer une arborescence plus détaillée.

Garder le fil avec un journal et Git

Un fichier status.md peut noter décisions, état des essais et prochaine étape, si la personne ou l’agent y a réellement accès. Git conserve un historique des changements dans un dépôt configuré, mais un commit n’est pas une preuve que les tests sont réussis. Les instructions rédigées en Markdown doivent être saisies ou chargées dans l’outil qui doit les appliquer.

RAG, SQLite et contrôles automatisés

RAG peut aider à retrouver des passages dans des documents, tandis que SQLite peut servir à consulter des enregistrements structurés par identifiant. La meilleure solution dépend des données, des accès et d’essais mesurés ; rien ne démontre qu’une base SQLite est toujours plus rapide. Une CI et Playwright peuvent vérifier du code et un parcours navigateur si le dépôt, le conteneur, les navigateurs et les permissions sont configurés. Ce parcours n’a aucune connexion à ces outils.

Passer de l’idée à la vérification

Prépare un cas ordinaire, un document absent, une contradiction et une demande hors périmètre. Vérifie séparément la réponse observable et les droits techniques. Une consigne « ne révèle pas le magasin B » ne bloque pas la récupération d’un passage B déjà transmis au modèle. Aucun filtrage de ce type n’est confirmé dans le portail par cette page.

Deux versions d’un même projet

Version minimale : une instruction claire, une base autorisée si des documents sont indispensables, une méthode facultative et des cas d’évaluation. Version plus élaborée : rôles distincts, outils, délégation et automatisation, uniquement si un problème concret le justifie. Pour chaque ajout, noter la tâche, les données transmises, les permissions, le coût de coordination et le contrôle du résultat. Un dépôt bien rangé facilite la collaboration mais n’active ni un fichier rules.md ni un agent-review.md. Demande toujours quel IDE ou portail doit interpréter ces fichiers.

Définir le résultat attendu avant l’essai

Choisis des situations fictives proches du travail attendu. Note pour chacune la question, les documents réellement accessibles, la réponse souhaitée et les erreurs à éviter. Sépare les cas faciles, les sources manquantes, les contradictions et les questions hors périmètre. Ne juge pas seulement si la réponse « sonne bien » : regarde si elle répond à la question et si les sources retrouvées soutiennent ce qu’elle affirme.

Contrôler la recherche, pas seulement la phrase finale

Une KB peut retourner un passage proche par les mots, mais hors sujet. Lorsque les outils le permettent, examine les passages récupérés, leur version et les droits appliqués avant qu’ils arrivent au modèle. Si ces éléments ne sont pas inspectables, indique la limite au lieu de conclure que la confidentialité ou la récupération sont validées.

Décrire honnêtement ce qui a été fait

Pour chaque règle identifiée, relie besoin, critère observable, test, résultat et preuve. « J’ai écrit un test » n’est pas « je l’ai exécuté ». Un fichier HTML dont la logique a été exercée par un script n’a pas forcément été testé dans un vrai navigateur. Si tu changes l’instruction, une base et le modèle en même temps, tu ne sauras pas lequel a changé le résultat.

Cas négatifs et changements de configuration

Une recette qui ne teste que les réponses correctes laisse de côté les erreurs les plus instructives. Essaie un passage absent, une ancienne version, une question ambiguë et, si les droits techniques sont disponibles, une recherche interdite par un compte de test. Si une personne perd l’accès à un magasin, vérifier que les documents ne remontent plus dans les passages récupérés, pas seulement qu’ils disparaissent de la réponse finale. À chaque changement d’instruction, de Skill, de modèle ou de KB, garde des cas de référence et note précisément ce qui a changé. Ne présente jamais une fonctionnalité non accessible comme un test exécuté.