IA et artefacts de connaissance : ce qui change

L'abondance produit aussi de la similitude

Quand des modèles sont entraînés sur des corpus comparables et sollicités avec des consignes proches, les réponses se ressemblent. Pas parce que tout le monde obtient exactement le même texte. Plutôt parce que la sortie « passe partout » différencie peu une offre, un service ou une décision.

Prenons deux cabinets qui utilisent l'IA pour préparer une note destinée à un client. Les deux peuvent produire un document clair, bien mis en forme. La différence finit par venir d'ailleurs : qualité des informations mobilisées, connaissance du secteur, arbitrages, et capacité à repérer ce qui ne tient pas ou ce qui manque. La machine accélère la rédaction ; elle ne garantit pas l'expertise.

La différence utile n'est pas la personnalisation seule

On a vite envie de croire qu'une IA personnalisée va forcément apporter quelque chose de durable. Pourtant, changer un ton ou mémoriser quelques préférences n'assure pas, à lui seul, une valeur réelle.

Une différence devient utile quand elle améliore une décision, un résultat ou la façon dont le travail se fait au quotidien. Dans une entreprise, elle peut venir, par exemple, de :

• une connaissance métier rare ou difficile à formaliser ;
• des données de qualité, collectées et utilisées dans un cadre légitime ;
• une méthode qui tient dans le temps pour traiter un type de cas précis ;
• la capacité à faire coopérer plusieurs outils et équipes ;
• une expérience concrète qui permet de gérer les exceptions.

La question n'est donc pas seulement : « Quel modèle est le plus intelligent ? » Elle est aussi : « Pour quelle tâche, à quel coût, et avec quel niveau de contrôle ? » Poser la question comme ça évite de comparer des outils sur des démonstrations impressionnantes, sans regarder ce que ça donne dans un processus réel.

La spécialisation compte, mais elle ne suffit pas

Comme pour les équipes humaines, la spécialisation peut améliorer les résultats. Un agent conçu pour trier des demandes de support connaît mieux les catégories, les règles de priorité et les cas qui doivent remonter plus haut qu'un assistant généraliste. Un autre peut préparer des rapprochements de factures ou vérifier la cohérence d'un dossier fournisseur.

Mais la spécialisation ne veut pas dire « aucun garde-fou ». Si l'agent se trompe sur un cas inhabituel, il faut prévoir une reprise humaine. Si les règles changent, il faut réévaluer ce qui fait partie du périmètre. La vraie question, c'est : où se situe le coût de l'erreur, et qui le porte ? Pour une tâche facilement réversible et peu risquée, un contrôle par échantillonnage peut suffire. Pour une décision qui a des effets importants ou qui touche à des obligations réglementaires, le niveau de contrôle doit être plus strict.

La coopération multiplie les capacités - et les dépendances

Un agent qui peut appeler d'autres services fait souvent plus qu'un modèle isolé. Il peut consulter un outil métier, demander une vérification à un agent spécialisé, puis transmettre une action à un système de gestion. Cette coopération répartit le travail selon les compétences, au lieu de demander à un seul assistant de tout faire.

Elle introduit aussi des risques. L'erreur peut se propager d'un agent à l'autre. Une consigne mal comprise peut déclencher plusieurs actions. Un agent tiers peut recevoir trop d'informations, ou s'appuyer sur une source peu fiable. En clair : la coopération augmente la puissance, mais elle augmente aussi la surface à surveiller.

Évaluer la valeur au niveau du processus

Pour juger un agent, il faut regarder le processus complet, pas seulement « la qualité de la réponse ».

Une évaluation utile peut inclure :

1. le temps gagné, en comptant la préparation, la vérification et les corrections ;
2. le taux d'erreur et le coût de traitement des erreurs ;
3. la fréquence des cas que l'agent ne sait pas traiter ;
4. la qualité de la transmission vers les outils et les personnes concernées ;
5. le coût total : intégration, supervision et sécurité.

Cette approche évite de confondre automatisation et amélioration. Si une entreprise gagne dix minutes à la génération mais en perd vingt à contrôler le résultat, l'usage n'est pas vraiment rentable. À l'inverse, un agent moins « spectaculaire » peut être intéressant s'il traite de façon fiable un gros volume de tâches simples.

Une consigne n'est pas une méthode complète

Partager une instruction du type « préparez une analyse des ventes » ne transmet ni les conventions de calcul, ni la définition d'un « client actif », ni la période de référence, ni les exceptions connues. Une consigne efficace dépend d'un cadrage : objectifs, entrées attendues, contraintes, critères de réussite, et situations où le travail doit être interrompu.

C'est pour ça que l'artefact le plus réutilisable est souvent une spécification, plutôt qu'un prompt isolé. Elle décrit le problème et le résultat attendu, sans exiger que quelqu'un réutilise le même modèle ou le même environnement.

Concrètement, une spécification peut inclure :

• le but de la tâche et son périmètre ;
• les données nécessaires, avec leur format ;
• les règles métier et les contraintes ;
• les critères d'acceptation ;
• les cas où il faut escalader vers un humain ;
• les exigences de confidentialité et de conservation.

Ensuite, le destinataire devra l'adapter à son contexte. Une procédure pensée pour une grande entreprise ne se transpose pas automatiquement dans une PME ou une association, même si « sur le fond » le problème ressemble.

Le contexte personnel n'est pas un paquet transférable

Un assistant peut devenir plus utile avec le temps parce qu'il « comprend » les habitudes, les priorités et l'historique d'une personne. Mais cette mémoire est souvent liée à des circonstances particulières.

La transférer intégralement à un collègue peut exposer des informations privées, des données commerciales, ou des décisions qui n'ont pas vocation à circuler. Il faut donc distinguer ce qui est utile de ce qui est juste disponible. Pour partager une méthode, on n'a généralement pas besoin de copier toute la conversation ni toutes les données d'origine : une version réduite, documentée et expurgée aide à garder la logique du travail tout en limitant l'exposition.

Le principe de minimisation des données du RGPD est un bon repère : ne transmettre que ce qui est nécessaire à la finalité visée.

Documenter les limites fait partie de l'artefact

Un artefact de connaissance utile ne dit pas seulement ce que l'IA sait faire. Il précise aussi ce qu'elle ne doit pas faire, les hypothèses qui conditionnent le résultat, et la date de dernière mise à jour.

Sans ça, une consigne qui semblait correcte « hier » peut produire, « demain », une réponse trompeuse ou obsolète.

Pour une équipe, le format de partage devrait au minimum mentionner le propriétaire, la version, les sources de référence, le périmètre d'usage, les tests effectués et le canal pour remonter les erreurs. Ce n'est pas aussi « sexy » qu'un agent autonome, mais ça évite qu'une expérimentation réussie devienne un système incompris, difficile à maintenir ou impossible à retirer.

Standardiser les interfaces, pas les réponses

Un standard peut dire comment un agent découvre un outil, transmet un contexte ou reçoit un résultat. Il ne dit pas, en revanche, si l'agent a raison, si l'outil est sûr, ou si l'échange est pertinent.

L'interopérabilité facilite la circulation ; elle ne remplace pas l'évaluation.

Pour les équipes produit, standardiser les formats d'entrée, les permissions et les retours d'erreur rend l'ensemble plus prévisible. En revanche, imposer une même manière de raisonner ou une même forme de production peut effacer les spécialisations qui justifient justement l'usage de plusieurs agents.

Prévoir identité, autorisation et provenance

Un échange entre agents doit répondre à des questions simples, mais indispensables : qui a envoyé la demande ? Quelles données l'agent destinataire a-t-il le droit de consulter ? Qui valide l'action finale ? Et comment savoir si le fichier reçu est authentique et à jour ?

Ces sujets comptent encore plus quand des agents travaillent avec des partenaires, des prestataires ou des systèmes externes.

Une mise en œuvre prudente prévoit notamment :

• une identité vérifiable pour chaque agent et chaque service ;
• des permissions limitées à la tâche, plutôt qu'un accès général ;
• une trace des demandes, des réponses et des actions réalisées ;
• une provenance des documents et des consignes ;
• des mécanismes de validation avant les actions irréversibles ;
• la possibilité de suspendre ou de révoquer un accès.

Ces précautions ne concernent pas seulement les grands groupes. Une PME qui connecte un assistant à sa messagerie, à son outil de facturation et à son espace client doit déjà se demander quelles actions peuvent être effectuées sans intervention humaine. Le fait que l'interface soit simple ne réduit pas les conséquences d'un accès trop large.

Commencer par un flux limité et observable

Avant de faire coopérer plusieurs agents dans un processus central, commencez par une tâche fréquente, bien délimitée et réversible. Fixez clairement les entrées, le résultat attendu, les permissions nécessaires, et les cas qui exigent une validation humaine.

Puis démarrez en mode « observation » : l'agent propose, l'équipe décide. Mesurez ensuite les erreurs, les retards et le niveau d'intervention sur des cas représentatifs. Testez aussi des situations atypiques : donnée manquante, document contradictoire, demande hors périmètre, indisponibilité d'un outil.

Quand les résultats deviennent suffisamment fiables, vous pouvez élargir. Cette progression évite de découvrir les limites au moment où l'automatisation touche déjà des clients ou des opérations critiques.