Voici ce que nous déployons réellement chez nos clients, et ce qui, d’expérience, fait la différence entre une démonstration réussie et un outil utilisé.
§1Un agent répond sur vos données, pas sur le web
Un modèle de langage sait beaucoup de choses en général et rien de votre entreprise en particulier. Ce qui rend un agent utile, c’est l’accès à vos sources : documentation technique, base clients, procédures, outils internes. La valeur ne vient pas du modèle, elle vient de l’accès aux bonnes données et du cadrage de ce que l’agent a le droit de faire.
Quand l’agent répond à partir de vos documents, nous construisons la recherche documentaire et nous faisons citer les sources dans la réponse, pour que vos équipes puissent vérifier. Un agent dont on ne peut pas contrôler les réponses finit par ne plus être consulté.
§2Le modèle est un composant remplaçable
Nous travaillons avec des plateformes comme Dust ou Copilot Studio, et avec les API des principaux modèles. Le choix dépend de votre environnement et de vos contraintes de confidentialité. Mais quel que soit ce choix, une règle ne change pas : vos logiques métier restent hors de l’outil.
Concrètement :
- l’appel au modèle passe par une interface unique, pour que changer de fournisseur soit un changement de configuration plutôt qu’une réécriture ;
- les prompts sont conservés dans votre dépôt, versionnés et relisibles comme du code ;
- les appels sont journalisés, avec leur coût et leurs erreurs, pour savoir quelle fonction coûte quoi et comprendre une réponse à côté.
Les modèles évoluent tous les trimestres. Une architecture soudée à l’un d’eux vieillit avec lui.
§3La confidentialité se décide avant le modèle
Quelles données partent, vers quel fournisseur, hébergé où, conservées combien de temps ? Ces réponses dépendent du contrat et de l’architecture, pas du modèle lui-même. Nous classons vos données par sensibilité avant de choisir un modèle, parce que le choix découle de la contrainte et non l’inverse.
Nous limitons ce qui part à ce que la tâche exige. Quand la sensibilité l’impose, nous travaillons avec un modèle hébergé chez vous ou chez un fournisseur européen, et nous mesurons l’écart de qualité plutôt que de l’affirmer.
§4La mise en production est le vrai sujet
Une démonstration se fait en une journée. Ce qui prend du temps, c’est tout le reste :
- l’intégration à vos systèmes : un agent qui oblige à recopier des données à la main ne sera pas utilisé ;
- les cas limites : la question mal posée, le document contradictoire, la demande hors périmètre ;
- l’adoption : un agent se rencontre dans les outils que vos équipes ouvrent déjà, et leur usage s’apprend.
C’est là que nous passons l’essentiel d’une mission. Et c’est pourquoi nous formons vos équipes sur leurs propres cas, avec leurs données : à la fin, elles savent faire évoluer l’agent sans nous.
§5Ce qu’il faut retenir
Un agent n’est pas un produit que l’on installe, c’est un accès cadré à vos données, une architecture qui vous appartient et une équipe qui sait s’en servir. Commencez par une tâche précise, sur des sources maîtrisées, et mesurez son usage réel avant d’élargir.
Une agence-conseil comme Solstice Lab peut vous aider à choisir les bonnes tâches, à concevoir une architecture indépendante des modèles et à mettre vos agents en production.
